Painful Problem First
Anchor the startup in urgent customer pain before choosing a solution
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 97%
The method begins by locating a customer problem painful enough to justify adoption, rather than inventing a product and searching for demand afterward. Founders define the affected customer, document the consequences of the problem, and test whether people actively want relief. Once the problem is validated, the proposed solution remains flexible. Vest, for example, retained its original focus on downside protection while reconsidering the most effective delivery vehicle. This distinction lets a team pivot without losing strategic coherence: the mechanism, wrapper, interface, or pricing can change while the customer need remains the anchor. The result is a customer-focused development process that reduces solution bias and directs iteration toward better delivery of a consistently valuable outcome.
Origin
Chang learned the approach at Y Combinator and applied it while Vest evaluated different vehicles for delivering downside protection.
Core principles
- 01Start with the customer problem rather than a preferred product
- 02Require pain strong enough to motivate action
- 03Keep the validated problem stable while allowing the solution to change
- 04Build something people demonstrably want
- 05Separate the delivery vehicle from the underlying need
How to run it
- 1
Find observable pain
Identify a recurring problem with meaningful financial, operational, or emotional consequences for a specific customer.
Pro tip Look for workarounds, complaints, abandoned tasks, or existing spending as evidence.
Watch out Interest in a topic is not the same as painful demand.
- 2
Define the problem independently
Write a problem statement that specifies the customer, circumstance, pain, and desired outcome without naming your product.
Pro tip Ask customers to describe the last time the problem occurred.
Watch out Do not smuggle your preferred solution into the problem statement.
- 3
Test urgency
Determine whether customers will commit time, money, data, or access to obtaining a solution.
Pro tip Behavioral commitments are stronger evidence than survey enthusiasm.
Watch out Compliments and hypothetical purchase intentions can create false confidence.
- 4
Explore delivery options
Compare multiple ways to solve the validated problem, including different products, wrappers, channels, or partnerships.
Pro tip Score options on customer friction, regulation, scalability, and economics.
Watch out Do not treat the first technically feasible approach as the final product.
- 5
Pivot around the anchor
Change the implementation when evidence points to a better route while retaining the validated customer problem as the strategic anchor.
Pro tip Record which assumption each pivot is intended to test.
Watch out Repeatedly changing both customer and problem makes learning difficult to interpret.
In the wild
Vest entered Y Combinator with a thesis around buffers and downside protection. The team reconsidered whether a mutual fund, ETF, or another vehicle would best address liquidity, credit-risk, compliance, and scalability constraints without abandoning the original customer need.
→ The company preserved its problem thesis while evolving toward scalable buffered ETFs.
A software founder discovers that small agencies struggle with unpredictable cash flow. Instead of immediately building a lending product, the team validates the pain through overdue invoices and then compares automated collections, invoice financing, and payment reminders.
→ The team selects the least burdensome mechanism that customers will actually adopt.
Common mistakes
Starting with a favorite product
A founder can mistake enthusiasm for a technology or format for evidence that customers need it.
Accepting weak pain signals
General interest, praise, and survey responses do not prove that the problem is urgent enough to change behavior.
Treating every pivot as a new mission
Changing the underlying problem with every implementation prevents cumulative learning and strategic focus.
Is it for you?
Best for
It is best for early-stage founders choosing, validating, or repositioning a product.
Not ideal for
It is not ideal when regulatory or scientific discovery must precede meaningful customer validation.
From the transcript
“YC always says that, like, make something that people want”
“Start with the problem solving your solving, and the problem needs to be painful enough.”
“always start with the problem first and make sure the problem is painful enough for your customer”
From the episode
Financial Products for Hedging with Vest Co-Founder Jeff Chang
Jeff Chang