The Value Proposition Stress Test: How to Prove a Customer Pain Is Real.

by Dr. Thomas Papanikolaou on .

Founders can usually find people who agree that a problem matters. It is harder to find out whether it matters enough for customers to change their behaviour, and whether the founder can reach a group of customers who share it.

An interview cannot establish with certainty that a market exists. A stress test turns a vague belief into a hypothesis you can disprove. You then check it against customers' experiences, their current behaviour, the cost of the problem, and what they will commit to changing.

This guide provides a seven-step process for testing customer pain before investing heavily in a solution. It complements our guide to creating a Value Proposition Canvas and the practical resources in our Template Library.

A PAIN CLAIM IS NOT YET EVIDENCE

A customer pain is a negative consequence, obstacle, risk, or unwanted cost encountered while a specific customer tries to complete a job. It is not a product feature written in reverse. "People need an AI assistant" describes a possible solution. "Finance controllers spend two days reconciling inconsistent supplier records before every monthly close" describes a testable pain.

The official Strategyzer Value Proposition Canvas separates customer jobs, pains, and gains from the products, pain relievers, and gain creators intended to address them. Preserve that separation during discovery. If founders introduce the solution first, they can no longer tell whether enthusiasm reflects the pain, the proposed feature, politeness, or the interviewer's framing.

Counting interviews does not demonstrate market traction. Strategyzer's September 2026 evidence review separates what customers say from what they do. The stress test uses that distinction to help you seek stronger evidence.

THE CUSTOMER-PAIN EVIDENCE LADDER

Evidence is stronger when customers act at some cost to themselves. Use these levels to assess what the team has learned:

  1. Agreement. A participant says the problem sounds familiar or important. This is a clue, not validation.
  2. A recent example. The participant can describe when the problem last occurred, what triggered it, and what happened next.
  3. A repeated pattern. Similar examples recur across independently recruited people in the same segment.
  4. Observable behaviour. Records, workflow artefacts, workarounds, escalation paths, or time allocations confirm the account.
  5. A meaningful commitment. The customer gives scarce time, data, access, reputation, budget, or money to pursue a better outcome.

Keep these types of evidence separate rather than combining them into one interview score. Ten polite statements do not establish demand, and even a paid pilot may be unrepresentative. Look for several kinds of evidence that agree on who the customer is, what job they are doing, what triggers the problem, what it costs them, and how much they care about solving it.

THE SEVEN-STEP STRESS TEST

1. Write a falsifiable pain hypothesis

State who experiences the pain, while doing which job, after what trigger, how often, with what consequence, and how they respond today. Specify what result would make you reject or revise the hypothesis. For example:

We believe [specific customer] experiences [observable obstacle] when [trigger and job] at least [frequency], causing [measurable consequence]. They currently [workaround]. We will reject or revise this belief if [threshold is not met].

Avoid broad labels such as "small businesses" or "busy people". A hypothesis that can explain every answer cannot be disproved.

2. Recruit people with a recent trigger

Recruit participants because they recently encountered the situation, not because they resemble a persona on paper or already like the founder. Ask a neutral screening question about the job and timeframe. In B2B research, include the user, economic buyer, approver, and anyone who bears the consequences. They may experience different pains and have different authority to act.

3. Interview past behaviour before discussing a solution

Ask for the last specific occurrence. What started it? What did the person do first? Who became involved? What information, systems, and approvals were needed? What took longest? What failed? What was delayed or put at risk? What did they try, pay for, or stop doing?

Questions about past behaviour are not perfect, but they are more useful than "Would you use this?" Strategyzer's problem-versus-solution guidance recommends establishing customer jobs, pains, and gains before presenting the solution. Record facts and quotations separately from the team's interpretation.

4. Observe the workflow and collect traces

Whenever practical, watch the work happen in its normal setting. Look for spreadsheets, duplicated entry, waiting, hand-offs, messages, exception queues, workarounds, and points where people abandon or escalate the task. With informed consent, examine anonymised logs, documents, support tickets, calendars, or purchase records that reveal frequency and consequence.

The UK Government Service Manual's contextual research guidance explains why observing people with their own equipment and usual distractions can uncover barriers that an interview misses. Protect personal and commercially sensitive information, and collect only what the test needs.

5. Quantify frequency, consequence, and priority

Ask what "frustrating" costs in practice: occurrences per period, minutes per occurrence, people involved, direct spend, revenue delayed, error rate, risk exposure, missed deadline, or opportunity displaced. Then compare this pain with the customer's other priorities. A real pain can still be too infrequent, inexpensive, or politically difficult to justify action.

Avoid multiplying one dramatic interview by a large market estimate. First measure how the problem varies within the target segment: median, range, exceptional cases, and the conditions that explain the variation.

6. Request a proportionate commitment

Match the commitment to the maturity of the idea. Early signals include a second meeting with the decision-maker, access to anonymised workflow data, an introduction to another affected colleague, or time spent configuring a prototype. Stronger signals include a signed pilot plan, a letter of intent with clear conditions, procurement work, a deposit, pre-order, or payment.

A commitment tells you more when following through costs the customer something. It still does not prove repeatable demand: incentives, novelty, founder relationships, and special terms can distort behaviour. Record what each person committed to, the deadline, and whether they followed through without repeated chasing.

7. Compare the evidence with thresholds set in advance

Before the first session, define what would support, weaken, or refute the hypothesis. Thresholds might cover the share of qualified participants reporting a recent occurrence, observed frequency, minimum consequence, current workaround, decision ownership, and the number completing a commitment. Setting these thresholds beforehand prevents the team from lowering the bar after hearing an exciting story.

Capture the hypothesis, test, observation, interpretation, and resulting action separately. Strategyzer's Learning Card keeps these records separate. Update the Customer Profile on the Value Proposition Canvas only with patterns supported by evidence.

A WORKED B2B EXAMPLE

Imagine a startup exploring supplier-invoice reconciliation for finance teams. Its first statement is: "Controllers hate reconciling invoices." That is too broad to test. A stronger hypothesis is:

Finance controllers in 50-to-250-person subscription businesses manually reconcile usage-based supplier invoices during every monthly close. The work takes at least six team-hours, delays close or creates material rework, and is managed in spreadsheets because existing systems do not explain usage discrepancies.

The team recruits controllers who completed a close within the previous month. Interviews reveal recent cases, but observation shows two distinct segments: most teams spend under two hours and accept the workaround; a smaller group with many usage-based suppliers spends eight to fifteen hours and regularly escalates discrepancies. The second segment shares anonymised examples and three companies agree to a scoped pilot with their procurement teams involved.

The evidence supports a narrower, more valuable problem than the team first proposed; it does not validate the broad claim. It changes who the ideal customer is, when the pain occurs, which integrations are needed, who is likely to buy, and what minimum commitment to ask for in the next test. The team can use those findings to revise its proposal.

FALSE POSITIVES TO AVOID

  • Polite agreement: the participant wants to help the founder or end an awkward conversation.
  • Solution contamination: excitement appears only after an impressive demo, so the underlying pain remains unclear.
  • Proxy evidence: experts, investors, managers, or friends speak for customers who were never observed.
  • Future-tense answers: hypothetical intent replaces a recent example and an actual next step.
  • A tolerated workaround: the customer complains but the alternative is cheap, familiar, and good enough.
  • User-buyer mismatch: the user feels the pain, but the buyer does not own its consequences or budget.
  • Cherry-picked intensity: one severe case is treated as representative without testing its segment conditions.
  • Vanity commitments: email sign-ups or non-binding praise are counted as equivalent to access, effort, or payment.

THE PROCEED, REFINE OR RETIRE DECISION

Proceed when independently recruited customers report a recurring problem with meaningful consequences, their behaviour and records support their accounts, and you can reach a buyer who is responsible for the outcome. Customers should also follow through on commitments appropriate to the stage of the idea. Then test whether the proposed solution relieves the pain and whether customers will pay for it, rather than continuing discovery indefinitely.

Refine when the pain is real but concentrated in a narrower segment, different job, trigger, or stakeholder than expected. Rewrite the hypothesis and the Customer Profile, then test the revised scope.

Retire when the pain is rare, low consequence, adequately solved, disconnected from a buyer, or supported only by opinions after several well-designed tests. Rejecting a weak assumption is useful: it saves time and capital for testing a better one.

IN SUMMARY

Look for evidence of customer pain in recent accounts, repeated behaviour, and workarounds. Check the time, cost, and risk involved, who is responsible for the outcome, and whether they commit to a next step. No single signal settles the question, but evidence that agrees across these checks gives you a better basis for a business decision.

Define the pain separately from the solution and recruit people who have recently encountered it. Ask what happened, watch the work, measure the consequences, and request a meaningful next step. Compare the results with the thresholds you set before the test. Use them to decide whether the problem matters enough, and to whom, even if that means giving up the original idea.

SOURCES AND FURTHER READING

  1. Strategyzer: The Value Proposition Canvas
  2. Strategyzer: Problem versus solution in customer interviews
  3. Strategyzer: How to capture customer jobs, pains and gains that are not subjective
  4. Strategyzer: Ways to test your value proposition and business model
  5. GOV.UK Service Manual: User research for government services
  6. GOV.UK Service Manual: Contextual research and observation

Use these guides and workshop resources to work on your value proposition and business model.

INTRIGUED?

For more information on how our advisory services can help you accelerate your entrepreneurial journey, please contact us to arrange an introductory meeting or

Book a Discovery Session now!
Get to know us. Put us to the test.

MORE INSIGHTS

Previous Up Next