Prototype
Make it real enough to learn from, no more.
A prototype is a question, not a deliverable. It exists to answer something specific: would users understand this flow, does this perform at scale, is the data shape workable. Once it has answered, it has done its job.
The lightest prototype that answers the question is the right prototype. Spend the time you save on building more of them. One prototype is a position. Two or three is a comparison, which is how teams actually learn.
What you do
Pick the lightest artifact that answers the question
A piece of paper, a Figma flow, a working code spike, a prompt in test mode. Choose by what the question demands, not by what feels impressive.
Build several
One prototype is a position. Two or three is a comparison, which is how teams actually learn.
Write down what each one is supposed to teach
"This proves users find X" or "This validates Y is technically possible." Without that sentence, you are decorating, not prototyping.
Treat it as disposable
A prototype that feels too precious to change has already become a commitment.
What you produce
Working artifacts
Paper sketches, clickable mockups, agent prototypes, code spikes. Whatever the question demanded.
A "what this is designed to teach" note
One paragraph per prototype, written before testing, not as a justification after.
Honest assumptions on the table
The bets you are making that the prototype is meant to confirm, challenge, or change.
AI makes prototyping lighter.
This is where the AI shift is easiest to feel. A working clickable flow, a backend spike, or a draft of an agent can often move from idea to “real enough to test” much faster than before.
That changes the team’s options. Where teams used to debate which one idea to prototype, the better move may be to build three and let users show you which one is worth carrying forward. Spend the saved time on more variants, not on polishing one.
One caveat: AI-built prototypes hide cost. The thing that looks like a working flow may have brittle plumbing. Use AI prototypes to test desirability quickly, and validate feasibility separately, on the same artifact or a parallel spike.
Watch for
Patterns that can make the work look farther along than it is.
Prototype-as-spec
Treating the prototype like a design doc the engineers can build from. It is not. It is a question. Specs come later.
Polishing past usefulness
The prototype answered the question two days ago, and the team is still polishing. Move the learning forward.
One prototype, one direction
Comparison helps the team see whether an option is strong or simply familiar.
Skipping the "what this teaches" note
Without it, the test will be vague, the result will be ambiguous, and the team will fall back to opinion.
Artifacts real enough to provoke an honest reaction from a real human, plus a clear list of what each one is meant to teach.