Build Something People Want

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:

When the answer is unclear, development may be producing output without producing enough evidence.

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:

It is:

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.

Understand the customer’s:

Define how the proposed product creates value through:

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:

Gains describe the better outcome the customer wants.

They may include:

A useful gain should be specific enough to observe or measure.

For example:

is vague.

A stronger gain is:

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:

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.

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:

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:

is too broad.

A stronger outcome is:

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.

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.

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:

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.

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.

Founders should welcome positive feedback, but avoid treating every positive signal as equal.

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:

It is:

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.

Begin with a clearly defined customer in a specific situation.

Clarify:

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:

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:

Ask:

Test the assumption most capable of invalidating the product.

The prototype should match the question.

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: