Create an account to save sources and durable progress.
Helping founders turn meaningful customer problems into focused products people adopt, trust and pay for.
Interest is not urgency. Customer behaviour is the evidence.
Start here
Founders love building products.
The work is tangible. You can design screens, write code, add features and watch the product improve. But that sense of progress can be deceptive when the team is learning more about the product than it is about the customer.
A product is not simply something that works. It must solve a problem that matters enough for customers to change their behaviour.
Apollo believes strong products develop through three levels of evidence:
These stages should not be collapsed into one vague claim that a product has traction. Each answers a different question and requires different evidence.
The founder’s task is not to build as much as possible. It is to build only enough to answer the next important question, then use customer behaviour to decide what happens next.
This guide will help you move from an interesting idea to a product that creates meaningful customer value and supports a viable business.
Key takeaways
By the end of this guide, you’ll understand how to:
Start with a meaningful customer problem rather than a preferred solution.
Understand the customer’s jobs to be done, pains and desired gains.
Use the Value Proposition Canvas as a testable set of product hypotheses.
Distinguish customer interest from genuine urgency.
Prototype with customers inside the real use case.
Use prototypes, pilots and MVPs to learn before making larger commitments.
Core question
Are we creating a product that solves a meaningful customer problem and supports a viable business?
Why Product Matters
A clear strategy chooses where the company will play and how it intends to win.
The product turns those choices into something customers can experience.
It is where the company’s understanding of the customer becomes real. Every workflow, feature, message and interaction reflects an assumption about what the customer needs, what they value and how they want to solve the problem.
When those assumptions are correct, the product creates progress for the customer.
When they are wrong, more features rarely solve the underlying issue.
Finding the Gold With Customers
I have run more than 30 product workshops across Moscow, Bucharest, Sydney, Melbourne, San Francisco, New York and Los Angeles.
The companies, industries and products have been different, but the pattern is remarkably consistent: we always discover something new when we explore the customer problem and test possible solutions with real users.
A team can spend months discussing a product internally. It can analyse research, debate features and create detailed plans. But the most valuable insights usually appear when customers experience a prototype in the real situation where the product will be used.
That is where you find the gold.
In 2014, we applied this approach while working on the Nike Soccer App.
We did not test the concept only in a meeting room or ask people whether they liked the idea. We prototyped real soccer games with players in San Francisco, London, Tokyo and São Paulo.
The product was placed inside the use case it was intended to support. We observed how players organised games, communicated with each other and responded before, during and after playing.
The Apollo Perspective on Product
Apollo believes product development is not primarily a process of adding features.
It is a process of reducing uncertainty.
At the beginning, a founder does not know with confidence whether the problem is urgent, whether the proposed solution will change customer behaviour or whether the company can deliver the outcome sustainably.
Every prototype, pilot and product release should help answer one of those questions.
This changes how a founder thinks about progress.
Progress is not simply:
Those outputs may matter, but they are valuable only when they produce stronger evidence about the customer and the business.
Use the Value Proposition Canvas to Find Problem–Solution Fit
The Value Proposition Canvas provides a clear structure for understanding whether a proposed solution fits a meaningful customer problem.
It connects two sides of the product opportunity.
The Value Proposition Canvas is a third-party framework from Strategyzer AG. Apollo uses it here as an input to the Apollo Product Fit Model; the canvas itself is not Apollo intellectual property.
Source: Strategyzer usage and attribution guidance
Understand the customer’s:
Build to Learn
The purpose of an early product is not to prove that the founder can build it.
It is to learn whether the customer will value it.
This changes the question from:
What can we add to the product?
to:
What is the smallest thing we can build to test the next important assumption?
That may be:
The appropriate product depends on the question being tested.
A prototype may test whether customers understand the experience. A manual service may test whether the outcome is valuable. A paid pilot may test whether the problem creates enough urgency to secure commitment.
The goal is not to avoid building.
The Apollo Product Fit Model
Apollo separates product progress into three levels of fit.
Each stage answers a different question and requires stronger evidence than the stage before it.
Stage and Memorable test and Core evidence
| Stage | Memorable test | Core evidence |
|---|---|---|
| Problem–Solution Fit | Are they seeking and solving? |
The Foundations of a Strong Product
A strong product is not defined by how many features it contains.
It is defined by how effectively it helps a specific customer make meaningful progress.
Apollo believes strong products are built on seven connected foundations.
Foundation and Product question
| Foundation | Product question |
|---|---|
| Customer Job | What progress is the customer trying to make? |
The Apollo Product Evidence Loop
Strong products do not emerge from one perfect idea.
They develop through repeated cycles of customer understanding, prototyping, testing and improvement.
Apollo uses a simple evidence loop:
Observe → Understand → Design → Prototype → Test → Measure → Learn → Improve
The loop begins with the customer, not the backlog.
Each cycle should reduce uncertainty about one of three things:
Common Product Traps
Even strong teams can become busy building without producing stronger evidence.
Most product mistakes do not begin with poor intentions. They begin when teams confuse output with progress, customer interest with commitment or feature volume with product value.
Product trap and What it looks like and Better alternative
| Product trap | What it looks like | Better alternative |
|---|---|---|
| The feature-factory trap |
A Practical Product Process
Product development becomes valuable when each cycle reduces uncertainty and improves the customer outcome.
Apollo recommends a practical eight-step process.
Begin with a clearly defined customer in a specific situation.
Clarify:
The One-Page Product Definition
A founder should be able to explain the current product hypothesis on one page.
Include:
The purpose is not to create permanent product documentation.
It is to make the current product logic visible, testable and easy for the team to discuss.
Think • Reflect • Act
A product is a focused solution to a problem that matters enough for customers to act.
Strong product development moves through three levels of evidence:
Each stage answers a different question.
Building more does not allow a company to skip one.
Consider the product you are currently building.
Ask yourself:
Questions
A great product does not begin with more features.
It begins with a customer making progress.
The strongest founders understand the job, find the pain, define the gain and test their assumptions through real customer behaviour.
Continue learning
You have explored how to turn strategic choices and customer evidence into a focused product.
The next step is finding, winning and keeping the right customers.
Product and growth are inseparable.
Growth cannot repair a product that lacks urgency, value or retention. It can only expose those weaknesses faster.
A strong product gives growth something worth amplifying.
Turn customer evidence into product priorities, decisions and a focused product operating system.
© Apollo Advisors° ABN 34 346 108 139
Measure product value through adoption, payment, usage and retention.
Progress from problem–solution fit to product–market fit.
Test whether the business can create and capture value sustainably.
Prioritise core workflows, trust and reliability over feature volume.
Product development can create the illusion of progress.
A team may spend months working through:
The work is real. The team is busy. The product keeps changing.
But most of the activity happens inside the company.
The founder may still lack clear evidence that the customer problem is important, frequent or urgent enough to justify switching behaviour or paying for a solution.
This is the product black hole: the team becomes increasingly absorbed in building while its understanding of the market remains largely unchanged.
The longer this continues, the harder it becomes to stop. Time, money and identity become attached to the product. Adding another feature feels safer than returning to the customer and questioning the original assumptions.
A useful question is:
What have we learned about customer behaviour since the last product release?
When the answer is unclear, development may be producing output without producing enough evidence.
That process exposed details, behaviours and needs that would have been difficult to discover through discussion alone. The prototype gave players something concrete to react to, while the real-world setting revealed what actually mattered to them.
This experience reinforced a lesson I have seen repeatedly throughout my career:
You do not discover product–market fit from inside the building.
Customer interviews are useful, but words alone are not enough. People may struggle to describe what they need, predict how they will behave or identify which parts of an experience matter most.
A prototype makes the idea tangible. Testing it inside the real customer use case shows you:
The objective is not to prove that the original idea was correct.
It is to uncover the insight that helps you build a better solution.
Product progress is measured by what you learn about customer behaviour—not only by what you ship.
Founders naturally see solutions.
They imagine a new product, interface, workflow or technology and immediately begin thinking about how it could be built.
Customers usually experience the situation differently. They feel the problem before they imagine the product.
They experience:
A strong product begins by understanding that lived experience.
The question is not simply:
Can we build this?
It is:
Does this problem matter enough for the customer to act?
A problem becomes strategically valuable when it is important, recurring and connected to a meaningful outcome. The customer may already be trying to solve it through spreadsheets, manual processes, additional staff, consultants or an imperfect competing product.
Those existing behaviours are evidence.
Customers are often polite.
They may say:
These responses can encourage a founder, but they are weak evidence.
Interest costs the customer nothing.
Urgency produces behaviour.
Customers with a meaningful problem are more likely to:
The strongest evidence is not that customers agree with your description of the problem.
It is that they are already doing something to solve it.
Define how the proposed product creates value through:
Customer Profile and Value Proposition
| Customer Profile | Value Proposition |
|---|---|
| Jobs to be done | Products and services |
| Pains | Pain relievers |
| Gains | Gain creators |
The objective is to create a clear connection between what the customer needs and what the product is designed to deliver.
But a completed canvas is still only a set of hypotheses.
The real work is validating those hypotheses with customers.
A job to be done is the progress a customer is trying to make in a particular situation.
The job may be functional:
It may also have emotional or social dimensions.
The customer may want to:
Customers rarely want a feature for its own sake.
They want the progress that the feature enables.
Pains are the obstacles, costs and risks that make the customer’s job difficult.
They may include:
Not every pain deserves a product.
The strongest product opportunities usually involve pains that are:
Ask:
Interest says the pain is understandable. Urgency means the customer is prepared to act.
Gains describe the better outcome the customer wants.
They may include:
A useful gain should be specific enough to observe or measure.
For example:
Make compliance easier.
is vague.
A stronger gain is:
Help a venue manager complete the weekly compliance workflow in 20 minutes, with a clear record of what has been completed and what still needs attention.
The second statement gives the team something concrete to design and test.
Once the Customer Profile is clear, define the Value Proposition.
Ask:
The goal is not to match every job, pain and gain.
A strong early product usually focuses on the few that matter most.
The Value Proposition Canvas should never be completed once and treated as truth.
Use it as a living set of hypotheses.
Validate it through:
Ask customers to show you what they currently do rather than only describing what they might do.
Observe:
The canvas organises the assumptions.
Customer testing decides whether they deserve confidence.
Problem–Solution Fit exists when four conditions are supported by customer evidence:
The simplest diagnostic is:
Do we understand the customer’s jobs, pains and gains—and have customers demonstrated that our proposed solution fits them?
It is to make building part of a disciplined learning process.
Early products are often weakened by trying to satisfy too many possible users at once.
The result is feature volume without a strong core.
Apollo recommends identifying the smallest complete experience that helps the chosen customer achieve the important outcome.
That experience should be:
Minimal does not mean careless.
An MVP may be narrow, but the core experience still needs to work well enough for customers to trust the result.
A broken core workflow teaches very little about demand because customers are reacting to poor execution rather than the underlying value proposition.
The founder’s job is not to predict the perfect product.
It is to create a disciplined sequence of evidence.
First, establish that the problem deserves attention.
Then, establish that the product changes behaviour.
Finally, establish that the business can deliver and capture that value sustainably.
That progression is the foundation of the Apollo Product Fit Model.
| Product–Market Fit | Are they paying, using and staying? | Adoption, payment, core usage, retention, renewal and recommendation. |
| Business-Model Fit | Can we acquire, serve and retain them sustainably? | Repeatable acquisition, viable pricing, healthy margins and scalable delivery. |
The model can be expressed simply:
Seeking and solving → Paying, using and staying → Acquiring, serving and retaining sustainably
Problem–Solution Fit begins before the complete product exists.
The objective is to establish that the problem is real enough for customers to do something about it.
Look for evidence that customers are already:
The strongest signal is not that customers agree the problem exists.
It is that the problem already influences their behaviour.
You have early Problem–Solution Fit when a clearly defined customer repeatedly demonstrates meaningful pain and commits time, attention or resources to finding a better solution.
Problem–Solution Fit gives the company permission to build and test.
Product–Market Fit shows that the resulting product creates enough value for the right customers to choose it and continue using it.
Look for evidence that customers:
Different product types will show fit differently. A daily workflow product may rely heavily on frequency of use, while an annual compliance product may create value through completion, trust and renewal rather than daily engagement.
The correct measure is connected to the customer outcome.
You have growing Product–Market Fit when the right customers consistently choose the product, reach meaningful value and remain customers.
A product can solve a meaningful problem and retain customers while still failing to become a healthy business.
Business-Model Fit asks whether the company can create, deliver and capture value at economics that work.
Look for evidence that:
This is where the product connects to pricing, operations, growth and profit.
The NuDance lesson is relevant here. Customers may love a product, but customer love alone does not guarantee that the company captures enough value to sustain itself.
You have Business-Model Fit when acquisition, delivery, retention and value capture work together as a repeatable and economically sustainable system.
Founders often try to move directly from an idea to scale.
They invest in:
before the earlier evidence is strong enough.
Scaling does not repair weak fit.
It amplifies it.
If the problem lacks urgency, more marketing creates more weak leads. If customers do not stay, faster acquisition creates faster churn. If the economics do not work, growth increases the loss.
The safer sequence is:
| Pain and Urgency | What makes the current situation difficult enough to change? |
| Desired Gain | What better outcome does the customer want? |
| Core Workflow | What must the product help the customer do exceptionally well? |
| Experience and Trust | What must feel clear, reliable and safe? |
| Adoption and Retention | What behaviour shows that customers receive continuing value? |
| Viability | Can the company create, deliver and capture value sustainably? |
A weakness in one foundation usually weakens the others.
A product may solve a real problem but feel too difficult to adopt. It may deliver an excellent experience but lack urgency. Customers may use it regularly while the company remains unable to serve them profitably.
Strong product development brings all seven foundations together.
Begin with the progress the customer is trying to make.
A customer may appear to be buying software, advice or automation. In reality, they are trying to achieve an outcome in a particular situation.
They may be trying to:
The product is useful only when it supports that progress.
Features describe what the product contains.
The customer job explains why those features should exist.
A job does not automatically create a product opportunity.
The current experience must contain enough pain, cost, risk or frustration for the customer to consider changing their behaviour.
A useful product problem is often:
Urgency may come from different sources.
A compliance deadline creates external urgency. A slow financial process may create recurring operational pain. A missed revenue opportunity may create commercial urgency. Anxiety or uncertainty may create emotional urgency.
The founder’s task is to understand not only what is difficult, but why solving it matters now.
A strong product should make the customer’s desired outcome clear.
The gain may involve:
The clearer the gain, the easier it becomes to decide what the product should and should not do.
For example:
Make compliance easier.
is too broad.
A stronger outcome is:
Help a venue manager complete the weekly compliance workflow in 20 minutes, with a clear record of what was completed and what still requires attention.
The second statement guides product decisions because it describes the user, the job and the desired result.
Every product needs a core workflow: the sequence of actions through which the customer receives the main value.
For an early product, this workflow matters more than the size of the feature set.
A useful core workflow should help the customer:
Founders should be able to identify the moment when the product first becomes useful.
This may be:
Everything before that moment should help the customer reach it.
Everything after it should deepen or repeat the value.
A product can solve the right problem and still fail if customers do not understand or trust it.
Trust matters especially when the product touches:
Customers build trust through details such as:
Minimal does not mean unfinished.
A narrow product can still provide a complete, trustworthy core experience.
A product creates value only when customers use it.
Adoption begins when the customer reaches the core value for the first time. Retention appears when that value is meaningful enough for the customer to return, renew or continue relying on the product.
Useful adoption questions include:
Retention questions include:
The correct behaviour depends on the product.
A daily collaboration tool may require frequent use. An annual estate-planning product may create value through completion, secure storage and future review rather than daily engagement.
The metric should follow the customer job.
A product must create value for the customer and capture enough value for the company.
That requires alignment between:
A high-value product can still become a weak business when every customer requires extensive custom work, founder involvement or expensive support.
A lower-cost product can still become a strong business when acquisition, delivery and retention are efficient.
Founders should ask:
This is where product decisions connect to Profit and Operations.
The objective is not to complete the loop once.
It is to complete useful loops faster and with better evidence.
Begin inside the customer’s real situation.
Watch what they do today:
Customers may not always describe these details accurately in an interview. Observation reveals behaviour they may consider too normal or obvious to mention.
Ask customers to show you the process rather than only explain it.
Translate what you observed into the customer side of the Value Proposition Canvas.
Clarify the customer’s jobs, pains and gains.
Do not rush to capture every possible need.
Prioritise the few that matter most.
Use the customer evidence to define a focused value proposition.
Decide:
The goal is not to design the complete future product.
It is to design the clearest response to the most important customer evidence.
Create the smallest credible representation of the proposed experience.
The appropriate prototype depends on the question.
Question and Possible prototype
| Question | Possible prototype |
|---|---|
| Do customers understand the concept? | Landing page or concept statement |
| Does the workflow make sense? | Clickable prototype |
| Does the outcome create value? | Manual or concierge service |
| Will customers commit time? | Structured pilot |
| Will customers pay? | Paid pilot or pre-order |
| Does the core experience work? | Narrow MVP |
| Does the product fit the real environment? | In-context prototype |
A prototype should be realistic enough to produce useful behaviour, but small enough to change without excessive cost.
Place the prototype in front of the right customers.
Whenever possible, test it inside the real context where the product will be used.
Look for evidence such as:
Avoid leading questions such as:
Would you use this?
Instead, create opportunities for the customer to demonstrate commitment.
Measure the behaviour connected to the assumption being tested.
Do not collect every possible metric.
Choose the evidence that answers the current question.
Measure:
Measure:
Measure:
The measure must match the product.
Daily activity may matter for a collaboration tool, but it may be irrelevant for an annual legal or compliance workflow. Measure the customer outcome, not a generic engagement metric.
Review what happened without defending the original idea.
Ask:
The learning should be specific enough to influence the next decision.
“Customers liked it” is not a useful conclusion.
“Customers understood the reporting workflow but would not invite their team until permissions were clearer” is useful.
Use the evidence to decide what happens next.
You may choose to:
Improvement does not always mean adding more.
Sometimes the strongest product decision is to narrow, remove or stop.
Product teams often try to test too many assumptions at once.
A new release may change:
When results change, the team cannot tell why.
Apollo recommends giving each major evidence loop one primary question.
Examples:
A focused question creates more interpretable evidence.
Not all product evidence carries equal weight.
Evidence level and Example and Strength
| Evidence level | Example | Strength |
|---|---|---|
| Opinion | “That sounds useful.” | Weak |
| Attention | Customer agrees to another conversation. | Early |
| Effort | Customer shares data or joins a prototype session. | Moderate |
| Commitment | Customer signs a pilot agreement or allocates staff. | Strong |
| Payment | Customer pays for the product or pilot. | Stronger |
| Behaviour | Customer uses the core workflow and achieves value. | Very strong |
| Retention | Customer stays, renews or expands. | Strongest continuing evidence |
Founders should welcome positive feedback, but avoid treating every positive signal as equal.
| Measure what the team learns and whether customer behaviour improves. |
| The founder-projection trap | The founder assumes customers think and behave as they do. | Observe the real customer job, pain and use case. |
| The interview-only trap | Positive conversations are treated as proof of demand. | Combine interviews with prototypes, commitment and behaviour. |
| The solution-first trap | The team becomes attached to a product before validating the problem. | Validate jobs, pains and gains before building deeply. |
| The custom-customer trap | One prospect’s requests reshape the entire product. | Distinguish repeatable market evidence from individual preference. |
| The premature-scale trap | The company adds sales, marketing and infrastructure before proving fit. | Prove the problem, product and business before scaling. |
| The weak-MVP trap | “Minimum” becomes an excuse for an unreliable or confusing core experience. | Keep the scope narrow while making the core workflow complete and trustworthy. |
| The vanity-metric trap | Sign-ups, clicks or downloads are treated as proof of value. | Measure activation, customer outcomes, payment, retention and renewal. |
| The sunk-cost trap | The team continues because too much has already been invested. | Make the next decision based on current evidence, not past expenditure. |
A product team can appear highly productive while making little progress towards Product–Market Fit.
The backlog grows. Releases happen regularly. More features become available. Yet the team may still be unable to explain:
Shipping matters, but shipping is a means rather than the outcome.
Before committing to a feature, ask:
Founders often build products for people they understand well—or believe they understand well.
That familiarity can become dangerous when the founder assumes customers share their:
The remedy is not more internal debate.
It is direct customer evidence.
Observe customers completing the job. Ask them to show you the current process. Test the prototype in context.
Customer interviews are one of the most useful tools available to an early-stage founder.
But interviews become misleading when positive language is treated as proof of future behaviour.
Interviews are strongest when they focus on:
Then strengthen the evidence through prototypes, commitments, payment and repeated use.
A conversation can reveal the hypothesis.
Behaviour helps validate it.
Founders often become emotionally attached to the solution before they have fully understood the problem.
The better sequence is:
A large or enthusiastic prospect can pull an early product away from its intended market.
Before accepting a major request, ask:
One customer can provide valuable insight.
One customer should not automatically define the product.
Growth magnifies what already exists.
When product fit is strong, additional sales and marketing can create momentum. When fit is weak, scaling creates more noise, higher costs and faster churn.
The safer order is:
An MVP should be minimal in scope, not careless in quality.
A useful MVP should be:
Minimal means removing what is unnecessary.
It does not mean removing what is essential.
Large numbers can create confidence without proving customer value.
Stronger measures include:
The question is not:
Are people interacting with the product?
It is:
Are the right customers achieving the outcome the product exists to create?
The more a team invests in a product, the harder it becomes to question it.
A better review asks:
Continuing without evidence may cost much more than changing direction.
Use the customer side of the Value Proposition Canvas.
Identify the customer’s:
The purpose is not to fill every section with ideas.
It is to identify the few jobs, pains and gains most likely to influence customer behaviour.
Treat the Customer Profile as a set of assumptions until customers provide evidence.
Use:
A stronger question than “Would you use this?” is:
Tell me about the last time this happened. What did you do?
Look for customers who are already searching, solving, spending, allocating staff or accepting risk.
Complete the solution side of the Value Proposition Canvas.
Define:
A focused value proposition should answer:
How will this product help this customer make meaningful progress in this situation?
Ask:
Test the assumption most capable of invalidating the product.
The prototype should match the question.
Question and Appropriate test
| Question | Appropriate test |
|---|---|
| Do customers understand the problem? | Interview, problem statement or landing page |
| Does the proposed value resonate? | Concept test or value proposition |
| Does the workflow make sense? | Clickable prototype |
| Does the outcome create value? | Manual or concierge service |
| Will customers commit time? | Structured pilot |
| Will customers pay? | Paid pilot, deposit or pre-order |
| Can the core experience work? | Narrow MVP |
| Does it fit the real environment? | In-context prototype |
Place the prototype in the real or closest possible use case.
Observe:
Do not try to persuade the customer that the prototype is valuable.
Create the conditions for their behaviour to show you.
After the test, separate observation from interpretation.
Record:
A product review should end with a decision, not merely a list of observations.
Ask:
What is the next most important question, and what is the smallest credible test that can answer it?
Then answer the harder question:
Are we building the next feature because customer evidence supports it—or because building feels more comfortable than testing the underlying assumption?
Where is your team currently building from evidence—and where might it be building because stopping to question the product feels uncomfortable?
Then ask:
Create or update your current Value Proposition Canvas.
Do not complete it alone and treat it as truth. Use it to make your assumptions visible, then validate them with customers.
Write down the customer’s:
Write down the proposed:
Complete this sentence:
Our product depends on the belief that…
Then ask:
Define:
Do not ask only whether customers like the idea.
Ask them to show commitment through time, effort, data, behaviour or payment.
Reflect on product evidence, challenge assumptions and think through difficult product decisions.
Connect the validated customer, problem and value proposition to go-to-market execution.
Test whether pricing, value capture and unit economics support a sustainable business.
Related content
Your reading position stays on this device. Create an account when you want durable guide, reflection, note, and saved-item milestones.
Create an account for durable progress