Product discovery needs underserved-need ladders

Discovery usually starts with useful mess. A sales call mentions a complaint. A support ticket repeats a workaround. An interviewee describes a painful ritual. A customer success manager says three accounts asked for the same integration. Soon the team has a board full of quotes, tags, screenshots, and enthusiasm.

That is not yet product evidence. It is raw material.

Product discovery needs underserved-need ladders because roadmap choices are not made by the most memorable quote. They are made by deciding which customer need, in which segment, has the largest satisfaction gap, the strongest evidence, and the clearest next test. A ladder turns discovery from a pile of observations into a ranked artifact that product, design, engineering, and go-to-market leaders can challenge together.

Dan Olsen’s Lean Product Process is a useful anchor here because it puts target customers and underserved needs before value proposition, MVP feature set, prototype testing, and iteration. The sequence matters: if the need is vague, every later decision becomes decorative. His description of the process explicitly moves from target customers to underserved customer needs, value proposition, MVP prototype, customer testing, and iteration in pursuit of product-market fit: Dan Olsen, The Lean Product Playbook.

Discovery is not a quote pile

A quote pile feels productive because it preserves the customer’s voice. That is valuable, but it can also hide the decision. Ten quotes about dashboard exports, five quotes about onboarding confusion, and three quotes about billing anxiety do not automatically tell the team what to build. The team still has to ask: which segment is this from, what job were they trying to complete, how poorly is the current solution serving them, and what evidence would change our confidence?

This is why discovery notes need a second artifact. Keep the raw notes, but do not ask a roadmap meeting to interpret them from scratch. The meeting will drift toward hierarchy, charisma, and recent anecdotes. The loudest account will look like the market. The newest sales opportunity will look like strategy. The most polished prototype will look like proof.

A need ladder prevents that drift. Each row captures one candidate underserved need and ranks it against alternatives. The ladder does not erase judgment. It makes judgment inspectable. If a product lead says the onboarding need should be above the reporting need, the ladder forces the reason into the open: larger segment, sharper pain, weaker workaround, stronger evidence, better strategic fit, or easier next test.

This connects directly to the discipline in Discovery is not asking customers what they want. Customers can describe friction, constraints, anxieties, and workarounds. They are usually less reliable at designing the roadmap for you. The ladder keeps the team focused on what customers are underserved by, not only on what they requested.

What belongs in an underserved-need ladder?

A useful ladder is small enough to read and specific enough to argue with. For each row, capture eight fields.

First, name the segment. Not everyone who uses the product belongs in the same decision group. A finance admin at a 40-person company, a RevOps manager at a 700-person company, and a founder using the product after midnight may all ask for reporting, but they may not share the same need.

Second, name the job or context. What was happening when the need appeared? Preparing a board update, cleaning a failed import, approving a refund, inviting a new teammate, or checking whether automation ran correctly are different contexts.

Third, write the stated need in plain language. Keep it boring. A good need line might be: identify which imported records failed before the next sales sync. It should not be: build an advanced import observability center.

Fourth, add the observed pain. What did the user do, delay, repeat, avoid, or escalate? This is where the team records behavior rather than preference.

Fifth, record the current workaround. Workarounds are underrated evidence. Spreadsheets, manual checks, Slack escalation, screenshots, duplicate tools, and scheduled review meetings all show that the customer is already paying a cost.

Sixth, estimate the satisfaction gap. The question is not whether the need exists. The question is whether current options leave the segment meaningfully underserved. A need with mild annoyance and many acceptable alternatives should not outrank a need that blocks a weekly operational workflow.

Seventh, rate evidence strength. Use a simple scale such as weak, moderate, strong. Weak might mean one interview and a sales anecdote. Moderate might mean repeated interviews plus support patterns. Strong might include observed behavior, frequency data, willingness to pay, churn risk, or prototype response.

Eighth, define the next test. Every row should have a next learning move: another interview in the same segment, a prototype test, a fake-door experiment, support-log quantification, pricing probe, concierge workflow, or usability test.

How does the ladder change roadmap choices?

The ladder changes roadmap discussion by moving the team from feature comparison to need comparison. Instead of asking whether export filters are more important than onboarding templates, the team asks which underserved need deserves a product bet now.

That distinction matters because features are often bundled guesses. A feature idea may address the need, partially address it, or miss it entirely. If the ladder says the top need is reducing uncertainty before a finance handoff, the roadmap can consider several approaches: better status messages, exception summaries, approval queues, audit trails, or workflow ownership. The team is no longer trapped by the first requested feature.

The ladder also makes trade-offs easier to explain. When a stakeholder asks why a visible customer request is not on the next roadmap slice, the product lead can show the row. Perhaps the segment is too narrow. Perhaps the workaround is acceptable. Perhaps evidence is weak. Perhaps the need is real, but another need has a larger gap and a clearer path to validation.

This pairs well with Product bets need kill criteria, not optimism. The need ladder helps decide what deserves a bet. Kill criteria help decide when that bet has failed. Together, they keep teams from treating discovery as a permission slip to build whatever already sounded appealing.

Where does evidence usually fail?

Evidence fails in predictable places. The first failure is segment mixing. Teams combine enterprise complaints, self-serve friction, and internal opinions into one row, then wonder why the solution feels bloated. Split the row until the segment and context are coherent.

The second failure is confusing frequency with importance. A complaint that appears often may still be low stakes. A rarer need may have high value if it affects renewal, activation, compliance, or a core workflow. The ladder should separate how often something appears from how costly it is when it appears.

The third failure is treating requests as needs. Build CSV export is a request. Reconcile offline numbers before a leadership meeting is closer to a need. The request may still be the right solution, but it should not skip the translation step.

The fourth failure is leaving next tests blank. A ladder without tests becomes a prettier backlog. The point is not to create a permanent ranking. The point is to show what the team currently believes and what would most efficiently improve or challenge that belief.

A practical ritual before roadmap review

Before the next roadmap review, take five discovery notes and turn them into a ladder. Do not start with a large taxonomy. Start with five rows.

For each row, write the segment, job, stated need, observed pain, workaround, satisfaction gap, evidence strength, and next test. Then rank the rows from most promising to least promising. Finally, mark the weakest cell in the top row. Maybe the segment is too broad. Maybe the workaround is assumed rather than observed. Maybe the gap is emotional but not operational. Maybe the next test is too vague.

That weak cell is the work. It tells the team what to learn before converting discovery into delivery.

A good underserved-need ladder does not slow product teams down. It prevents false speed. It keeps customer evidence close to the roadmap while making every leap visible: from segment to need, from need to gap, from gap to evidence, and from evidence to the next test.