How to Validate a Digital Product Idea Before Spending on Development

The cheapest time to discover that a digital product idea is weak is before the organisation has built it.

Product validation is the process of replacing assumptions with enough evidence to decide whether to build, buy, test further, change direction or stop.

It does not require certainty. It requires progressively better evidence.

Why good ideas still fail

A product idea can sound compelling in a strategy meeting and still fail because:

• the problem is not painful enough;
• the intended users behave differently from expected;
• the market already has an acceptable alternative;
• willingness to pay is weaker than interest;
• the organisation cannot reach the users economically;
• the product depends on data or integrations that are not feasible;
• adoption requires a workflow change the business underestimated;
• the solution is too expensive relative to the value created.

Development converts these assumptions into cost.

Discovery converts them into evidence first.

The Abrasim evidence ladder

We validate product opportunities through five levels:

Problem → User → Market → Solution → Delivery

Each level asks a different question.

1. Is the problem real?

Start by defining the problem without describing the proposed product.

Weak framing:

We need an AI-powered customer portal.

Stronger framing:

Business customers cannot see accurate order status without contacting an account manager, creating service cost and avoidable delay.

The stronger statement can be investigated without assuming the answer.

Useful evidence includes:

• support tickets;
• customer complaints;
• search behaviour;
• sales objections;
• manual workarounds;
• call-centre data;
• operational delay;
• churn reasons;
• employee interviews.

GOV.UK’s Service Manual makes the same general discovery principle explicit: understand the problem before committing to building a service.

2. Do the intended users care enough?

A problem can exist without being important enough to change behaviour.

Research should establish:

• who experiences the problem;
• how frequently;
• what they do today;
• what the workaround costs;
• what a better outcome would be worth;
• who makes the buying or adoption decision.

Avoid asking:

Would you use an app that solved this?

People are generous with hypothetical enthusiasm.

Ask about actual behaviour:

• What happened the last time you had this problem?
• What did you do?
• How long did it take?
• What did it cost?
• Which alternatives did you try?

Past behaviour is usually better evidence than polite predictions.

3. Is there a viable market or internal business case?

For external products, examine:

• addressable customer groups;
• alternative solutions;
• pricing patterns;
• distribution channels;
• buying process;
• switching costs;
• market concentration;
• regulatory constraints.

For internal products, the “market” is the business case.

Assess:

• number of users;
• current operating cost;
• time saved;
• error reduction;
• impact on revenue or service;
• cost to deploy and support;
• opportunity cost.

An internal tool used by 40 people can be an excellent investment if it removes an expensive bottleneck.

A public product with thousands of potential users can still be poor if acquisition economics do not work.

4. Does the solution direction work?

Only after the problem is understood should solution testing become more concrete.

Useful methods include:

Paper or low-fidelity prototype

Test structure and workflow cheaply.

Clickable prototype

Test whether users understand how to complete the key journey.

Concierge test

Deliver the proposed outcome manually before automating it.

Landing-page demand test

Test whether a proposition earns real interest from the intended audience.

Wizard-of-Oz test

Present an automated-looking experience while humans perform some work behind the scenes, where appropriate and ethical.

Technical spike

Test a high-risk integration, performance or AI assumption before building the whole system.

The goal is to test the riskiest assumptions using the cheapest credible method.

5. Can it be delivered and operated?

A desirable product can still be a bad investment if delivery economics do not work.

Assess:

• build vs buy options;
• integrations;
• data availability;
• security;
• privacy;
• performance;
• support model;
• ongoing product ownership;
• operating cost;
• vendor dependencies;
• skills required.

For major technology choices, use the Build vs Buy Software decision framework.

Validate the riskiest assumption first

Teams often validate what is easiest rather than what is most dangerous.

If the biggest risk is willingness to pay, a beautiful prototype does not answer the question.

If the biggest risk is a legacy-system integration, interviewing 30 users does not answer the question.

If the biggest risk is whether the problem exists at all, technical architecture is premature.

Write the assumptions down, rank them by:

• importance;
• uncertainty;
• cost if wrong.

Then design evidence around the highest-risk assumptions.

Evidence strength matters

Not all validation evidence is equal.

A useful hierarchy is:

Weak evidence

• internal opinions;
• trend articles;
• competitor activity;
• user statements about hypothetical behaviour.

Moderate evidence

• repeated qualitative interviews;
• observed workarounds;
• search demand;
• prototype usability;
• existing operational data.

Stronger evidence

• deposits or paid pilots;
• signed commitments;
• repeat usage;
• behavioural experiments;
• measurable workflow improvement;
• conversion against a real proposition.

You do not always need the strongest evidence before moving forward.

You need evidence proportional to the size and reversibility of the investment.

Define the decision before the research

Validation becomes endless when nobody knows what evidence is sufficient.

Before starting, define the decision you expect to make.

For example:

We will move to an MVP if at least two of the three priority customer groups demonstrate the problem, prototype testing shows the core workflow is understandable, and the technical spike confirms the required integration is feasible within the expected cost range.

That gives discovery an end point.

Product validation for AI products

AI adds a few specific assumptions to test.

Quality

Is model performance good enough for the actual task?

Variability

What happens when the output is uncertain or inconsistent?

Evaluation

Can you define examples of acceptable and unacceptable performance?

Human control

Where should a person review or override the system?

Cost

What will inference, retrieval and monitoring cost at expected scale?

Data rights

Can the required information be used safely and lawfully?

An AI demo that works on five hand-picked examples is not product validation.

Common validation mistakes

Building the MVP too early

An MVP is still software. If the riskiest assumption can be tested with a prototype or manual service, start there.

Asking users to design the product

Users are excellent sources of problems, behaviours and context. Product teams still need to design and prioritise solutions.

Treating competitor existence as proof of demand

A competitor proves somebody is trying to serve the market. It does not prove your proposition or economics work.

Researching forever

Discovery should reduce uncertainty enough for a decision, not eliminate every unknown.

Ignoring the commercial model

High user enthusiasm with no viable acquisition, pricing or operating model is not validation.

A practical validation plan

For a new B2B software idea, an early plan might be:

1. Review existing support, sales and operational evidence.
2. Interview 8 to 12 representative users around the real workflow.
3. Map alternatives and switching behaviour.
4. Define the riskiest assumptions.
5. Prototype the core journey.
6. Test the prototype with likely users.
7. Run one technical spike for the highest-risk dependency.
8. Build a simple economic model.
9. Decide build, buy, test further or stop.

The exact numbers and methods should fit the problem. There is no ritual sample size that makes discovery automatically valid.

How do you know validation is complete?

You are ready to move forward when leadership can answer:

• Who has the problem?
• How important is it?
• What happens today?
• What evidence shows a better solution is wanted?
• Which solution direction is most promising?
• What are the largest remaining risks?
• Can the organisation deliver and operate it?
• What will the next investment test?

If those answers are still vague, building more software is unlikely to improve them.

Where a Product Opportunity Sprint fits

A Product Opportunity Sprint packages this work into a focused decision engagement when an organisation has an opportunity but does not yet have enough evidence to justify development.

The output should not automatically be “build an MVP”.

Sometimes the most valuable conclusion is buy, integrate, run another experiment or stop.

The product principle

Commit code after you have earned the right to commit capital.

Discovery is not a delay before development. It is how the organisation avoids making development the most expensive form of research.

Sources and further reading

• GOV.UK Service Manual: How the discovery phase works
• GOV.UK Service Manual: Learning about users and their needs
• Atlassian: Product discovery
• GOV.UK Service Manual: Deciding on priorities