Cisco · Duo Security
Early Access
Portal
A self-service early-access portal where customers turn on beta features and share feedback on their own — designed in code with AI and shipped to customer beta in about a month.
Overview
A self-service loop, not a recruitment cycle
Customers turn on beta features themselves and send feedback right from the product, instead of waiting for a product manager to recruit them one by one.
Customer
turns on features →
← routed feedback
Product
team
No one brokers the loop anymore. Signal flows both ways, at scale.
The Problem
Manual outreach was the bottleneck
The old feedback model ran entirely on outreach, with a person in the middle of every loop. Alpha and beta were where the work stalled.
| Pain | Reality |
|---|
| Recruitment | Product managers spent days to weeks per program finding customers |
| Response rate | Manual outreach landed under 1% |
| Dependency | Every conversation brokered through customer success |
| Repetition | The whole cycle restarted at alpha → beta → GA |
The Shift
Opt in, no one in the middle
A portal where customers opt into early access and send structured feedback themselves — no recruitment, no one brokering the middle.
For customers
Opt into early access and shape the product on their own terms, instead of waiting to be found.
Internally
Feedback comes back tagged and routed, so product managers reclaim the weeks lost to recruitment and synthesis.
Value runs both directions — customers engage on their own terms, the team gets signal at scale.
Role & Team
Sole designer, four-person core team
Covering research framing, the end-state vision, every iteration, and the build that shipped to engineering. No separate design team, and deliberately no Figma stage.
4
Core team: design, product management, and two engineers
4+
Stakeholders — product, engineering, design, and leadership — in weekly review
0
Figma files — every iteration designed directly in code
Weekly cadence
- Mon standup · Wed office hours
- Fri — 4+ stakeholders review a live build
Why it mattered
The artifact under review was the implementation, so feasibility and scope got resolved in one conversation instead of across three.
Collaboration
Trust built on a live build, not a deck
Every Friday, product, engineering, and leadership reviewed the same working software — not a mockup, not a spec. That changed how the team worked together.
One conversation, not three
Feasibility, design intent, and scope got resolved live in the room, instead of bouncing across separate design review, eng scoping, and PM alignment meetings.
Shared reality over assumptions
Everyone reacted to the same real thing each week, instead of carrying their own mental model of what "the feature" was supposed to be.
Faster trust, faster yes
Leadership could see progress firsthand every week, which made it easier to greenlight scope changes without a lengthy re-pitch.
The build itself became the shared source of truth for product, engineering, and leadership alike.
Design Process
Not a blank page — a handoff to build on
It began with a starting direction from product, taken much further before the first real build.
Starting point
- Rough PRD
- Initial competitive research
- Lovable mockup
Taken further
- Reviewed the existing research
- Far wider competitive teardown
- Grounded the vision into the product
From there, the direction was rebuilt inside the actual product — the real Duo admin shell, its navigation, and existing components.
Research
Competitive teardown
A wider teardown of how Linear, Vercel, Notion, Stripe, and Slack each handle beta — down to the design-system details.
- Surfacing — where beta features live in the UI
- Enrollment — how users opt into early access
- Feedback — how input gets routed back
- Design system — badges, toggles, density
00 Iteration
The vision, grounded in the product
The PM's Lovable concept rebuilt inside the real Duo admin shell, as an Early Access settings page. A grounded starting point, before real content structure or a feedback loop.
- Rebuilt the PM's Lovable concept inside the real Duo admin shell and its existing components
- Framed early access as a settings page rather than a standalone surface
- A grounded starting point, with no real content structure or feedback loop yet
01 Iteration
First design pass
The first build designed in code. Page inside the admin panel, feature-list structure, status, enable/disable, and a feedback prompt.
- First build designed entirely in code, living inside the admin panel
- Introduced a feature-list structure with per-feature status and an enable/disable toggle
- Added a feedback prompt to start closing the loop with customers
02 Iteration
Closest to the end state
Explored where early access lives: dedicated homepage vs. top-nav entry. A content pass tightened feature names and descriptions.
- Promoted early access to a top-nav entry instead of burying it in settings
- Tightened feature names and descriptions in a dedicated content pass
- The structure that came closest to the shipping end state
From a North Star to a Spec
Design the end state, then cut scope
The PRD was a North Star: direction, with almost no requirements. Instead of waiting for it to fill in, I designed the end state in code, then cut scope down to the V1 worth shipping first.
| Earlier attempt | This time |
|---|
| Build toward the full automated vision | Start with the simplest possible version |
| Scope kept expanding | Iterate weekly, nothing gets scrapped |
| Never shipped | Every V1 decision made with the end state in mind |
What V1 had to prove: a Beta Programs page, a short feature list, status with a per-feature toggle, and a feedback prompt on opt-out. One question — if we give customers a page to enroll themselves, will they use it?
V1 In development
The build that shipped
Feedback intake, routing, and the early-access surface consolidated into what customers actually touch. Handed to engineering, now entering customer beta.
- Consolidated the early-access surface into the page customers will actually touch
- Built feedback intake that tags and routes input to the right teams
- The build handed to engineering, now entering customer beta
Results
Live in customer beta
V1 went into customer beta and is actively in review, gathering more feedback as customers use it.
~1 mo
Design to customer beta — record time for a project of this scale
5
Features shipping to customers, rolled out on a percentage basis
0
Middlemen — no manual recruitment or customer-success coordination
1.5 weeks in
- 148 unique visitors
- 231 total visits
- 21 engaged with a feature
1 month in
- 39 customers enrolled
- 40% of customers rolled out
- 4 of 5 features at double-digit adoption
AI Learnings
How designing in code with AI changed the workflow
The biggest shift wasn't a feature — it was the loop the whole team worked in.
Hours, not weeks
Each iteration went from idea to a working, clickable build in hours instead of weeks — design stayed ahead of the project instead of trailing it.
Reviews changed shape
Weekly reviews shifted from critiquing mockups to critiquing working software — feasibility questions got answered on the spot, not punted to a follow-up.
The tradeoff
Less upfront spec meant more in-flight scope negotiation — the PRD got written against something real, but it was written later, not first.
What we'd tell another team: don't wait for the spec to stabilize — build the end state, cut it down to a V1, and let the working software carry the argument.
Reflections
Design led the project
The real shift was the process. Designing in code with AI turned ideas into working screens in hours instead of weeks, so design ran ahead of the project instead of trailing it.
- Design led the project — there was always something real to react to, instead of waiting on a spec.
- The build kept everyone aligned — product, engineering, and customer success worked off the same real thing instead of their own assumptions.
- Requirements emerged by reacting — each demo sharpened the PRD against something real, not an abstract doc.
Cisco / Duo Security · 2026
