Product Discovery

We test the problem, segment, alternatives, value and willingness to pay before you build an MVP. The output is evidence, risks and a decision on the next experiment.

Discuss your project

Overview

Product Discovery: the stage in short

Discovery exists to make a specific decision before development. We test the team's underlying assumptions and gather evidence about real customer behavior, alternatives and the next commitment, not about general interest in the idea.

Focus: the most expensive risk
Data: interviews and behavior
Output: a decision and the next test
Possible outcome: continue, change or stop

If every possible research result still leads to development that was approved in advance, Discovery becomes a formality.

In plain words

What it is and why it matters

What it is: Before development, we check whether customers have the problem the product solves, what they use today and whether they will pay. The outcome: continue, change the idea or stop.
Who it is for: A founder or IT team with an idea for a new product or a move into a new segment, when it is unclear which risk to test first and development will be expensive.
What you get: A map of hypotheses and risks, interview data, a map of competitors and alternatives, a test of value and the pricing model, an evidence board with sources and a decision on the next step.
Where to start: Describe the idea, who it is for and what you already know about customers. We will pinpoint the costliest risk and suggest a way to test it.

Solution architecture

How Product Discovery works with the 5D methodology

Each stage reduces uncertainty around one decision and ends with a testable next step.

Discover

Capture hypotheses

We define the problem, segment, alternatives, value, willingness to pay and the decision the team will make based on the results.

Design

Choose how to test

We pick interviews, a message test, a landing page, a concierge test, a pre-order, a prototype or a technical proof of concept.

Deploy

Get a market signal

We test the hypothesis with target users and record behavior, commitments and alternative explanations.

Drive

Collect evidence

We bring the facts together on an evidence board, assess signal strength and update the product model.

Dominate

Make a decision

We move on to a prototype or MVP, narrow the segment, change the offer, run a new test or stop investing.

Unit economics and ROI

How Discovery saves your budget

Discovery does not guarantee product-market fit. Its economic effect is catching a weak hypothesis early, before it turns into months of development, complex architecture and commitments to the market.

The team first invests in the cheapest way to get a strong signal. The result can be a move to a prototype or a deliberate decision to stop the product. Both protect the next budget.

What we protect: development budget
Key asset: verifiable evidence
Next investment: after the decision
Criterion: a change in behavior or a commitment

Result

What you get

Discovery ends with a decision map and the scope of the next experiment, not a lengthy research report.

A map of hypotheses and risks
Segmentation and a priority ICP
Interview and observation data
A map of competitors and alternatives
A test of value and monetization
An evidence board with sources and signal strength
A decision on the next stage
The scope of the next experiment

Comparison of approaches

Discovery or straight to development

Where to start depends on whether the problem, the segment and the client's readiness to act are confirmed.

Approach	What it tests	Main risk	Output
Develop an MVP right away	Reaction to a finished product	Testing a weak hypothesis is expensive	A working version
Run general research	Attitude to the category	Interest without commitment	An analytical report
Product Discovery	A specific decision and behavior	Requires readiness to change the original idea	Evidence and the next test

Limitations and risks

When Discovery will not help

The stage is useful only when the team is ready to change its decision based on the results.

Development is already approved with no alternatives

If scope, segment and budget cannot be revised, the research will not change what you do.

You only need a visual prototype

Once the problem and scenario are confirmed, you can go straight to UX testing.

No access to users

Without observable behavior and strong market signals, conclusions will remain guesswork.

A good fit

When the stage fits

You have an idea but do not know which risk to test first
The team is choosing a segment or monetization model
A new product requires expensive development
An existing product has lost traction or is entering a new segment

Not a fit

When to start with a different step

The problem and scenario are already confirmed
You need a technical experiment with a clear question
Decisions cannot change based on research results
No access to target users and their behavior

Terms in plain words

Hypothesis: an assumption that could change the team's decision
ICP: the customer segment for which the problem matters most
Evidence board: a map of facts, sources and decisions made
Strong signal: an action or commitment, not just a positive opinion
Hard Stop: a condition, agreed in advance, for stopping investment
Product-market fit: The state where a chosen market segment consistently needs the product. It is confirmed by customer behavior after launch, not by research.
Concierge test: A test where the team delivers the future product's service by hand to see real demand before writing any code.
Traction: Measurable progress in the market: growth in customers, usage or revenue. Losing it is a reason to recheck the segment and the offer.

For IT products

Product Discovery for SaaS, services and apps

Product Discovery for an IT product answers one question: is it worth building an MVP, and at what scope. The way we test depends on the product type, because SaaS, a mobile app and a B2B service carry different main risks.

SaaS: willingness to pay for a subscription

For SaaS the main risk is usually not features but whether clients will pay on a recurring basis. We check how the client solves the task today, with spreadsheets, a contractor or another service, how much time it takes them and what will be the first value in the product. A strong signal is a pre-order, a letter of intent or agreement to a paid pilot.

Mobile app: scenario frequency

For mobile apps we check how often the task arises and whether it matters enough for a user to install yet another app. We use interviews, message tests and a clickable prototype, and check whether the problem is already solved in WhatsApp, Kaspi or an existing service. Without a recurring scenario, retention after install will be low.

B2B service: who decides

In B2B the user, the department head and the person who pays are different people. Discovery studies each of them separately: what pain the user feels, which metric the department head is accountable for, what conditions finance and procurement set. In small Kazakhstan companies the business owner often makes the decision, so we test the owner's arguments first.

A new segment for an existing product

When a working product enters a new segment or loses traction, Discovery helps avoid carrying old assumptions over blindly. We compare the behavior of current and new clients, look for reasons for usage and churn, and check whether the offer, onboarding or monetization model needs to change before development is restructured.

How it works

How to test a product hypothesis before building an MVP

Testing a product hypothesis is a series of low-cost experiments, each answering one question and ending in a decision. Below is how we run Product Discovery before MVP development in Kazakhstan and which artifacts the team keeps.

Assumption map and the costliest risk

We start by writing down every assumption the idea rests on: who the client is, what problem they have, what they use now, why they would switch and how much they are willing to pay. Each assumption is scored on two axes: how confident we are and what we lose if we are wrong. We work first on what is both uncertain and costly. The artifact is a hypothesis map with the wording, test method and success criterion written down before testing. Without a pre-recorded criterion any result is easy to read in favor of the idea, and Discovery turns into confirming a decision already made.

Interviews about past behavior

We build interviews around what a person has already done, not what they would do. We ask when the problem last came up, how they solved it, how much time and money it took and what they did not like. We do not ask “would you buy it?” or “do you like the idea?”: polite agreement is not a signal. Interviews are held in Russian or Kazakh, whichever the respondent prefers. In B2B we keep in mind that the Kazakhstan market is small: we find respondents through referrals and professional communities and treat each interview with care, because going back to the same person is harder.

Experiments with commitment

An opinion is not a signal, so after interviews we move to tests that require action. This can be a landing page with a price and a sign-up form, a message test in ads, a concierge test where the team delivers the service by hand, a pre-order or a paid pilot. For each experiment we define in advance which action counts as a strong signal: leaving contact details, booking a meeting, making a prepayment. If the product targets the Kazakhstan market, we also test familiar payment methods such as Kaspi, since the payment barrier can matter more than features. Results are recorded right away together with the experiment conditions so they can be compared.

Competitors and client alternatives

The main competitor of a new product is often not another service but a habitual way of working: a spreadsheet, a WhatsApp chat, an outsourced accountant or an employee doing the work by hand. We build a map of alternatives: what the client uses now, what they like about it, what switching costs them and which local players already exist in Kazakhstan. We also look at international products available here but not adapted to the local language, payments and data requirements. The artifact is a map of alternatives with the reasons a client might switch and the reasons they would stay with the current solution. Interviews often reveal alternatives the team missed, so the map keeps updating.

Evidence board and team decision

All facts go into an evidence board: hypothesis, source, what exactly was observed, signal strength and alternative explanations. It is not a hundred-page report but a working board that shows which assumptions are confirmed, which are refuted and which are still open. At the final meeting the team makes one of the decisions: move to a prototype or MVP, narrow the segment, change the offer, run a new test or stop investing. The stop condition, the Hard Stop, is agreed at the start so the decision is made on data rather than attachment to the idea. The board is kept from day one rather than assembled at the end.

MVP scope based on the findings

Once a hypothesis is confirmed, Discovery results become the MVP brief: which scenario delivers first value, what can be done manually and what must be automated, which metrics will show that the product works. This way MVP development in Kazakhstan starts with a narrow scope and a clear success criterion rather than a list of every feature. We also record market expectations: an interface in Russian and Kazakh, payments through local services and, if the product collects personal data, where it will be stored. The scope goes to the development team together with the evidence board so decisions are not lost.

Step by step

Product Discovery: five steps to an MVP decision

Below is how Discovery runs in practice for an IT company or a product founder: who takes part, what happens and which artifact remains after each step.

Kick-off session with founders

We meet the founders and key product people. We write down the idea, the target segment, known facts and which decision Discovery must lead to. We also agree on the stop condition and on who has the right to make the final decision. The output is a one-page brief with the research question and an agreed success criterion.

Recruiting respondents

We define the respondent profile and find people through the founders' network, referrals, professional communities and current clients. For B2B we set the roles in advance: user, department head, finance, business owner. We prepare an interview guide in Russian and Kazakh. The artifact is a list of booked interviews and a guide tested in one or two trial conversations. If the right people are hard to reach, we revise the profile or search channel with the founders right away.

Interviews and observation

We run interviews about past behavior and, where possible, watch how the person solves the task today: opening a spreadsheet, writing in a chat, calling a contractor. Founders join at least some of the conversations to hear the client directly. After each interview we record facts and quotes the same day. The output is transcripts, fact cards and first patterns across segments.

Experiment that requires action

Based on the interviews we pick the cheapest way to get a strong signal: a landing page, a message test, a concierge scenario, a pre-order or a paid pilot. We build the experiment, run it on the target audience and track behavior, not opinions. The artifact is the experiment results together with the conditions under which it ran and an assessment of signal strength. If the signal is weak, we change one parameter and repeat rather than starting over.

Decision and handover to development

We hold a final meeting over the evidence board: what is confirmed, what is refuted, what remains open. The team decides whether to move to a prototype or MVP, change the segment or offer, or stop. If we go into development, we prepare the MVP scope, first-release metrics and a list of risks to test on the product itself. The artifact is a decision record and a brief for the development team.

Ways to work

Product Discovery formats for IT products

Discovery timing depends on the number of risky hypotheses, segment complexity and how fast we can reach users. Work continues until the signal is strong enough for one decision, and the stop condition is agreed at the start.

Format	What is included	Timeline	Outcome
Single hypothesis test	Assumption map, interviews, one experiment, evidence board	A few weeks	Decision: continue, change or stop
Discovery before an MVP	Segmentation and ICP, interviews, map of alternatives, value and monetization test	Defined after the diagnostic	MVP scope and success criteria
Discovery for B2B	Research with the user, department head, finance and procurement; testing readiness for a paid pilot	Defined after the diagnostic	A clear buying process and arguments for each participant
Discovery for an existing product	Reasons for usage and churn, testing a new segment or monetization model	Defined after the diagnostic	A product change plan backed by client behavior

We choose the right format during a free basic diagnostic session, after reviewing the idea, the segment and the product's main risk.

Frequently asked questions

Product Discovery: questions

How many interviews are needed?

There is no universal number. We look at sample quality, differences between segments and how consistently signals repeat.

Does Discovery guarantee product-market fit?

No. It reduces specific risks. Product-market fit is confirmed by market behavior after launch.

Is the approach suitable for B2B?

Yes. We separately research the user, the department head, procurement, finance and other people involved in the decision.

Can you run Discovery for an existing product?

Yes, especially when traction is lost, the product is entering a new segment or the reasons for usage and churn are unclear.

How long does Product Discovery take?

The duration depends on the number of risky hypotheses, the complexity of the segment and how quickly we can reach users. The work continues until there is a signal strong enough for one specific decision, not until a predefined research volume is reached. The timeline and stop condition are agreed at the start.

How much does Product Discovery cost?

The cost depends on the number of hypotheses, the chosen test methods and the complexity of the segment: interviews, message tests, a landing page or pre-orders require different resources. In B2B there is extra work with several people involved in the decision. The goal of the stage is to spend less than building on an untested hypothesis would cost.

What does Product Discovery for SaaS include?

Defining the priority segment and problem, analyzing alternatives, and testing value, the monetization model and willingness to pay for a subscription. For SaaS we also look at the path to first value and at who in the customer's company makes the buying decision. The output is an evidence board and the scope of the next experiment or MVP.

How is Product Discovery different from market research?

Market research describes the market and attitudes to the category. Discovery tests specific product hypotheses through user behavior and commitments and ends with a decision: continue, change or stop. A positive opinion without action does not count as a strong signal.

What if Discovery shows that the idea does not work?

That is also a result, and it protects the budget. The options are to narrow the segment, change the offer, test a different problem or consciously stop investing. The stop condition is agreed in advance so the decision is driven by data rather than attachment to the idea.