Discovery and Validation Frameworks That Prevent Dead Features

It's 4:47 PM on a Thursday. The CRO drops a Slack message: "Big logo just churned. They wanted custom approval routing. We need this on the Q3 roadmap." By Friday's leadership sync, "custom approval routing" is a committed Q3 deliverable. Two engineers get pulled in. Six months later it ships, 9% of accounts touch it in the first 60 days, and nobody can explain what problem it actually solved.

I've shipped that feature. Twice. Once at a workflow tool, once at a CRM. Both times the diagnosis was the same. We skipped discovery because someone with a title turned a single data point into a strategy. The engineering quarter wasn't the cost. The cost was the three opportunities we didn't explore because the team was busy building the loudest customer's pet feature.

If you're a PM who keeps shipping things nobody adopts, this guide is the discovery stack I wish someone had handed me three years ago.

Why First-Idea Shipping Fails

Pendo's product benchmarks have been depressingly consistent for a decade. 60-70% of features in B2B SaaS products see less than 15% adoption in the first six months. Some studies put the dead-feature rate even higher. That's not a bug in any single team; that's the base rate of building before validating.

Let's call this what it is. Sub-15% adoption after 60 days = dead feature. Not "needs more enablement." Not "the GTM motion is off." Dead. The cohort that needed it didn't pull on it, the cohort that didn't need it ignored it, and now you have surface area to maintain forever.

A dead quarter isn't 12 weeks of engineering time. It's 12 weeks of engineering time, plus PM time, plus design time, plus QA, plus the technical debt you'll carry for years, plus the opportunity cost of the three other bets you didn't make. A four-engineer squad shipping a dead feature burns roughly $400K of fully-loaded cost. You don't get many of those before someone in finance starts asking pointed questions in the QBR.

The fix isn't "do more research." It's a discovery practice that runs every week, not as a sprint.

The Opportunity-Solution Tree (Teresa Torres)

Teresa Torres' opportunity-solution tree is the single artifact that has done the most for my product sense. The structure is brutally simple:

                Outcome
                   |
         +---------+---------+
         |         |         |
    Opportunity Opportunity Opportunity
         |         |         |
      +--+--+   +--+--+   +--+--+
      |     |   |     |   |     |
    Sol   Sol Sol   Sol Sol   Sol
      |
   Assumption tests

Outcome at the top: one measurable business or product outcome, like "increase weekly active workspaces by 20%." Not a feature. Not a launch. An outcome.

Opportunities are customer problems, framed in customer language, that (if solved) would move the outcome. "New admins can't tell which projects are stuck" is an opportunity. "Build a project health dashboard" is not. That's a solution.

Solutions sit under opportunities, three to five per opportunity. Cheap, multiple, and explicitly competing with each other.

Assumption tests sit under each solution. These are the actual experiments (fake doors, prototypes, concierge MVPs) that decide whether the solution gets built.

The reason most teams fail with the tree isn't the structure, it's that they treat it as a one-time artifact. They build it in a Miro board, present it in a quarterly planning meeting, and then it dies. The tree is supposed to live on a wall (physical or digital), and you walk past it every week. New interview happens? You add an opportunity branch. Assumption test fails? You prune a solution. Outcome shifts? Whole sub-branches die.

I review my tree every Thursday morning, alone, for 30 minutes. I add what I learned that week and kill what stopped making sense. If you don't do this, the tree becomes wallpaper.

Continuous Discovery — At Least 3 Customer Interviews Per Week

Here's the rule I steal from Torres: a PM who isn't doing at least three customer interviews per week is not doing discovery.

That sounds aggressive until you do the math. Three interviews × 45 weeks = 135 customer conversations per year. Most PMs do 30. The compounding effect on pattern recognition is enormous. By the end of year one, you can predict what a customer is going to say in the first five minutes, and that's when you start running interviews that pressure-test specific assumptions instead of fishing for vague pain.

Quarterly research sprints are the opposite of this. You batch up your unknowns, hire a research vendor, get a 40-page deck, and try to retrofit the findings onto a roadmap that's already half-committed. By the time the deck lands, the world has moved.

Weekly interviews fix three things at once:

1. Recency. Pain you heard last week beats pain you heard last quarter.
2. Iteration. You can adjust your interview script based on what you heard yesterday. Sprints don't let you do that.
3. Stakeholder credibility. When the CRO says "customers want X," you've talked to nine of them in the last three weeks and can say "actually, three of them mentioned X, but the bigger pattern was Y." That's a different conversation.

Recruiting interviews without burning out CSMs

The recruiting problem is real. Three solid sources, ranked by quality:

• In-app recruiting prompts. A simple banner ("PM here, can I get 25 minutes of your time? $50 Amazon gift card.") converts at roughly 1-2% of weekly actives in B2B. If you have 10K WAU, that's 100-200 conversations available per week. Most PMs never tap this because they're scared to ask.
• CSM intros. Pre-negotiate a quota ("I need 5 intros per month from your book of business") written into the CSM's monthly goals. Without a quota, this falls apart in week three.
• Lost-deal interviews. Talk to people who evaluated and rejected you. They'll tell you things current customers won't, because they have nothing to lose.

A $50 gift card is the right threshold for most ICP segments. Below that, you get tire-kickers who just want a chat. Above $100, finance starts asking questions. For executive personas (VP+ at companies above 500 employees), you usually need $150-200 or a charity donation, because $50 is insulting to them.

What counts as an interview

A customer interview is not a sales discovery call, a CSM check-in, or a demo. The PM-led interview has one job: understand a specific past behavior or pain. If you're showing slides, demoing, or pitching anything, you're not interviewing. You're selling. Pause and start over.

Assumption Mapping

Every product idea rests on four buckets of assumptions. David Bland's assumption mapping framework, popularized in Testing Business Ideas, borrows from IDEO's classic desirability/viability/feasibility lens and adds usability:

For each assumption, score it on two axes:

• Risk. If this assumption is wrong, does the whole idea collapse?
• Evidence. How much real evidence do we have right now? (Not opinions. Not "we've talked about this." Evidence.)

Plot them on a 2x2. The top-right quadrant (high risk, low evidence) is where you focus discovery work first. The cheapest test that could kill the idea goes first. If desirability is shaky, run a fake door before you build anything. If feasibility is the killer, build a 2-day spike, not a 6-week MVP.

I keep the assumption map in the same Miro board as the opportunity-solution tree, one frame to the right. Every solution branch points to its top three assumptions. When an assumption gets tested and falsified, I cross it out red and the solution gets demoted or killed.

The Fake Door / Smoke Test

A fake door is the single highest-leverage discovery tool I run. The premise: build the entry point to a feature without the feature behind it. Measure whether anyone clicks. If they don't, the feature is dead before a single line of code gets written.

How it works in practice:

1. Add a button, menu item, or in-app card that promises a capability, like "Schedule recurring reports."
2. When users click, show a "Coming soon, want early access?" form that captures email and a one-line "what would you use this for?"
3. Track click-through rate against the cohort that saw it.

The thresholds I actually use

These are the numbers I've calibrated across three companies. Your mileage will vary, but they're a starting point:

The 5% threshold matters because it's roughly the rate at which you can justify engineering investment for a feature that addresses a clear pain. Below 2%, you're chasing a 1-in-50 hand-raiser, and the cohort isn't big enough to drive meaningful business outcomes even if every clicker converts.

The ethical guardrails

You can't lie to your customers. The "Coming soon" follow-up state is mandatory, no exceptions. Two more rules:

• Always email everyone who clicked, even if the answer is "we decided not to build this." Tell them what you're doing instead. This costs you 20 minutes and protects the next fake door you ever run.
• Never run a fake door for something you'd never build. If you're doing pure curiosity-mining, do interviews. Fake doors are validation tools, not market research surveys.

I once killed a feature at fake-door stage that the executive team had been pushing for six months: a "predictive lead scoring" upsell module. We launched the entry point to a cohort of 1,400 mid-market admins, expecting at least 8-10% CTR based on sales' anecdotes. We got 1.7%. Of the 23 clickers, 14 thought "predictive lead scoring" meant something completely different from what we were planning to build. We pulled the feature from the roadmap on a Friday, redirected the squad to a different opportunity, and the new bet shipped six months later at 41% adoption. The fake door cost us four days of design and dev time. The feature would have cost a quarter.

Prototype-Driven Validation

When a fake door clears the 5% bar, you've proven demand. You haven't proven the solution works. That's the prototype's job.

I match the prototype fidelity to the assumption I'm testing:

• Figma click-through prototype. For testing usability and information architecture. Five users tested via Maze unmoderated tests will surface most catastrophic UX problems. Cost: 1-2 days of design.
• Concierge MVP. When feasibility or workflow assumptions are the killer, do the work manually for 5-10 customers. If a customer wants an automated competitor-analysis report, generate the first ten by hand and email them. If customers stop opening the emails by week three, the underlying value isn't there.
• Wizard of Oz. The front-end is real, the back-end is humans. Useful when you need to validate behavioral data (do users actually upload the file? do they come back?) without building real infrastructure.
• Hard-coded vertical slice. A real but narrow build. One persona, one workflow, ugly but functional. Ship to 10-20 design partners. This is your last cheap test before a real engineering investment.

Don't skip levels. Don't go from "the CRO asked for it" to "vertical slice" without a fake door and a prototype in between. Every skipped level is a multiplier on your blast radius if the assumption was wrong.

The Mom Test (Don't Lead the Witness)

Rob Fitzpatrick's The Mom Test fixed my interview practice more than any other single resource. The premise: people lie to you in interviews, especially when they like you. Your job is to ask questions that get you the truth even from your own mother.

The three rules:

1. Talk about their life, not your idea. "What's the worst part of your Monday morning?" beats "Would you use a tool that fixes Monday mornings?" The first question can't be flattered. The second one can.
2. Ask about specifics in the past, not generics about the future. "Tell me about the last time this happened" beats "Would you do X?" Past behavior is data. Future intent is fantasy.
3. Listen more than you talk. A good interview is 80% them, 20% you. If you're explaining your product, you're done. End the call, take notes, do better next time.

The single most damaging anti-pattern I see in PM interviews is the demo disguised as discovery. You schedule a 30-minute call to "learn from a customer." Twenty minutes in, you've shown them three mockups and asked "would this be useful?" They say yes, because they're polite, because they're confused, because they want the call to end. You log a "validation interview" in your notes. You ship the feature. It dies.

If you catch yourself opening Figma during a discovery call, hang up and start over. That's not interviewing. That's selling.

When to Kill a Discovery Thread

Killing your own ideas is the hardest skill in product. Three signals tell me a thread is dead:

• Three failed assumption tests in a row. Fake door under 2%, prototype tested with five users and three got stuck, concierge MVP saw no repeat usage. That's not bad luck. That's the universe telling you to stop.
• No pull from interviews after 6-8 conversations. If you've talked to eight customers about a problem and not one has volunteered "yes, this is a real pain we'd pay to solve," the opportunity isn't there. Interviewees will hand-wave for one or two conversations. By eight, the pattern is honest.
• Opportunity scores below threshold. I rank every opportunity in my tree on three dimensions: frequency (how often the pain hits), severity (how bad when it does), and reach (what % of our ICP feels it). If two of three are weak after a month of discovery, the branch dies.

When I kill a thread, I write a one-page kill memo. Not for politics. For me, six months from now, when someone resurrects the idea and I need to remember why I parked it. Template:

Idea: [name]
Opportunity it was meant to address: [opportunity from tree]
Assumptions tested: [list]
Evidence collected: [bullets]
Reason killed: [the specific failure]
What we'd need to see to revisit: [the conditions]
Date: [YYYY-MM-DD]

The kill memo lives in the same Notion folder as the opportunity-solution tree. When the CRO comes back six months later asking "whatever happened to predictive lead scoring," I send the memo. Two minutes of conversation, not two weeks of replaying the same debate.

My Weekly Discovery Cadence

Here's the rhythm I run, in case it's useful as a starting template:

• Monday morning. Three interview slots get booked for the week. I confirm them, prep questions, and update the interview tracker. Recruiting happens via in-app prompts (running continuously) and CSM intros.
• Tuesday-Thursday. Interviews happen, 45 minutes each. Notes go into Dovetail. Highlight reels get shared with eng and design (five-minute clips, not transcripts). Engineers actually watch clips.
• Thursday morning. Solo opportunity-tree review. 30 minutes. New opportunities added, dead branches pruned. Assumption map updated.
• Friday afternoon. One assumption test ships every sprint (fake door, prototype, or concierge MVP). Friday is when I write the spec for next sprint's test.

That's it. No quarterly research sprint. No 40-page decks. Three interviews a week, one opportunity tree, one assumption test per sprint. The boring discipline beats the dramatic effort, every time.

The PMs I respect most don't have better instincts than the rest of us. They have better discovery practice. They've talked to 135 customers this year, run 26 fake doors, killed 18 ideas, and shipped the four that survived. That's why their features hit 40% adoption while everyone else stares at 9%.

You don't need a bigger budget or more researchers. You need three interview slots on next week's calendar and the discipline to keep them booked when the quarter gets noisy. Start there.

Learn More

• Product Manager Job Description Template
• Roadmapping Without Lying to Stakeholders
• Writing PRDs That Engineers Actually Read
• PM Metrics: Outcome vs Output, North Star, Leading Indicators