glossary · discovery
Prototype
A throwaway artifact built to answer one specific question about desirability before engineering commits.
A prototype is a learning instrument, not a deliverable. Its only job is to produce a decision: build, pivot, or kill. If the session ends without a clear go/no-go call, the prototype was wasted.
The fidelity decision
Fidelity is a PM call, not a design call. It should track the hypothesis being tested, not the team’s comfort level or how much time is available.
- Lo-fi (paper, sketches, whiteboard flows): Use when the debate is structural. Is this the right flow? Are we solving the right problem? Lo-fi forces feedback on shape, not execution. In 2026, lo-fi’s primary value is alignment speed inside the room, not prototyping speed, because hi-fi is almost as fast to produce.
- Mid-fi (clickable wireframes, Figma flows with minimal styling): Use when the question is about navigation and interaction patterns. Can users find the action? Does the sequence make sense? Keeps visual noise low so users respond to behavior, not polish.
- Hi-fi (pixel-perfect Figma, coded prototype): Use when emotional response, trust, or usability confidence is what you need to measure. A checkout flow, a healthcare intake form, an AI assistant’s first-run experience: these require hi-fi because the feeling IS the hypothesis.
The fidelity trap is real. Showing a hi-fi prototype before you have validated the core concept causes users to critique button colors instead of the underlying idea. That feedback is noise. An interviewer who hears you jumped straight to hi-fi will probe why, and “we wanted it to look good” is a wrong answer.
Where prototyping fits in the process
In the double diamond, the prototype lives at the end of Develop and feeds back into Define: you have converged on a concept, and the prototype tests whether that concept holds against real users before you move to Deliver.
In a Google Ventures Design Sprint, the schedule is precise: the team builds the prototype entirely on Day 4. It is tested with exactly five real users on Day 5. The sprint prototype is intentionally throwaway. It is never shipped. The output is a set of decisions, not an artifact to hand off.
Prototype vs. MVP vs. POC
These three are the most common interview trap in product sense questions. They answer different questions at different commitment levels.
| Proof of concept | Prototype | MVP | |
|---|---|---|---|
| Question it answers | Can we build this? | Should we build this? | Will people pay for or habitually use this? |
| Audience | Internal (engineering, leadership) | Target users | Real market |
| Ships? | Never | Rarely | Yes |
| Output | Technical verdict | Desirability verdict | Market verdict |
The commitment ladder runs POC to prototype to MVP. Each stage earns the right to move to the next by resolving its specific uncertainty. Skipping stages is how teams build things that are technically impressive and commercially irrelevant.
What changed in 2026
AI tools (v0, Cursor, Replit, Bolt) collapsed the cost of a functional prototype from days to under an hour. That changes the calculus in two ways. First, the prototype’s job has shifted: it is no longer about proving you can build it (feasibility is largely free now) and entirely about proving the interaction is worth building. The question a prototype must answer in 2026 is whether users actually want this specific behavior, at this point in their workflow, in this form: a viability and lovability test. Second, lo-fi paper prototyping is now primarily a team alignment tool rather than a speed tool, since hi-fi is almost as fast.
Meta introduced a live vibe-coding round for AI PM candidates: 30 minutes of traditional product sense followed by 30 minutes building a working prototype with an AI coding tool. The test is PM judgment (what to build, what to cut, what to test), not engineering skill. Candidates who spend the session on the wrong feature reveal that their product instincts are weak; candidates who build something testable and immediately articulate what they would learn from it reveal that they understand what prototypes are for. See the vibe-coding round for how to prepare.
Prototyping AI and agentic products
Screen-based prototyping tools do not map cleanly onto AI products. If you are validating a conversational agent, a multi-step autonomous workflow, or an AI-powered recommendation surface, a Figma mock tests the wrong thing. The techniques that work are different.
Wizard of Oz prototyping: A human plays the AI behind the scenes, responding as if the system were live. Users interact normally. You observe where they lose trust, where they re-prompt, where they give up. This reveals interaction failures that no static mock can surface.
Prompt-flow diagrams and conversation scripts: Sketch the agent’s decision tree and the range of responses for each branch. Walk a user through the script verbally. This is faster than building the agent and surfaces gaps in the conversation design before any code is written.
PMs who still reach for Figma to validate an AI feature are testing the UI wrapper, not the agent behavior. Those are different hypotheses requiring different methods. See feasibility is free for the broader context.
The PM’s job during a prototype session
Define the hypothesis in writing before the session starts. State specifically what user behavior would count as validation, not just “they liked it.” Run the session or observe it closely. Debrief immediately while memory is fresh. Make the go/no-go call yourself: that is the output the prototype exists to produce.
Delegating fidelity decisions and test design entirely to design is a gap interviewers probe. So is leaving a prototype session without a named decision. The richest interview story material is a prototype that proved a hypothesis wrong: it shows you know what prototypes are actually for, and that you had the discipline to kill something before it became expensive.