Answer in brief
Before building a full product, write down the assumptions it depends on and pick the one that would do most damage if false and has the least evidence behind it. Turn it into a statement that can fail, choose the smallest prototype that could disprove it, such as a paper sketch, a clickable mock-up or a service run by hand, and fix the pass and fail criteria before testing. Then act on the result: stop, test again or build.
A platform is a stack of guesses with a login screen
A plan for a new platform reads like a list of facts: customers need this, they will switch from what they use now, the data can be obtained, the partner will integrate, the price covers the cost. None of these is a fact yet. Each is an assumption, and the product works only if nearly all of them hold.
Building the full product is one way to find out. It is also the slowest and dearest way, because it tests every assumption at the same moment and delivers the answer after the budget is spent. Kara Pernice of Nielsen Norman Group made the comparison in 2016: throwing away code is costly, and throwing away a prototype, especially a paper one, is not.
Faster tools do not change this. In a March 2026 article for the same firm, Sara Paul observes that low-code platforms and AI assistants have made building quicker, yet what makes a product risky is how much it costs to be wrong, not how much it costs to build. A wrong product built in a week is still the wrong product.
List what must be true, then rank it by damage
Start by writing the assumptions down, one per line. A useful opening is “for this to work, it must be true that…”. Sort them roughly into four kinds: people want it, people can use it, we can build and run it, and it pays for itself within the rules that apply.
Then give each line two marks: how bad it would be if the assumption were false, and how much evidence you already hold. The GOV.UK Service Manual calls identifying and testing the riskiest assumptions a crucial part of its alpha phase and adds that what they are depends on the service. Paul offers a practical rule: risk tends to be inversely related to existing evidence.
The manual gives two examples. A team hoping to reduce loneliness with an online information service should first learn how the people concerned receive information now, because if they do not use the internet they are unlikely to use the service. And the team behind Register to vote saw that everything hung on an interface to the registration systems of more than 400 local councils, so its alpha concentrated on that.
Turn the dangerous assumption into a sentence that can fail
An assumption becomes testable when it names who, what and how you will know. Nielsen Norman Group suggests a template for the first question, whether anyone values the offer at all: we believe a certain proposition is valuable to a certain audience, and we will know this is true when we observe a named behaviour during testing.
Here is an illustration with invented details. A bakery chain is considering a pre-order platform. The dangerous assumption is that regular customers will order the evening before instead of walking in. As a testable sentence: we believe pre-ordering is valuable to weekday regulars, and we will know when at least a third of those we invite place a second order within two weeks without a reminder. The proportion illustrates a criterion; it is not a benchmark.
Write down, before any test, what each outcome will look like. The NN/g article distinguishes three: supported, partially supported and not supported. Fixing them in advance matters more than the exact figures, because afterwards almost any result can be argued into a success by someone who has already fallen for the idea.
Pick the smallest test that could prove you wrong
The form of the prototype follows from the kind of doubt. If the question is whether people understand and want the offer, NN/g lists three common formats: paper sketches, a clickable mock-up, and the Wizard of Oz method, in which the product appears automated while a person does the work behind the scenes. The bakery could take pre-orders through a simple form and fulfil them by hand for a fortnight.
If the doubt is technical, the smallest test is a narrow piece of real engineering: one connection to the outside system everything depends on, as with Register to vote, or a trial of whether the data is good enough. If the doubt is legal or contractual, the test may be a conversation: the Service Manual suggests spending part of alpha on how feasible it is to resolve a legislative constraint.
In each case the manual's advice is the same: you need not prototype the whole journey; focus on the areas you expect to be most challenging and do the minimum you need to test your riskiest assumptions. Nesta's prototyping framework makes the point with a chair: in the first phase you test the materials, the length of the legs and the angle of the seat, not the finished chair.
Rough on purpose: how much polish a prototype needs
A prototype should be as rough as the question allows. Pernice lists what low fidelity buys: less time spent preparing and more on the design itself, changes that can be made between sessions, participants who feel freer to criticise something visibly unfinished, designers less attached to their work, and stakeholders who can see that it is not ready to ship.
Roughness has a floor, though. If people cannot work out how to use the thing, Paul warns, the test becomes a test of the interface and not of the idea. The offer has to be clear enough that a refusal means “I do not want this” and not “I did not understand this”. Real content, real prices and realistic wording matter more than colours.
Whatever its form, treat the prototype as disposable. The Service Manual tells teams to build things just complex enough to test ideas, not production-quality code, and to expect to throw away the code, and many of the ideas, at the end of alpha. A prototype polished for a month is hard to discard, which is one more reason to keep it rough.
Evidence is what people do, not what they say they like
A prototype test produces three kinds of signal, and they are not worth the same. Praise is the weakest: people are kind to someone showing them an idea. A stated intention, “I would use this”, is a little better. Behaviour is the strongest: the person completes the task unaided, comes back a second time, pays a deposit or hands over the data the service needs.
This ranking is not eccentric. The NN/g template asks for a behavioural signal in its second half, and Nesta's framework tells teams to watch people using prototypes as well as asking them, because what they say, think or will do is often different from how they actually interact. Arrange the test so that there is something to do, not only something to look at.
Be equally strict about who takes part. Colleagues, friends and existing fans are not the audience named in the hypothesis. A few sessions with the right people can show whether the idea is understood and wanted; they cannot tell you how large the market is, and they should not be reported as if they did.
Stop, repeat or build: write the rule before the results arrive
The purpose of the exercise is a decision. For the Service Manual, alpha is finished when the prototype is substantial enough to help you decide whether to move on. To continue, a team needs to be confident that it can create something that meets users' needs and is cost-effective, and that the budget and people exist. If it is not confident, the manual says, it could stop altogether or repeat an earlier phase.
Nesta describes the same fork with three outcomes: enough insight to draw up the final plan; gaps that call for another round with a revised specification; or so much to rethink that the team returns to the proof of concept. An unsupported result is not automatically the end. NN/g advises asking first whether the opportunity failed or only this approach to it: the wrong audience, the wrong channel, a confusing design.
Set a limit on time as well as on criteria. Government alphas, according to the manual, tend to last between six and eight weeks; a small company checking one assumption should need far less, and the limit belongs on paper before work starts. An open-ended prototype quietly becomes the product, with no decision ever taken.
What a passed test still does not prove
A prototype answers the question it was built for and no other. It can show that people understand and want an offer. It cannot show that they will keep using it, that the service performs under load or that the economics hold at scale. Nesta is explicit that prototyping is not an alternative to piloting: it comes first and produces a better specification for the pilot.
The next step, in NN/g's sequence, is a small live version released to real users, which lets a team measure engagement, retention and conversion. The article lists safeguards for that stage: limit exposure to a segment or to invited users, show people what the product will do before asking them to act, label it as a beta or a pilot, and monitor it in real time.
Two cautions belong here. A test in which a person quietly does the machine's work must still be honest about what happens to people's data and money. And a prototype that passed should be rebuilt, not promoted: the shortcuts that made it cheap are the reason it is not safe to run a business on.
Practical checklist
- Write every assumption the product depends on as one plain sentence beginning “it must be true that”.
- Mark each one for damage if false and for evidence held, and choose the line that scores worst on both.
- Rewrite it as a hypothesis that names the audience, the behaviour you expect and the result that would count as failure.
- Build the roughest prototype that can produce that behaviour, and try it with people from the intended audience.
- Agree the time limit and the stop, repeat or build rule in writing before the first session takes place.
Questions and answers
What is the riskiest assumption in a product idea?
It is the belief the whole plan depends on that has the least evidence behind it and would cause the most damage if it turned out to be false. It may concern demand, usability, technology, cost or law. The GOV.UK Service Manual notes that it differs from one service to another, which is why it has to be identified deliberately and cannot be copied from someone else's project.
How is a prototype different from a minimum viable product?
Usage varies, so it helps to say what you mean. Nielsen Norman Group treats an MVP as an experiment that can take the form of a prototype, such as paper, a clickable mock-up or a manually operated service, or of live code released to real users. Prototype forms suit the question of whether people value the offer. Live code suits the later question of whether a specific solution attracts and keeps its users.
How long should testing an assumption with a prototype take?
There is no fixed length, but there should be a fixed limit. The Service Manual says alphas in government tend to last between six and eight weeks, and Nesta describes prototyping as a low-cost process with short to medium timescales compared with a pilot. A small business checking a single assumption can usually set a much shorter period. What matters is that the limit is agreed before the work begins.
What should we do when the prototype test fails?
First find out what failed. NN/g advises against abandoning an idea on a single unsupported result and suggests examining the design, the technical approach and outside factors such as reaching the wrong audience. If the right people understood the offer and still did not want it, stopping is a legitimate and inexpensive outcome. The Service Manual lists stopping altogether among the acceptable ways for an alpha to end.
Can prototype code be reused in the final product?
Plan not to. The Service Manual tells teams to build prototypes that are just complex enough to test ideas, not production-quality code, and to expect to throw the code away when alpha ends. A prototype leaves out security, error handling and performance work on purpose, and carrying it into production carries those gaps along. Keep what was learned, the content and the design decisions, and build again properly.