How to reach product-market fit

Treat validation as an evidence ladder, not a phase

The best pre-PMF founders did not choose between talking and shipping. They increased the cost and realism of the evidence as confidence grew. Buffer tested its proposition with a landing page, then added pricing and watched whether visitors clicked a paid plan before building the working product. Gong began with a pitch deck and design partners. Segment learned that praise meant little when prospects would not install its first products, then went much deeper into one market and its existing workflow.

Paul Graham's account of Stripe's early growth adds the delivery end of the ladder: the Collison brothers installed Stripe for users on the spot. That was not premature scale. It was the shortest path to observing whether the promised value survived contact with a real business. In each case, the team escalated evidence; none treated an encouraging interview as permission for a broad build.

• Past behaviour: how the customer handles the problem now, including workarounds, cost and failed attempts.
• Simulated behaviour: a prototype, fake door, concierge run or realistic offer that requires the customer to act.
• Commitment: access to data, buyer time, a signed design partnership, deposit or paid pilot.
• Live behaviour: successful use, return, payment, expansion, referral, or retreat to the old alternative.

Recruit a cohort narrow enough to learn from

Cagan's customer discovery programme aims for six successful, referenceable B2B customers in one specific segment. Teams normally recruit six to eight because one or two may be unavailable or prove to be a poor fit. This is not a statistically representative sample. It is a deliberately small group that gives the product team sustained access while it discovers what success actually requires.

Six is a useful B2B charter-programme heuristic, not a universal definition of product-market fit. A consumer habit product, a marketplace and a high-value enterprise system reveal fit through different combinations of return, liquidity, expansion, payment and pull. Sequoia's PMF archetypes make the same point: the evidence and operating model depend on how the customer experiences the problem.

Screen for the same buyer, struggling moment, operating context and desired outcome, not merely the same industry label. Each participant should feel the pain acutely, lack an adequate existing solution and commit the buyer and user time, data and workflow access needed for repeated testing. Exclude people attracted mainly by novelty and anyone asking for a private custom build that other members would not value.

Use Bob Moesta's switch interview to reconstruct the push of the current situation, pull of a new outcome, anxiety about changing and habit with the old alternative. For consumer products, Cagan suggests a recurring cohort of roughly 10–50 people, supplemented by much broader testing with unexposed users. In both cases, the cohort is where the team learns deeply; it is not permission to generalise beyond the evidence.

Write the customer letter before mapping the journey

For a substantial product bet, write Cagan's imagined customer letter before listing features. Write from one well-defined customer's perspective to the company CEO. Describe the old situation, the moment the problem became costly, what the customer can now achieve and why that change matters. Keep it positive but credible: include the effort of switching, where human help remains and the concrete behaviour that proves the improvement. Add the CEO's short reply explaining how the result helps the business.

Then build Jeff Patton's story map. Lay the customer's future journey left to right as an activity backbone, add alternative paths and failure recovery beneath it, then slice the thinnest end-to-end experience capable of producing the letter's outcome. A story map is not a backlog drawn sideways. It keeps the whole customer journey visible while the team narrows delivery.

Map that slice against Cagan's four risks: value, usability, feasibility and viability. Test the riskiest assumption with the cheapest credible method: message, prototype, concierge run, technical spike or commercial commitment. Stay in discovery while one of those can answer the question. Deliver when only dependable end-to-end use can show whether the promised outcome survives reality.

Cross into delivery through an explicit gate

Delivery is justified when a dependable end-to-end product is the cheapest remaining way to learn whether customers reach the value, repeat it and pay. Do not require certainty; require enough evidence that the residual question genuinely depends on live use. The whole product team should review the gate because product, design and engineering each see different failure modes.

• One narrow customer, struggling moment, buyer and desired outcome recur across independent prospects.
• The proposition has caused meaningful action, not merely praise, and the strongest prospects will commit time, data, access or money.
• The critical path works in a realistic prototype without the team narrating every step.
• The lead engineer has cleared the largest technical unknown, while legal, support and commercial constraints make the offer viable.
• The delivery has a fixed appetite, explicit exclusions, instrumentation and a stop rule agreed before work begins.

Deliver one complete value loop, with a circuit breaker

Use the first story-map slice to scope one segment, one job, one buyer-to-user path and one promised outcome. Manual work behind the product is acceptable when it speeds learning; a broken core journey is not. Instrument time to first value, successful completion, repeat use, payment, support required and any fallback to the previous workflow. Track those signals for each cohort member rather than hiding six different experiences inside one average.

Basecamp's fixed-appetite idea provides a useful circuit breaker. Decide how much time the evidence justifies and stop when it is spent. If the work is still dominated by unknowns, return those unknowns to shaping and discovery rather than extending the cycle by habit. The aim is not to rescue every bet; it is to cap the cost of being wrong while preserving a complete test of the value loop.

Keep discovery running and let behaviour choose the next cycle

Discovery does not stop when delivery starts. Keep weekly customer contact, review live evidence with the same team and explore the next constraint while the scoped product is being made dependable. This is not a 50:50 allocation: effort follows risk. Engineers stay involved in discovery; product and design stay close to support, activation and commercial evidence after release.

Return to discovery when customers need founder explanation to find value, commitments do not become use, users do not return or pay, each customer wants a different job, or a fundamental value or viability question remains. Continue delivery when several similar customers pull the same outcome and the remaining questions are about reliability, speed and reach rather than whether, what or for whom.

Rahul Vohra's product-market-fit survey becomes useful only after enough users have experienced the core value. Before that, it risks measuring reactions to an unfinished or misdirected experience. Later, segment the people who would be very disappointed, study why they care and improve the product for adjacent users. Earlier, use the harder signals: commitment, successful use, return, payment and unsolicited pull.