How to Decide What to Build Next from Real Customer Evidence

Export the last 90 days from every source into one list with five fields per item: the customer's words, a source link, the account, the date, and plan or ARR. Ninety days smooths out one bad week and still reflects today's product. If feedback is spread across Slack, tickets, Notion, and your CRM, start with how to centralize customer feedback.

A feature request is the customer's proposed solution; a pain point is the problem underneath it. Group on the problem, because different requests often describe one pain:

• "Add a Salesforce sync," "let me export deals to CSV," and "why do I type this twice?" all become reps re-enter deal data in two tools.
• "Dark mode" could mean the dashboard is hard to read at night, or just a preference. The quotes tell you which.

Write each pain point as a one-line problem in the customer's language. Jobs-to-be-done methods push the same way: Tony Ulwick's Outcome-Driven Innovation focuses "on jobs-to-be-done rather than product improvements" (Wikipedia). For naming and nesting rules, see how to build a customer feedback taxonomy.

Use the same four signals for every pain point:

1. Frequency: unique accounts that raised it in 90 days. One customer posting in five channels is still one account.
2. Who is affected: their segments and combined ARR, with pipeline from lost or stalled deals in its own column.
3. Severity: 3 if it blocks a core job or was named in a churn or lost deal, 2 if the workaround is costly, 1 if it is an annoyance.
4. Trend: accounts in the last 30 days against the monthly average of the 60 days before: rising, flat, or falling.

Show ARR next to the account count, never instead of it, so one large logo cannot set the roadmap. Why feature voting fails covers revenue weighting in depth.

Score only the top 5 to 10 pain points, and keep one framework for the quarter so scores stay comparable. Pick it by the decision you are making:

RICE: Reach, Impact, Confidence, Effort

Sean McBride introduced RICE on Intercom's blog as Reach × Impact × Confidence ÷ Effort (Intercom). Reach is people or events per period, Impact runs from 3 (massive) to 0.25 (minimal), Confidence is 100%, 80%, or 50%, and Effort is total person-months.

Fill the first three from Step 3 instead of guessing. One workable mapping: Reach is the account count; severity 3 is Impact 2 or 3, severity 2 is Impact 1, and severity 1 is Impact 0.5; Confidence is 100% when two or more source types agree, 80% for one, and 50% for anecdotes. Effort needs a concrete solution to estimate, so RICE ranks solutions, not raw problems, and McBride says the scores "shouldn't be used as a hard and fast rule."

Opportunity Scoring: Importance Versus Satisfaction

Opportunity scoring comes from Tony Ulwick's Outcome-Driven Innovation, introduced in a 2002 Harvard Business Review article. You survey customers on how important each outcome is and how satisfied they are today, then compute importance + max(0, importance − satisfaction) (Strategyn). Strategyn measures both as the share of top-two ratings and calls important, poorly satisfied outcomes underserved (Strategyn).

On a 0 to 10 scale, 8.1 importance and 3.0 satisfaction scores 13.2; 6.0 and 7.0 scores 6.0. There is no effort term, so add a rough cost check.

Opportunity Solution Trees and Continuous Discovery

Teresa Torres of Product Talk describes the opportunity solution tree as "a simple way of visually representing the paths you might take to reach a desired outcome" (Product Talk): one outcome, then opportunities (unmet needs, pain points, and desires), then solutions, then assumption tests. It is central to her 2021 book Continuous Discovery Habits (Product Talk), and she defines continuous discovery as "weekly touch points with customers by the team building the product, where they conduct small research activities in pursuit of a desired outcome" (Product Talk).

Torres compares sibling opportunities on sizing (how many customers, how often) and on market, company, and customer factors, leaving effort out so teams do not "rule out an opportunity too early." Your Step 3 numbers fill in the sizing; use them to choose who to interview, not to skip interviewing.

A ranked list is an input, not a decision. Ask four questions of each top candidate:

1. Does it move this quarter's outcome, such as enterprise retention or activation?
2. Are the affected accounts in the segment you are trying to win?
3. Is it already in progress, or blocked by other work?
4. Does it fit beside the capacity you reserve for non-customer work, such as security?

Keep the scored order unless an answer says otherwise, and write the reason in one sentence. When a stakeholder wants to jump the queue, ask for the same evidence (how to stop the loudest stakeholder from driving your roadmap). To audit an existing roadmap, run the roadmap evidence check.

Write down why you chose each bet, or nobody will remember by next planning. Attach a brief like this to the roadmap item or ticket:

## [Bet name]
Problem: [one sentence in the customer's words]
Evidence: [n] accounts in 90 days · [segments] · $[ARR] affected · trend [rising/flat/falling]
Severity: [1-3], because [churn, lost deal, or workaround]
Score: [framework and score], confidence [%]
Quotes:
- "[quote]" ([account], [source link])
- "[quote]" ([account], [source link])
Why now: [link to this quarter's outcome]
Not doing: [related requests left out, and why]
Success metric: [what should change] · check on [date]

Teams skip the "Not doing" line, yet it settles next quarter's arguments. On the check date, see whether complaints about the pain point fell. The build from evidence playbook shows how to link each requirement to the insights behind it.