The Product Role When a Prototype Takes an Afternoon

When a working prototype can appear by the end of an afternoon, building stops being the scarce thing. The expensive mistake moves somewhere else. A team can now produce a polished version of an idea nobody needed, and the polish makes the idea harder to question. That shift changes what a product role is for, and it asks more of the people in the role, not less.

Why building stopped being the bottleneck

In most product work, building used to be the slow part. Every idea cost engineering weeks, so teams argued before they built and used those arguments as a filter. When a prototype becomes cheap, the filter weakens. Ideas reach a screen quickly and look finished, and a demo can persuade people who would have pressed much harder on a written proposal.

The mechanism to understand is that a prototype is only evidence when it is built to test something. A prototype that shows what is technically possible answers a question about feasibility. A prototype built to see whether people change their behavior answers a different question, and it needs a different design. Product work now lies mostly in choosing which question a prototype should answer, and in knowing when a result is strong enough to act on. The speed of the builder does not decide that. The clarity of the product person does.

Writing a problem statement that can be wrong

A problem statement names a user, a situation, a cost, and a condition that would show the problem is solved. Its job is to be specific enough that a prototype could disprove it. Compare two versions. "Users want faster support" cannot be wrong, because almost any change could be described as faster. "Support agents ask customers for an order number the system already holds, and each chat pauses for that step" can be checked. A team can see whether the step happens, how often it appears in the transcripts on hand, and whether removing it changes how long the conversation takes.

Write the statement before anyone opens a design tool. Keep it to three or four sentences. If the person who has the problem cannot be named, the team has a hypothesis about a solution, which is a different thing and worth labeling as one. Engineers who receive a sharp statement can often propose a test in the same meeting, and that speed is the real benefit of the discipline.

Testing assumptions before the first build

Every product idea rests on a handful of assumptions. The user has the problem. It happens often enough to matter. The current workaround is painful. The proposed change fits how people already work. List them, then mark the one that would end the idea if it were false. That assumption deserves the first test, because a cheap test that kills a bad idea saves more than a clever test that confirms a good one.

Many tests need no code. Structured interviews with specific questions reveal more than asking whether someone would use a feature. Ask them to describe the last time the problem happened, what they did next, and what it cost them. A fake door, a page that describes a feature and measures how many people try to open it, can test interest. A manual version, where a person does the work behind the screen, tests whether the output is useful before anyone automates it. Each method has limits. Interviews can flatter, fake doors measure curiosity rather than need, and manual versions can hide the real cost of the service. Write down what each method cannot show.

Working with engineers who prototype quickly

Engineers who can build a prototype in an afternoon need three things from product work: a clear question, a definition of success, and a time limit. Without the first, the prototype answers whatever question the builder finds most interesting. Without the second, the team argues about the result after seeing it, when the argument is already expensive. Without the third, the prototype grows into something nobody planned to maintain.

The most common trap is that a fast prototype becomes production code by accident. Agree at the start whether it will be thrown away. If it will be kept, plan the parts a prototype usually skips: error handling, data privacy, logging and monitoring. Then ask the engineer what they would change if the thing were built properly. Their answer is often the best early preview of the real cost, and it can go into the roadmap without any extra research.

Practice: a one-page test plan

Take a feature idea that has been worked on, or one heard in a meeting. Write the problem statement in three sentences. List three assumptions and choose the one that would end the idea if it were false. Design the cheapest test for that assumption, and write down two results in advance: the one that would make the team stop and the one that would make it continue. Keep the whole plan to a page.

Show the plan to someone who builds the product and ask one question: which part of this test would you not trust? Their answer shows where the design is weak. Revise the plan, then decide whether the test could run this week without writing production code. If it could, run it and write up what was learned in the same format. Product judgment is mostly the habit of making an idea risk something before it costs a team a quarter.