Product Discovery Explained: What to Do Before You Build Software

Product discovery is the work you do before committing significant time and money to building software.

Its purpose is not to prove that the original idea was correct.

Its purpose is to reduce uncertainty about:

• the problem;
• the users;
• the value;
• the constraints;
• the solution direction;
• the economics;
• the delivery risk.

A successful discovery can end with “build this,” “test this first,” “buy rather than build,” or “do not proceed.”

All four can be valuable outcomes.

What product discovery actually means

A useful definition is:

Product discovery is a structured process for gathering enough evidence to make a better product investment decision.

That evidence usually spans five questions:

1. Is there a real problem worth solving?
2. Do identifiable users experience it?
3. Would solving it create enough value?
4. Is the proposed direction viable and feasible?
5. What is the smallest next investment that meaningfully reduces uncertainty?

The GOV.UK Service Manual uses a similar principle for digital services: before committing to build, understand the problem, users, constraints and opportunities, and decide whether further investment is justified.

Discovery is not requirements gathering

Traditional requirements gathering often begins with an assumed solution.

For example:

We need a mobile app with login, notifications, maps and an admin dashboard.

Discovery reframes the starting point:

What are users trying to achieve, why is the current experience failing, and which intervention is most likely to improve it?

That may still produce an app.

It may also reveal that the right solution is:

• a better web journey;
• integration between existing systems;
• workflow automation;
• a configured SaaS product;
• process redesign;
• a much smaller product than originally imagined.

This is why discovery can save money before a line of production code is written.

The Abrasim Discovery Model: Problem → User → Value → Evidence → Option → Decision

1. Problem

Define the problem without embedding the solution.

Weak:

“We need an AI customer service platform.”

Stronger:

“Customers wait too long for answers to common support questions, while agents spend 35% of their time retrieving information from several internal systems.”

The stronger statement can be measured and admits more than one solution.

2. User

Identify who experiences the problem.

This may include:

• customers;
• employees;
• managers;
• partners;
• administrators;
• suppliers;
• regulators.

Understand:

• what they are trying to accomplish;
• how they work today;
• where friction appears;
• what alternatives they use;
• what matters most to them.

Do not assume the buyer and user are the same person in B2B products.

3. Value

A product needs an economic reason to exist.

Value may come from:

• new revenue;
• improved conversion;
• reduced cost;
• lower risk;
• faster cycle time;
• customer retention;
• strategic capability;
• better employee productivity.

Estimate the size of the problem before estimating the build.

4. Evidence

Gather enough evidence to challenge assumptions.

Sources can include:

• analytics;
• search behaviour;
• interviews;
• observation;
• support data;
• sales calls;
• competitor products;
• operational data;
• process maps;
• existing technology;
• lightweight prototypes.

Discovery is not “ask five people whether they like the idea.”

5. Options

Explore more than one intervention.

Options might include:

• buy;
• configure;
• integrate;
• automate;
• build;
• change the process;
• do nothing.

This prevents the initial idea from becoming the only idea.

6. Decision

The output should state what to do next and why.

A good discovery creates a decision, not a pile of workshop photographs.

What should happen during product discovery?

The exact work depends on the uncertainty.

A practical discovery may include:

Stakeholder interviews

Clarify business goals, constraints and assumptions.

User research

Understand real behaviour and needs.

Journey or workflow mapping

See where the product fits into a wider process.

Market and alternative analysis

Understand what users do instead today.

Data review

Quantify the problem where possible.

Technical discovery

Assess architecture, integrations, data, security and platform constraints.

Prototyping

Test risky interaction or workflow assumptions before full build.

Commercial modelling

Estimate the value, costs and operating implications.

Prioritisation

Decide which capabilities belong in the first testable release.

How long should product discovery take?

There is no universal duration.

The GOV.UK discovery guidance notes that discovery length should follow the purpose and uncertainty of the problem rather than a fixed ritual.

A focused commercial product sprint may take days or a few weeks.

A complex enterprise service involving several user groups, legacy systems and regulation may require longer.

The key is to define the decision discovery must support.

When is discovery finished?

Discovery is finished when the team has enough evidence to make the next investment decision.

That means you should be able to explain:

• the problem;
• target users;
• evidence;
• opportunity size;
• main risks;
• recommended direction;
• what remains uncertain;
• next experiment or MVP;
• rough delivery implications.

If the only output is a feature list, discovery has collapsed back into requirements gathering.

Discovery should identify reasons not to build

This is an important quality test.

A discovery process is weak if it cannot conclude that the proposed product should not be built.

Reasons to stop may include:

• the problem is not important enough;
• users already have an acceptable alternative;
• the economics do not work;
• the organisation lacks the operating capability;
• data is unavailable;
• legal or security risk is disproportionate;
• an existing platform solves the need adequately.

Stopping can be one of the highest-return product decisions available.

Discovery versus prototype

Discovery is the broader learning process.

A prototype is one tool inside discovery.

You may prototype:

• a critical screen;
• a workflow;
• an AI interaction;
• a service process;
• a technical integration.

The purpose is to test uncertainty, not create a visually impressive artefact for its own sake.

Discovery versus MVP

An MVP is typically a live or operational product version designed to test value with real users.

Discovery should help decide:

• whether an MVP is justified;
• which assumption it should test;
• what belongs in scope;
• what should deliberately be excluded.

Building an MVP without discovery can produce a smaller version of the wrong product.

Discovery for internal software

The same principles apply to systems built for employees.

Internal product ideas often arrive as:

• “we need a dashboard”;
• “we need a CRM”;
• “we need an app for field staff”;
• “we need an AI assistant.”

Map the work first.

You may find that the real problem is fragmented data, duplicated steps or unclear ownership rather than missing software.

South African product realities

Discovery should reflect the environment the product will operate in.

Depending on the audience, consider:

• mobile device mix;
• connectivity;
• data costs;
• payment methods;
• local integrations;
• POPIA and data governance;
• language;
• operational support;
• regional logistics;
• existing digital literacy;
• offline workflows.

These should be researched for the actual user group rather than assumed as generic “African market” traits.

What should discovery deliver?

A practical commercial package may include:

• problem definition;
• user/use-case model;
• evidence summary;
• journey/workflow map;
• opportunity sizing;
• solution options;
• risk register;
• recommended MVP or next test;
• architecture considerations;
• delivery roadmap;
• build/buy/stop recommendation.

That is the basis of Abrasim's Product Opportunity Sprint.

What happens after discovery?

The next artefact is usually not a detailed project plan.

First, the product direction should be expressed as outcomes, priorities and learning horizons.

Read Product Roadmap vs Project Plan: Why Confusing Them Gets Expensive.

For a broader validation model, see How to Validate a Digital Product Idea Before Spending on Development.

Sources and further reading

• GOV.UK Service Manual: How the discovery phase works
• GOV.UK Service Manual: User research in discovery
• GOV.UK Service Manual: Learning about users and their needs