Product Prototyping

Build the cheapest prototype that answers a risk question. Test it with real users, then record the decisions, staffing and production requirements in the PRD.

Why this matters

Interviews test the problem. Prototypes let you observe a proposed solution in use. Cagan calls discovery building to learn and delivery building to earn.

AI makes convincing prototypes faster. Production still requires permissions, audit logs, reliability, integrations, residency, migration and support. Keep that gap visible during every review.

Prototypes: what they’re for

The four risks, one question at a time

Test value (will customers choose it?), usability (can they use it?), feasibility (can we build it?) and viability (can the business support it?). Chapter 01’s adoptability lens covers security, procurement and partner approval.

A prototype should target one risk, two at most. Write the risk question at the top before anyone builds anything:

We are testing whether [persona] will [observable behavior] when [situation], using [prototype]. This prototype deliberately ignores [what it doesn’t cover].

State exclusions explicitly. An approval-screen prototype may omit tenancy, permissions, audit logging and scale. These remain requirements for the PRD.

Use the prototype to communicate, but test it before treating the design as a solution.

Cagan’s prototype types

In a 2014 SVPG essay, “Flavors of Prototypes,” Cagan describes four families, with the user prototype split by fidelity. Different people build each one to answer a different question.

Cagan cautions that high-fidelity user prototypes reveal usability objections rather than proving sales. Live-data prototypes still omit production use cases, automation, localization and scale.

A hybrid can run diagnosis on historical incidents without live traffic or executed actions. Domain experts can assess whether quality merits a user test before a live pilot.

The fidelity ladder

Fidelity is three dials

NN/g’s Kara Pernice describes three independent fidelity dimensions: interactivity, visuals and content. A wireframe can contain realistic incidents. A polished mockup can contain only placeholders.

Low fidelity is fast to change, and users criticize it more freely. High fidelity tests realistic timing and detailed workflows, but it’s slower to build and invites attachment.

For expert B2B users, prioritize content fidelity. Plausible logs, service names and timelines make a plain wireframe more useful than decorative screens with fake domain content.

AI builders collapse the cost of visual and interactive fidelity, so teams reach for polish by default, and the attachment risk rises: the result looks finished, and stakeholders ask when it ships.

The rungs

This ladder combines Cagan’s types, Pernice’s dimensions and service simulation. The interface track increases interface realism. The service track increases realism behind it.

• Sketch. Pen, whiteboard or a quick drawing in a chat window. Good for exploring several directions with the trio in an hour.
• Wireframe. Layout and content without visual design. Tests information architecture: does the user find the evidence, the approval button, the rollback scope?
• Clickable. A user prototype that responds along the main paths. The workhorse of usability testing.
• Coded. Runs as software, built by hand or by an AI builder. Handles interactions (typing, filtering, live charts) that clickable prototypes fake badly. Still a simulation unless it’s connected to real data and traffic.
• Concierge. A human delivers the service openly, by hand, to a few customers. The canonical example is Food on the Table, a meal-planning startup that served its first customer face to face before automating anything. Its founder, Manuel Rosso, argued that if a personal, high-touch service can’t win adoption, a web page won’t. Eric Ries tells the story in The Lean Startup as the concierge MVP.
• Wizard of Oz. The participant uses an interface that appears automated, but a hidden human (the “wizard”) produces some or all of the responses. NN/g’s Sara Paul and Maria Rosala trace the method to Don Norman and Allen Munro in 1973 and the name to Jeff Kelley’s 1983 dissertation on natural-language interfaces. They recommend it for conversational interfaces, recommendations and generative AI features, where it tests desirability before you invest in building. Participants sometimes guess a human is involved, and anyone deceived must be debriefed afterward.
• Hybrid and live-data. The top of the service track, where engineers own the build.

Concierge participants know a human delivers the service. Wizard of Oz participants experience apparent automation. The first tests outcome value, the second the future automated experience.

Prototyping with AI in 2026

The tool categories

Colin Matthews’s January 2025 Lenny’s Newsletter guide groups tools into one-off chatbot prototypes, hosted app builders and local developer assistants. Design-to-code tools add a fourth category.

Andrej Karpathy coined vibe coding in February 2025 for building without reading generated code. Collins named it Word of the Year for 2025. This book reserves that approach for throwaway prototypes.

One rule ties the categories together: the closer a prototype gets to production data and real customers, the more engineering ownership it needs.

Cagan’s warnings about prototypes and products

Cagan’s “Prototypes vs Products” (2025) lists production demands: reliability, observability, scale, localization, integrations, maintenance, fault tolerance, security, compliance and recovery. A prototype covers only a few cases. Enterprise products must handle extensive policy and operational needs.

His warnings, for any team using AI builders:

• Prototyping tools and build tools serve different purposes. The gen-AI prototyping tools are generally not for building actual products, and don’t need to be. Production quality almost always takes different tools and skills.
• PMs underestimate the gap, especially PMs without engineering backgrounds, and vendors overstate how automatically a prototype becomes a product.
• Self-deception is the newer risk. Cagan sees product people themselves now confusing the two.

He allows one exception: internal tools and customer-enabling tools carry lower operational demands, so their path to product quality is shorter.

CVE-2025-48757 described insufficient row-level security in sites from a prompt-to-app builder, potentially exposing read and write access. The vendor disputed responsibility and pointed to customer data controls. Require engineering review before using real customer data or public exposure.

Cagan’s July 2026 AI productivity paradox argues that faster production of existing artifacts does not ensure better outcomes. Use AI to test in discovery and maintain production disciplines in delivery.

Usability testing that changes decisions

The method in brief

NN/g’s Kate Moran describes usability testing as three elements: a facilitator, a set of tasks and a participant, who usually thinks aloud. Tests are qualitative (find problems and understand why) or quantitative (measure task success or time against a benchmark). They run in person or remotely, and remote tests are moderated (live, over screen share) or unmoderated (a tool delivers written tasks).

For enterprise users, moderated remote is the practical default: they’re scarce, busy and often behind firewalls, and their workflows are complex enough that unmoderated sessions tend to stall on the first unfamiliar step.

How many users

Nielsen’s “Why You Only Need to Test with 5 Users” (2000) uses a model developed with Thomas Landauer. Across Nielsen’s projects, one user revealed about 31% of problems and five about 85%. He recommends repeated small rounds with redesign between them.

The model assumes comparable users. Nielsen suggests three to four participants per group for two groups and three per group for more groups. His 2012 guidance separates qualitative tests, around five participants, from quantitative studies, at least twenty. Recruit separately for distinct enterprise roles.

Krug’s Rocket Surgery Made Easy suggests three participants one morning monthly, followed by same-day prioritization and small fixes to serious problems. Both methods favor repeated small tests.

Thinking aloud

In thinking aloud, participants describe their thoughts while using the system. It works from paper to shipped software and lets stakeholders observe difficulties directly.

It’s also unnatural, participants filter their thoughts to sound smart, and facilitator prompts change behavior. So the facilitator gives representative tasks and stays quiet: prompt only on silence, never lead, and note every intervention so you can discount what follows it.

Writing tasks

Marieke McCloskey’s three rules for task scenarios, published by NN/g, separate a test from a guided tour:

1. Make the task realistic. Give the context a real user would have.
2. Make it actionable. Ask them to do it, not to describe how they would.
3. Avoid clues. Don’t name buttons, tabs or menu labels, and don’t give steps.

Weak: “Click the Diagnose tab and read the root cause.” Strong: “You were paged for checkout latency at 03:10. Find out what most likely caused it, and decide what to do next.”

From results to decisions

A test changes a decision only if someone agreed, before the sessions, what result would change it. This book’s practice is to pre-register signals in the test plan: a proceed signal (“at least four of five on-call engineers correctly approve or reject the proposed action”), an iterate signal and a kill signal (“any participant approves a rollback that the evidence on screen contradicts”). Results then map onto a decision instead of starting a debate.

Nielsen’s severity scale gives the readout a shared language. Severity combines frequency, impact and persistence, with market impact judged separately:

Every finding in the readout carries a severity, a count (“three of five participants”), one piece of evidence (a clip or a quote) and a decision: fix, test again, accept or kill.

Staffing the team

The product trio

Teresa Torres defines the product trio as a PM, designer and engineer jointly responsible for an outcome. They interview, map opportunities and test together, reducing repeated handoffs among requirements, designs and code.

Cagan’s empowered product team, in Inspired and Empowered, is the same idea at full size: a product manager, a product designer and typically two to ten engineers with a tech lead, given a problem rather than a feature.

For AI-powered products, this book extends the trio. Model quality and evals are core risks, so an applied AI engineer (or ML engineer) should be a standing fourth member during discovery. That’s our recommendation, not Torres’s.

Team types and interaction modes

Matthew Skelton and Manuel Pais’s Team Topologies names four team types: stream-aligned (delivers customer value along one value stream and owns its outcomes), platform (provides internal services that remove complexity for stream-aligned teams), enabling (helps other teams build a capability, temporarily) and complicated subsystem (owns a component that needs scarce specialist knowledge). It names three interaction modes: collaboration (close, time-boxed, expensive; good for discovering a new boundary), X-as-a-Service (one team consumes another’s service through a clear interface) and facilitating (one team helps another remove obstacles).

Their central constraint is cognitive load: overloaded teams decide worse and move slower. Interaction modes should evolve, typically from collaboration to X-as-a-Service once an interface is stable.

Staffing a new initiative, answer two questions in writing: what type of team is this, and what’s our interaction mode with each neighbor right now?

Cagan’s 2025 forward deployed engineer pattern embeds an engineer, sometimes a PM or designer, with a customer to learn the environment. A platform team generalizes the findings. Without that platform strategy, customer work can become expensive customization.

Capacity, honestly

Calculate net capacity by subtracting on-call, maintenance, support, migrations and other obligations from assigned staffing.

Then compare it with appetite, Ryan Singer’s term in Shape Up for how much time the business is willing to spend on a problem. Fixing time and varying scope keeps teams out of endless negotiation; in Singer’s words, “Stating the appetite in the pitch prevents unproductive conversations.” The staffing plan and the PRD should state the same appetite.

Writing the PRD

Prototype shows, PRD decides

In “Revisiting the Product Spec” (2006), Cagan recommends a high-fidelity prototype tested for usability and desirability, supplemented by use cases, reliability, performance, scalability and platform requirements. Writing a long specification alone creates weak evidence of progress.

Enterprise PRDs must cover API contracts, permissions, service levels, compliance, packaging, migration and partner impact. Use the prototype as the behavior specification. Use the PRD to record customer, problem, scope, success criteria and requirements beyond the screen.

Ben Horowitz’s “Good Product Manager/Bad Product Manager,” written in the 1990s and posted publicly in 2012, sets the tone: good product managers give direction in writing, define the what, leave the how to engineering and take written positions on the important tradeoffs. A PRD that specifies database tables has wandered into engineering’s job. A PRD that won’t take a position on scope has skipped the PM’s.

What a PRD contains

Teams vary widely, as Lenny Rachitsky’s survey of PM templates shows. This book’s full PRD has these sections, each there because a decision depends on it:

The one-page PRD

Start with a one-page PRD. This book combines Singer’s appetite, no-gos and rabbit holes with the one-pager formats Rachitsky collects. Include problem, audience, timing, appetite, solution sketch, prototype link, success measure, exclusions and open risks.

Use it to align leadership and the trio on a bet, then grow it into the full PRD as test results arrive.

PR/FAQ or PRD?

Werner Vogels’s 2006 description of Amazon’s working backwards practice starts with a press release, FAQ, customer experience and user manual. For services, the experience includes use cases and sample code.

Colin Bryar and Bill Carr’s Working Backwards describes the PR/FAQ in practice. The press release names the product, the customer and the benefit, then covers the problem, the solution, quotes from a spokesperson and a hypothetical customer, and how to get started. The FAQ has an external half (price, how it works, support) and an internal half (competition, demand, unit economics, investment, legal issues, dependencies and the top reasons it could fail). Most PR/FAQs never become products, by design.

The two documents answer different questions, in sequence:

The sequence that works: PR/FAQ, then prototype tests, then PRD. Platform PMs should take Vogels’ point about web services literally. The customer experience of an API is sample code, so writing the developer documentation before building is one of the strongest prototypes a platform PM has.

The PRD has two readers now

GitHub’s Spec Kit, released in September 2025, supports spec-driven development. Den Delimarsky describes four phases: specify intent and outcomes, plan architecture, define testable tasks, and implement under human review. Explicit intent reduces agent guesswork.

The PRD may now be read by people and by agents. The PM still owns the what and the why: user journeys, acceptance criteria, non-goals and constraints, written precisely enough that an agent could turn them into a plan and tests. Engineering owns the plan and the tasks. A requirement an agent can’t interpret (“make it intuitive”) was never a good requirement for people either.

The AI feature addendum

When the feature is AI-powered, the classic PRD is necessary but not sufficient. Chapter 31 covers the AI PRD addendum: evals with pass-rate targets as acceptance criteria, a failure taxonomy, latency budgets and cost per task, trust and failure UX, staged autonomy with a kill switch, a gross-margin floor and regulatory classification. Attach it to the PRD for any feature where a model’s output reaches a user or takes an action.

How to apply it

This method runs one discovery-to-PRD cycle on a significant bet, after the hypothesis work in Chapter 01. Plan on four to eight weeks.

Frame (week 1)

1. Pick the riskiest assumptions from the top-right quadrant of the assumption map. Write a risk question for each and name the risk it tests.
2. Write the PR/FAQ if the bet is new or large, and hold the review. Proceed only on a go.
3. Write the one-page PRD, with appetite and no-gos. It will be wrong in places; that’s what the tests are for.

Prototype (weeks 1 to 3)

4. Choose the type and rung for each risk question: the lowest rung that can answer it. For expert users, turn up content fidelity before visual fidelity.
5. Assign builders by type. Engineers build feasibility and live-data prototypes; designers and PMs build user prototypes. Decide up front which are throwaway.
6. Set the data rule. No real customer data in any prototype a PM or designer built with a prompt-to-app or chat tool. Use realistic synthetic data that a domain expert has checked for believability.
7. Pilot every prototype with a colleague before real sessions.

Test (weeks 2 to 5)

8. Write the test plan: the decision it informs, the risk question, the prototype, participants per role, three to five tasks, pre-registered signals, logistics and the readout date.
9. Recruit three to five participants per distinct role, through customer success and sales.
10. Run moderated remote sessions with think-aloud. The trio watches every session; invite one stakeholder who needs convincing.
11. Debrief the same day, then iterate. Fix the worst problems with the smallest change and retest with new participants.

Decide and write (weeks 5 to 8)

12. Write the readout. Rate findings by severity with counts and evidence, compare them with the signals and recommend proceed, iterate, pivot or stop.
13. Write the staffing plan: team type, roles, interaction modes, net capacity, appetite and the binding constraint.
14. Grow the one-pager into the full PRD. Link the tested prototype as the behavior spec; add non-functional requirements, dependencies and the decision log; attach the Chapter 31 addendum for AI features.
15. Review the PRD with engineering, design and the gatekeepers (security, legal, partner teams) before delivery planning starts. Stories and acceptance criteria continue in Chapter 06.

Later test results revise the PRD, and every revision lands in the decision log.

The AI lens

Prototyping AI-powered products

AI features change what a prototype has to prove.

• Quality is the first feasibility question. For a deterministic feature, feasibility asks whether you can build it. For an AI feature it asks whether the output is good enough, often enough. Answer that with a hybrid prototype first: run the model on real historical cases with no live traffic and have domain experts grade the output. If quality is far from the bar, interface polish won’t save it.
• Test trust, not only usability. A user can understand an AI output perfectly and still not act on it, or act on it when they shouldn’t. Seed tasks where the AI is wrong on purpose. For an AI feature, the most important usability finding is whether users catch a confident, plausible mistake.
• Use Wizard of Oz to separate the experience from the model. A human wizard produces the ideal output so you learn whether the format, evidence and level of autonomy drive trust before the model can deliver it. Have engineers define feasible responses so the wizard doesn’t promise what the model can’t do.
• Prototype the failure states. Every AI prototype needs a screen for “I’m not sure,” a way to correct the output and a way to undo an action. A happy-path-only prototype tests a product that won’t exist.

Doing the work with AI

Hand the harness the mechanical work:

• Drafting the test plan from the PR/FAQ’s riskiest assumptions and the assumption map.
• Generating realistic synthetic data (incidents, logs, tickets) for prototypes, for a domain expert to review.
• Building single-screen prototypes in several variants so the trio can compare directions.
• Piloting the script against a synthetic participant to find confusing or leading tasks.
• Transcribing sessions, clustering observations and drafting the readout with counts and timestamps.
• Drafting the capacity table and the PRD from the schedules, readout and decision log.

Keep with people:

• Choosing the risk question, moderating sessions, judging severity and making the decision.
• Verifying every number in the readout against the recordings. “Four of five” when it was three of five changes the decision.
• Taking positions in the PRD. A harness will happily produce a balanced document that decides nothing.

Use AI-assisted discovery to improve decisions. Faster production of prototypes and PRDs matters only when their evidence changes what the team builds.

The Beacon case: prototyping supervised remediation

The risk questions. The trio, now four with an applied AI engineer, writes three:

1. Usability and value: Will Dana, paged at 3 a.m., correctly approve or reject an agent-proposed action from the evidence on screen within five minutes?
2. Viability (adoptability): Will Sam approve the permissions and audit model for allowlisted actions?
3. Feasibility: Can the agent retrieve recent deploys and change tickets through the existing connectors, including MCP servers, and cite them within the latency budget?

The prototype set. Each question gets the lowest rung that answers it:

• Feasibility prototype. The applied AI engineers wire the agent to the deploy and change-ticket connectors in a sandbox and measure citation latency. No interface; throwaway.
• User prototype. The designer and you build the approval screen with a design-to-code tool: proposed action, root cause, cited evidence, blast radius, approve and reject. Content fidelity is high: Priya’s team helps write a dozen realistic incidents. No real customer data goes near it.
• Wizard of Oz. In two design-partner sessions, an SRE on the Beacon team writes the “agent’s” diagnosis live behind the interface, to learn whether the evidence format drives trust before the agent can produce it. Participants are debriefed afterward.
• Hybrid prototype. With two design partners’ agreement and under their data controls, the agent diagnoses real past incidents: live data, no live traffic, no actions executed. Two SREs grade each diagnosis to estimate the offline diagnosis acceptance rate.

The prototype that wanted to ship. Two weeks in, a sales leader asks to demo the approval screen at Marcus’s peer roundtable as “what’s coming.” You walk through what’s missing: least-privilege access, per-action audit logs, data residency and the kill switch, exactly Sam’s requirements. It goes to the roundtable as a labeled concept with invented data.

The test. Moderated remote sessions with think-aloud cover three roles: five on-call engineers (Dana’s role) and three SRE leads (Priya’s) on the approval flow, and three security reviewers (Sam’s) on the permissions and audit screens. No task names an interface label. Each on-call engineer sees four incidents, one with a seeded wrong root cause: a plausible recent deploy that the timeline contradicts. The pre-registered signals: proceed if at least four of five on-call engineers make the right call on every incident; kill this design if any participant approves the seeded wrong rollback without opening the evidence.

The readout. Round one trips the kill signal.

The Wizard of Oz sessions agree: participants questioned weak diagnoses when the evidence appeared with timestamps, and trusted them when it was summarized. In round two, with the cited evidence listed on the approval screen, all five new on-call engineers reject the seeded wrong rollback, and all three security reviewers say they could approve the permissions model if the audit log ships with it.

You also record what the test couldn’t tell you: whether responders still check the evidence at 3 a.m., under real pressure, after weeks of mostly correct diagnoses, and whether the agent’s real failure modes look like the seeded one. Both become open questions in the PRD and things the design-partner pilot must measure. Chapter 31 picks up what happens when one of them goes wrong.

The staffing plan. Beacon has three PMs, one designer, about 35 engineers across five teams, and two applied AI engineers. Staff Agents as a stream-aligned team: PM, shared designer, tech lead, six engineers and one applied AI engineer. The shared designer is the binding constraint. Connectors supplies a platform service after two weeks of collaboration on approval and audit APIs. The second AI engineer and an SRE enable evaluation practice for a quarter. One engineer embeds with two design partners. Subtract on-call and Classic migration load. Leadership must add design capacity or sequence Leo’s MSP work after launch.

The PRD. You grow the one-pager into the full PRD, targeted at Northlight Live, with the tested prototype as the behavior spec. Non-goals include fully autonomous actions beyond each customer’s allowlist and multi-tenant views for MSP partners such as Leo in v1. The Chapter 31 addendum covers diagnosis acceptance evals, the failure taxonomy, cost per resolved incident (a pointed question: Beacon’s gross margin already fell from 81% to 72% after agentic features launched) and the EU AI Act documentation European customers have asked for.

The week-one PR/FAQ justified testing. The PRD records a narrower v1 based on the evidence.

Product 360 artifacts

These templates are this book’s syntheses of the methods above. The test plan, script and readout are used once per round; the staffing plan and the PRDs are durable and revised as the work moves.

# Prototype test plan · [Initiative] · Round [n] · [Date]

**Owner:** [PM]   **Trio:** [PM, designer, engineer, applied AI engineer if AI]   **Decision owner:** [Name]   **Readout date:** [Date]

## Decision this test informs
[The specific decision, e.g. "Proceed to PRD with design A, iterate, or stop."]

## Risk question
We are testing whether [persona] will [observable behavior] when [situation], using [prototype].
Risk type: Value / Usability / Feasibility / Viability (adoptability)
Assumption(s) from the assumption map: [#, #]

## Prototype
- Type: Feasibility / Low-fidelity user / High-fidelity user / Live-data / Hybrid / Wizard of Oz / Concierge
- Fidelity: Interactivity [L/M/H] · Visuals [L/M/H] · Content [L/M/H]
- Built by: [Name, tool category]
- Throwaway or reusable: [ ]
- Deliberately ignores: [permissions, scale, audit, multi-tenancy, ...]
- Data: synthetic (reviewed by [domain expert]) / real (engineering-owned, with [controls])
- Piloted with: [Colleague] on [Date]

## Participants
| Role (persona) | Count this round | Screener criteria | Recruiting source |
|---|---|---|---|
| | | | |

## Tasks (three to five, no interface labels)
1.
2.
3.

## Signals (agreed before testing)
- Proceed if:
- Iterate if:
- Kill or pivot if:

## Logistics
Format: moderated remote / in person / unmoderated   Session length: [min]   Recording consent: [method]
Observers: [names]   Debrief: same day, [time]
Wizard of Oz or deception used: Yes / No   If yes, debrief script: [link]
Customer data handling: [approved tools only; what's recorded and where it's stored]

# Usability test script · [Prototype] · [Persona] · [Date]

**Facilitator:** [Name]   **Note-taker:** [Name]   **Length:** [45 to 60] minutes

## 1. Welcome and consent (5 min)
- Thank them. Explain the session: "We're testing a design, not you. You can't do anything wrong here."
- "Some of what you see won't work yet. That's expected."
- Ask permission to record. Name who is observing.

## 2. Thinking aloud (3 min)
- "As you work, please say what you're thinking: what you're looking at, what you expect, what surprises you."
- Warm-up: ask them to think aloud while doing a simple task on a familiar site or tool.

## 3. Background (5 min)
- "Tell me about your role and how [the situation] usually comes up for you."
- "Tell me about the last time it happened. What did you do?"

## 4. Tasks (25 to 35 min)
Read one task at a time. Hand it over in writing as well.

| # | Scenario (realistic, actionable, no clues) | What we're watching for | Post-task question |
|---|---|---|---|
| 1 | | | "How confident are you in what you just decided, from 1 to 7? Why?" |
| 2 | | | |
| 3 | | | |

Facilitator rules: stay quiet. Prompt only on silence ("What are you thinking now?"). Don't answer questions about the interface; turn them back ("What would you expect?"). Note every intervention.

## 5. Wrap-up (5 min)
- "What was most confusing? What was most useful?"
- "If you could change one thing, what would it be?"
- If Wizard of Oz was used: explain that a person produced some responses, why, and offer to answer questions.
- Thank them and confirm any incentive.

## Note-taking grid
| Time | Task | What they did | What they said (verbatim) | Intervention? |
|---|---|---|---|---|
| | | | | |

# Test readout · [Initiative] · Round [n] · [Date]

**Decision requested:** [proceed / iterate and retest / pivot / stop]   **Decision owner:** [Name]   **Recordings:** [link, access-controlled]

## Summary (three sentences)
What we tested, with whom, and what we recommend.

## Against the pre-registered signals
| Signal | Threshold | Result | Met? |
|---|---|---|---|
| Proceed | | | |
| Kill | | | |

## Findings, ranked by severity
Severity: 0 not a problem · 1 cosmetic · 2 minor · 3 major · 4 catastrophe (must fix before release)

| # | Severity | Finding | Count (n of N, by role) | Evidence (clip or quote, timestamp) | Decision (fix / retest / accept / kill) |
|---|---|---|---|---|---|
| 1 | | | | | |

## What we'll change before the next round
Smallest change that fixes each severity 3 and 4 finding:
1.
2.

## What worked (keep)
-

## What we still don't know
-

## Effect on the hypothesis and PRD
Assumptions confirmed, revised or killed: [#, #]   PRD sections to update: [ ]

## Verification
Every count and quote checked against recordings by [Name] on [Date].

# Team staffing plan · [Initiative] · [Date]

**Owner:** [PM]   **Approver:** [Leader]   **Review date:** [Date]

## Outcome and appetite
- Outcome the team owns: [metric and target]
- Appetite: [weeks or quarters] for [scope boundary]

## Team type
Stream-aligned / Platform / Enabling / Complicated subsystem. Why:

## Roles
| Role | Named person | Allocation (%) | Responsibilities | Backfill or gap |
|---|---|---|---|---|
| Product manager | | | | |
| Product designer | | | | |
| Tech lead | | | | |
| Engineers | | | | |
| Applied AI engineer (AI features) | | | | |
| Forward-deployed engineer (if used) | | | | |
| Product marketing | | | | |
| Other (data, security, docs) | | | | |

## Interaction modes with neighboring teams
| Team | Mode now (collaboration / X-as-a-Service / facilitating) | Until | Target mode | Interface or agreement |
|---|---|---|---|---|
| | | | | |

## Capacity
| | Engineer-weeks per quarter |
|---|---|
| Gross (people × weeks × allocation) | |
| Less on-call | |
| Less maintenance and support | |
| Less migrations and other keep-the-lights-on work | |
| **Net capacity for this initiative** | |

Net capacity versus appetite: [fits / doesn't fit, by how much]

## Binding constraint
[The one role or team that limits throughput, and the decision needed: add, borrow, sequence or cut.]

## Dependencies and risks
-

## Asks
-

# PRD · [Feature or product] · v[n] · [Date]

**Owner:** [PM]   **Status:** Draft / In review / Approved / In delivery / Shipped   **Reviewers:** [engineering, design, security, legal, partner, PMM]
**Links:** Hypothesis · PR/FAQ · Prototype (behavior spec) · Test readouts · Staffing plan · AI addendum (Chapter 31)

## 1. Problem and evidence
What's wrong, for whom, how often, what it costs. Cite interviews, test readouts and data.

## 2. Customers and personas
| Persona | Role in the deal | What they need from this release |
|---|---|---|
| | | |

## 3. Goals and success metrics
| Metric | Baseline | Target | Measured how | By when |
|---|---|---|---|---|
| | | | | |

## 4. Non-goals
What this version deliberately doesn't do, and why.

## 5. Scope and user journeys
Journey 1: [persona] [situation] → [steps] → [outcome]. Prototype link: [ ]
Journey 2:

## 6. Requirements and acceptance criteria
| # | Requirement (the what) | Journey | Acceptance criteria (testable by a person or an agent) | Priority |
|---|---|---|---|---|
| | | | | |

## 7. Non-functional requirements
- Security and permissions:
- Audit and logging:
- Performance and reliability:
- Data residency and privacy:
- Accessibility and localization:
- Integrations and APIs (contracts, versioning):

## 8. Dependencies and staffing
Teams, interaction modes and capacity, from the staffing plan.

## 9. Risks and open questions
| Risk or question | Impact | Owner | How we'll resolve it | By when |
|---|---|---|---|---|
| | | | | |

## 10. Rollout, pricing and packaging
Rollout stages, eligibility, migration, enablement, pricing and packaging impact.

## 11. AI features only
Attach the AI PRD addendum (Chapter 31): evals and pass-rate targets, failure taxonomy, latency and cost per task, trust and failure UX, staged autonomy and kill switch, margin floor, regulatory classification.

## 12. Decision log
| Date | Decision | Options considered | Decided by | Rationale |
|---|---|---|---|---|
| | | | | |

# One-page PRD · [Bet] · [Date]

**Owner:** [PM]   **Decision needed:** [what, from whom, by when]

**Problem.** [Two or three sentences, with the strongest piece of evidence.]

**Who.** [Primary persona, and the buying-group member who could block it.]

**Why now.** [What changed: customer demand, technology, competition, strategy.]

**Appetite.** [Time the business is willing to spend, and the team that would spend it.]

**Solution sketch.** [Core elements in a few bullets. Prototype link: ]

**Success metric.** [One metric, baseline, target, timeframe.]

**Non-goals and no-gos.**
-
-

**Rabbit holes.** [Known pitfalls and how we'll avoid them.]

**Top risks.** [Value / usability / feasibility / viability, one line each.]

**Open questions.**
-

**Next step.** [Test, build or stop, and when this page becomes a full PRD.]

Prompts

Goal: Pick the lowest rung on the fidelity ladder that can answer each risk question.
Paste in: your assumption map (top-right quadrant), the personas involved and any constraints on time, people or data.

For each assumption below, act as a skeptical product coach and:
1. Rewrite it as a risk question: "We are testing whether [persona] will [observable behavior] when [situation]."
2. Name the risk type: value, usability, feasibility or viability (including adoptability: will security, procurement and the buying group let it through?).
3. Recommend a prototype type (feasibility, low- or high-fidelity user, live-data, hybrid, Wizard of Oz or concierge) and set each fidelity dial (interactivity, visuals, content) to low, medium or high. Explain why a lower rung wouldn't answer the question.
4. Say who should build it (engineer, designer, PM), whether it's throwaway, and what it deliberately ignores.
5. State whether it needs real customer data. If it does, say that engineering must own it.

Recommend the lowest fidelity that can answer the risk question.

[assumptions, personas, constraints]

Check the output: for each recommendation, ask whether a sketch or wireframe with realistic content would answer the same question. If it would, drop a rung.

Goal: Get a test plan and script that map results to a decision before any session runs.
Paste in: the risk question, the prototype description, the personas and the decision the test informs.

Draft a moderated remote usability test plan and script for [prototype], testing this risk question: [risk question].

Plan: the decision this informs; participants per distinct role (three to five each); three to five tasks; proceed, iterate and kill signals stated as observable thresholds; logistics including recording consent and same-day debrief.

Script: welcome and consent ("we're testing the design, not you"); think-aloud instructions with a warm-up; background questions about the participant's last real experience of the situation; each task as a realistic, actionable scenario; a confidence question after each task; wrap-up.

Task rules: describe a realistic situation and goal. Let the participant choose the interface path independently. Keep navigation labels and step-by-step guidance out of the tasks. If this is an AI feature, include at least one task where the AI output is plausibly wrong and the evidence on screen shows it.

[risk question, prototype, personas, decision]

Check the output: read each task aloud and delete any interface word that appears on the screen. Make sure the kill signal is something you'd actually act on.

Goal: Catch confusing, leading or impossible tasks before a real customer sees them.
Paste in: the test script and a short description of the persona and their environment.

Role-play as [persona description] in a moderated usability session using this script. Respond to each task briefly, in character, describing what you'd look for and where you might get stuck. Then step out of character and list:
1. Tasks that give away the answer or name interface elements.
2. Tasks a real person in this role couldn't attempt without context the script doesn't give.
3. Questions likely to produce opinions rather than behavior.
4. Anything that would take much longer than the time allotted.

Your in-character responses are not research and won't be reported as findings. I only want feedback on the script.

[script]

Check the output: use only the script feedback. Discard the in-character answers. Then pilot with a real colleague before the first session.

Goal: Draft a readout that ranks findings by severity and ties them to the decision.
Paste in: session transcripts or notes (with timestamps), the test plan with its pre-registered signals and the observers' debrief notes. Use only tools approved for customer recordings.

Draft a usability test readout for [test].
1. List every distinct problem observed. For each: what happened, which participants (by ID and role), a verbatim quote or behavior with timestamp.
2. Propose a severity from 0 to 4 using frequency, impact and persistence. Show your reasoning; I'll decide the final rating.
3. Compare results with each pre-registered signal and say whether it was met.
4. For severity 3 and 4 findings, suggest the smallest change that might fix the problem.
5. List what worked, what we still don't know, and which assumptions were confirmed, revised or killed.

Rules: count behavior supported by the transcripts. Use exact words inside quotation marks. Report participant disagreements. Leave the final decision section for me.

[test plan, transcripts, debrief notes]

Check the output: verify every count and quote against the recordings. Watch for findings inflated from one participant into "users."

Goal: See whether the team you have can deliver the appetite you've stated.
Paste in (or connect the harness to): the team roster with allocations, the on-call schedule, the last two quarters of ticket and maintenance load, known migrations and the appetite from the one-page PRD.

Draft a staffing plan for [initiative].
1. Propose a team type (stream-aligned, platform, enabling or complicated subsystem) and explain why.
2. List roles, named people and allocation. Flag any role with no owner.
3. For each neighboring team, propose an interaction mode now (collaboration, X-as-a-Service or facilitating), when it should change and to what.
4. Calculate net capacity in engineer-weeks: gross capacity minus on-call, maintenance and support, and migrations, using the data provided. Show each subtraction and its source.
5. Compare net capacity with the appetite. Identify the binding constraint and give options: add, borrow, sequence or cut scope.

If data is missing for any subtraction, say so instead of estimating silently.

[roster, schedules, load data, appetite]

Check the output: confirm the subtractions with the tech lead. Ask whether the binding constraint the model named is the one the team would name.

Goal: Draft a full PRD from the evidence, written for people and for coding agents.
Paste in: the one-page PRD, test readouts, the decision log, the staffing plan and links to the tested prototype.

Draft a PRD for [feature] with these sections: problem and evidence; customers and personas; goals and success metrics; non-goals; scope and user journeys; requirements with acceptance criteria; non-functional requirements (security, permissions, audit, performance, reliability, data residency, accessibility, integrations); dependencies and staffing; risks and open questions; rollout, pricing and packaging; decision log.

Rules:
- Define customer behavior, purpose and constraints. Leave architecture and implementation tasks to engineering.
- Write each acceptance criterion so a person or a coding agent could turn it into a test.
- Every claim in "problem and evidence" must cite a readout, interview or data source from the material. Write "No evidence yet" where there is none.
- Treat the prototype as the behavior spec; describe only what it can't show.
- Record unresolved tradeoffs as open questions with owners for the team to decide.
- If this is an AI feature, add a placeholder for the AI PRD addendum and list the questions it must answer.

[material]

Check the output: delete any sentence that would read the same in any company's PRD. Confirm the non-goals with the trio, and check that each non-functional requirement has a gatekeeper who has seen it.

Goal: Find the gaps a security reviewer, an engineer or a partner team would find, before the review.
Paste in: the PRD and, for AI features, its addendum.

Review this PRD as three reviewers in turn: a skeptical tech lead, a security and compliance reviewer, and the PM of a team that depends on this feature. For each reviewer:
1. List the requirements that are ambiguous or untestable.
2. List what's missing that they'd need to approve it.
3. Name the decision the PRD avoids taking.
Then list any place where the PRD describes a prototype's behavior as if it were already built to production standards (reliability, observability, scale, integrations, security, recovery).

[PRD]

Check the output: fix the gaps that would block approval. For the rest, add them to open questions with an owner rather than expanding the PRD.

Anti-patterns

Checklist

• Every prototype has a written risk question, a risk type and a list of what it deliberately ignores.
• Each prototype is the lowest rung that answers its question, and engineers own anything touching real data.
• No prototype built by a PM or designer holds real customer data, and every prototype shown outside the team is labeled as a concept.
• AI-feature prototypes include failure states, and tests include a seeded wrong output.
• The test plan names the decision it informs and pre-registers proceed, iterate and kill signals.
• Each distinct role has three to five participants per round, recruited against a screener.
• Tasks are realistic and actionable and name no interface labels; the script has been piloted.
• Sessions use think-aloud, the trio observes and the debrief happens the same day.
• The readout rates every finding by severity, with counts and evidence checked against recordings.
• The staffing plan names team type, interaction modes, net capacity after keep-the-lights-on load and the binding constraint.
• A one-page PRD with appetite and no-gos exists before the full PRD.
• The full PRD links the tested prototype as the behavior spec and covers non-functional requirements, non-goals and a decision log.
• Acceptance criteria are testable by a person or an agent.
• AI features have the Chapter 31 addendum attached.
• Large new bets have a reviewed PR/FAQ before discovery commits real effort.