The most expensive mistake in product is building something nobody wants. CB Insights reports that 35% of startups fail because there is no market need. Carta reports startup failures are up 58% in 2024. Almost every one of those failures shipped code, designed interfaces, hired teams, and ran marketing campaigns for something the market never asked for in the form they delivered it.
The fix is product validation: a disciplined process for testing whether real users want what you are planning to build, before you invest the resources to build it. This article distills a working 30-day framework, building on Eric Hoppe's approach in the Canny blog and adapting it for product teams that use feedback portals and public roadmaps.
What product validation actually is
Validation is not asking customers if they would use your product. They will say yes. Validation is structuring a situation where customer behavior reveals whether the demand is real, ideally before you have built the thing.
The distinction matters. "Would you pay $20 a month for this?" gets 70% yes. "Here is the signup link, $20 a month" gets the real answer. Validation designs experiments that produce behavior, not just stated preference.
The 30-day framework
Days 1-5: hypothesize the need
Start with a sentence: "We believe [segment] has [problem] and would value [solution] enough to [action]." Make the segment specific (not "small businesses" but "freelance designers earning $50K-$150K a year"). Make the action specific (sign up, pay, schedule a demo, share contact).
Write three versions of the hypothesis with different framings. Talk through them with two trusted advisors. Pick the strongest version. Now you have something testable.
Days 6-10: research the market
Before talking to anyone, understand the landscape:
- Existing competitors: what they offer, what reviews complain about, what gaps exist
- Search volume: are people actively looking for solutions to this problem?
- Adjacent solutions: how do people solve this problem today (even badly)?
- Market size signals: how many people fit the segment? How accessible are they?
One day per source. By day 10 you should know if the problem space is empty (bad sign, nobody is looking), crowded (could be good if you have a real edge), or growing (best sign).
Days 11-17: customer conversations
Conduct 8-12 customer interviews with people who match the segment. Not friends, not investors, not your team. Real people in the target segment.
Three questions to anchor every interview:
- Tell me about the last time you tried to solve [problem].
- What did you use? What worked? What did not?
- If a perfect solution existed, what would change in your week?
Listen for the words they use, not the words you would use. The vocabulary mismatch is often where the validation fails. People do not have the problem framed the way you do.
Days 18-22: build the smallest possible artifact
Now you have enough signal to test demand with an artifact. Options, ranked by validation strength:
| Artifact | Signal it produces | Build cost |
|---|---|---|
| Landing page with signup | Interest at price point | 1 day |
| Concierge MVP (you do it manually) | Are people willing to pay for the outcome | 2-3 days |
| Clickable prototype | UX feedback, conceptual fit | 3-5 days |
| Wizard of Oz MVP | End-to-end behavior | 4-7 days |
Pick the one that tests your highest-risk assumption. If the risk is "will anyone pay?", a landing page is enough. If the risk is "can we actually deliver the outcome?", concierge MVP is right.
Days 23-27: test, adjust, improve
Put the artifact in front of real users from the target segment. Twenty users, minimum. Measure behavior, not opinions:
- Did they sign up?
- Did they actually use the product / take the action?
- Did they pay (or commit to paying)?
- Did they tell anyone else?
Stated preference is comforting and unreliable. Revealed preference is the signal that matters.
Days 28-30: check for product-market fit signal
By day 30 you should know one of three things:
- Strong signal: Multiple users took the action, paid or committed, asked when more would be available. Build.
- Mixed signal: Some users responded, but you cannot tell if it is the segment or the framing. Refine and run a second 30-day cycle on the strongest sub-segment.
- No signal: Users were polite but did not act. The hypothesis is wrong. Kill the idea or pivot to a different problem space.
The 35% of startups that fail from no market need usually shipped six months too early. A 30-day validation would not have saved all of them, but it would have saved many.
How validation connects to the roadmap
For products already shipping, validation is a feature-level discipline, not just a startup discipline. Every meaningful roadmap initiative should go through a validation cycle scaled to the bet:
- Small features: 1-week validation. Quick prototype with 3-5 users.
- Medium features: 2-week validation. Concierge or wizard-of-oz with 10-15 users.
- Big bets: 30-day validation. Full framework.
Validation is not friction. It is the cost of avoiding much larger friction later when you discover the feature does not work for the people you thought it was for.
Common validation mistakes
- Talking to the wrong people. If your interviewees are friends or warm contacts, they will be supportive. Find strangers in the segment.
- Asking leading questions. "Would this be useful?" gets yes. "What did you do last time you had this problem?" gets truth.
- Building too much before testing. A landing page tests demand in 1 day. A built feature tests demand in 6 weeks. Use the cheaper test first.
- Confusing engagement with validation. Users clicking around your prototype is not validation. Users signing up, paying, or returning is.
- Ignoring the data when it disconfirms. Validation only works if you are honest about disconfirmation. Most teams find ways to read a negative result as encouraging.
The takeaway
Product validation is the cheapest insurance against building the wrong thing. The 30-day framework moves you from hypothesis to evidence in a month: hypothesize, research, interview, build the smallest artifact, test with real users, read the signal honestly. The 35% of failed startups are mostly the ones who skipped this. Even mature products benefit from the discipline scaled to feature size. Build less, validate more, and the rate of features that find their audience improves dramatically.
