Test Before You Build: How Enterprise Teams Validate New Product Ideas With Real Users Before a Full Build Budget
A clickable prototype can now be produced in days, and almost every innovation team has one. The harder problem is what happens next: a finance partner looks at the demo, asks what it proves, and the accurate answer is that it proves the idea can be drawn. Build budgets are released on evidence about people and decisions, not on evidence about screens. This guide sets out a five-step method for enterprise innovation teams: choose the riskiest assumption, build the smallest artefact that can test it, put it in front of real users, and convert the result into a build, pivot or stop decision.
Why most prototypes fail to move a budget
A prototype answers a narrow question: can this idea be made to look and feel plausible? That is useful, and it is also the question that matters least to the person holding the budget. Their questions are different. Will anyone outside this building use it? Will they use it instead of what they do today? What would we need to believe for this to be worth funding, and how much of that have we checked?
Three patterns explain most of the gap.
- The audience is friendly. Prototypes are often shown to colleagues, sponsors and a handful of existing customers who like the team. Their reaction tells you the idea is understandable. It does not tell you that a stranger with a competing priority will change their behaviour.
- The test measures opinion, not behaviour. "Would you use this?" produces polite answers. Watching someone attempt a task, abandon it, or ask to keep using the prototype produces evidence.
- Nothing was agreed in advance. If the team did not write down what result would count as success before the session, every outcome can be read as encouraging. A funder will notice.
There is also a market reason to be precise. Rapid proof is no longer a distinctive promise: at least one UK consultancy was advertising a short, funded start to working software on its website when we reviewed the market in October 2026. Our reading is that building quickly is now easy to claim, so the scarce thing is evidence that survives scrutiny. That is the part an innovation team can own, whoever does the building.
Innovify's own AI Labs offer is built around the same observation, and we describe it later in this article. First, the method.
Step one: write the decision and find the riskiest assumption
Start with the decision the evidence will serve, written as a sentence a finance partner could sign. For example: "We will release the next tranche of funding for this product if we can show X, and stop if we cannot." If you cannot finish that sentence, you are not ready to test anything.
Then list what must be true for the idea to work. Sort the assumptions into four groups.
- Desirability. Do the intended users have this problem, and do they care enough to change what they do?
- Feasibility. Can we build it with the data, systems and skills we have access to?
- Viability. Can it earn or save enough to justify running it, and does it fit the organisation's commercial model?
- Permission. Are we allowed to do this under our regulatory, legal, security and brand constraints?
Enterprise teams tend to over-test feasibility, because it is the group they are best equipped to examine, and to under-test permission, because it is uncomfortable. In financial services, a perfectly desirable idea can fail at the permission stage, so it belongs in the first list rather than the last.
Pick the one that would hurt most
For each assumption, ask two questions: how bad is it if we are wrong, and how little do we currently know? The assumption that scores worst on both is the riskiest, and it is the one your first test should attack. Teams often choose the assumption they are most excited about. Resist that. The point of an early test is to find out early, and with the least effort, that the idea is wrong, if it is.
A useful discipline is to write the assumption as a claim that could be shown false. "Users want a better way to manage recurring payments" cannot be refuted. "Customers who already manage three or more recurring payments will complete setup of a new one unprompted in under a set time" can. Choose the threshold yourself, and agree it with the sponsor before the test.
Step two: build the smallest artefact that can test it
The artefact should be matched to the assumption, not to the team's skills or the demo it would make. A few options, from lightest to heaviest:
- A narrative or storyboard, for testing whether the problem is recognised at all.
- A concierge or "wizard of Oz" version, where a person performs the service behind a simple front end. It tests whether people want the outcome before you have automated anything.
- A clickable prototype, for testing whether a flow makes sense and where people hesitate.
- A thin working slice, such as one real integration or one live model call, for testing feasibility or whether the output is good enough to rely on.
The common mistake is to build a heavier artefact than the assumption needs. A fully working slice to test whether people want the thing is an expensive way to learn something a concierge version would have shown. The opposite mistake is just as common: testing a feasibility question with a mock-up, which can never tell you whether the model output is good enough or the integration will hold.
For AI-enabled ideas, the artefact usually has to contain a real model response, because the quality of the output is the assumption. A prototype that shows scripted answers tests the interface, not the idea.
Step three: recruit real users and test properly
Real users are the people who would actually use or buy the product, recruited from outside your project team and, where possible, outside your existing goodwill. Define the profile before you recruit: role, situation, current alternative. If the buyer and the user differ, as they often do in enterprise products, test with both.
Keep the test small and observed
Qualitative sessions with a small group are enough to expose most usability problems and to show whether a need is recognised. They are not enough to size a market or to prove a conversion rate, and you should not present them as if they were. Say what the evidence can and cannot support. Funders respond better to a modest claim that is clearly bounded than to a confident one that falls apart in questioning.
Whatever the format, observe behaviour. Ask people to attempt the task you care about, note where they stall, and ask what they would do next. Where the idea allows it, look for commitment rather than approval: a request for a follow-up, a willingness to share real data, an introduction to a colleague, a signed letter of intent where that is appropriate. These are stronger than a score on a scale.
Take the permission question seriously
If your test touches personal data, use it with a lawful basis and tell participants what you are doing. Under UK data protection law, using real customer data in an experiment is still processing. If the idea involves a regulated activity or real consumers, take advice before you test it live. The Financial Conduct Authority describes its Regulatory Sandbox, on a page last updated on 28 October 2026, as a way for firms to test products and services with real consumers, and states that it is not an exemption: firms carrying on regulated activities must still be authorised or registered. Check the current FCA page before relying on any of this. It is outline guidance, not legal or compliance advice.
Step four: turn the results into build, pivot or stop
This is the step most teams skip, and it is the one finance cares about. A test that ends with "the feedback was positive" has not produced a decision.
Before the sessions, write down three thresholds in plain terms:
- Build: the result at which you would ask for the next tranche of funding.
- Pivot: the result that suggests the problem is real but the solution is wrong.
- Stop: the result at which you would close the work and release the people.
After the sessions, compare what happened with what you wrote. Where the result falls between thresholds, say so, and propose a second, narrower test rather than rounding up.
Grade your evidence
It helps to be explicit about how strong the evidence is. Our own working order, which is a framework rather than a standard, runs from weakest to strongest:
- What people say they would do.
- What they do in a prototype, in front of you.
- What they do repeatedly, without prompting, over several days.
- What they commit to: time, data, money or a signed intention.
A funder does not expect level four from a first test. They do expect you to know which level you reached and to say so. Stopping is a legitimate and valuable result. An innovation team that reports a clean stop, with the evidence behind it, has protected the build budget and earned credibility for the next proposal.
Step five: put the evidence pack in front of finance
The output of the method is a short evidence pack. It should fit on a few pages and answer questions in this order.
- The decision requested, in one sentence, using the wording from step one.
- The assumptions tested, with the riskiest one first and the reason it was chosen.
- What was built and why that artefact, including what it could not test.
- Who took part, how they were recruited and how they differ from the real target group.
- What happened, against the thresholds written in advance.
- What remains unknown, stated plainly.
- The recommendation, build, pivot or stop, with the scope and gates for the next stage.
Notice that cost and return figures do not lead the pack. They belong in a later business case, built on the evidence, once the idea has earned it. An innovation lab that puts a revenue forecast ahead of a user test is asking finance to believe an estimate in place of a result.
Where Innovify fits
Innovify is a technology partner with deep expertise in banking, financial services, fintech and insurance, and we design compliance in from day one. We are a technology partner, not a regulated financial institution, so questions of regulatory permission stay with you and your advisers.
Innovify AI Labs is our stated approach to the problem in this article: it lets enterprise teams run several proofs of concept in parallel, test with real users and finish with a business case ready for funding. The method above is how we would expect any team, with us or without us, to make that evidence credible: one decision, one riskiest assumption per test, real users, thresholds agreed first. If you are weighing several ideas against a single budget, running them side by side is what lets the evidence be compared rather than argued.
FAQ
How do you validate a product idea with real users before building it?
Write the funding decision the evidence must support, identify the riskiest assumption behind the idea, and build the smallest artefact that can test it. Then put that artefact in front of people who match your real target users, observe what they do, and compare the result with success thresholds you set beforehand. The output is a build, pivot or stop recommendation.
How many users do we need for enterprise prototype testing?
There is no single number that applies to every test. Small qualitative groups can show whether a need is recognised and where a flow breaks, but they cannot prove market size or conversion. Decide what claim you want to support, then recruit enough of the right users to support that claim and no more.
What is the difference between a prototype and a proof of concept?
A prototype usually tests whether people understand and want an experience, often with scripted or simulated behaviour. A proof of concept tests whether something can actually work, such as an integration or a model output of sufficient quality. Many ideas need both, in the order that tests the riskiest assumption first.
Can we test a regulated financial idea with real consumers?
Sometimes, but it needs advice first. The FCA describes its Regulatory Sandbox as a route for testing with real consumers, and says it does not remove the need for authorisation where a regulated activity is involved. Check the current FCA page and take legal or compliance advice before any live test.
What should an innovation team show finance after a test?
Show the decision requested, the assumption tested, what was built, who took part, what happened against pre-agreed thresholds, what remains unknown and a recommendation. Lead with evidence, not a forecast. A clear stop, supported by results, is as useful to a funder as a clear go.
Conclusion
A prototype is a means of asking a question, and the discipline is to ask the right one. Name the decision, pick the assumption that would hurt most if wrong, build only what can test it, use real users, and agree the thresholds before the sessions begin. Teams that work this way give finance something it can act on, whether the answer is to build, pivot or stop.
