Turn Raw User-Interview Notes into a Prioritized Problem Statement for the Next Sprint

The task

You just wrapped five customer calls for the week. You have a wall of messy notes and a sprint planning meeting Monday. You need one crisp problem statement and a ranked stack of what to build — not another doc nobody reads.

This is for founders running discovery themselves between shipping. It works whether you took notes in a Notion doc, a transcript dump, or bullet points in your phone.

Before AI

Manually, this is a 2-4 hour job: re-read each interview, tag themes in a spreadsheet, cluster, argue with yourself about what's signal vs. one-off, then write the problem statement, then score things. Most founders skip the scoring step and just pick whatever's loudest in their head from the last call. That's how you end up building for your most recent interviewee instead of your market.

The structured approach borrows from the RICE scoring model — Reach, Impact, Confidence, and Effort — but the bottleneck isn't the math, it's getting from raw notes to scorable items in the first place.

The workflow

1. Extract structured pain points from raw notes

Paste your interview notes in. The model pulls out discrete problems with the verbatim quote attached so you can defend each one later.

You are helping a founder synthesize user interview notes. The notes below contain 3-7 customer conversations, separated by headers or obvious breaks. Some are messy, fragmented, or contain my own asides — ignore those.

Your job: extract every distinct pain point, workaround, or unmet need mentioned. For each, output a row in a markdown table with these columns:

| # | Pain point (one sentence) | Who said it (name or "P3") | Verbatim quote or paraphrase | Category (workflow / pricing / integration / trust / onboarding / other) | Frequency (how many interviewees raised it) |

Rules:
- One row per distinct problem. If two people raised the same thing, combine into one row and bump frequency.
- Quote must be from the notes, not invented. If you only have a paraphrase, mark it (paraphrased).
- Do not editorialize. No solutions yet. Just problems as stated.
- If notes are ambiguous, include the row but mark the pain point with [unclear].

Output ONLY the table. No preamble.

Here are the notes:

=== P1 — Maya R., ops lead at a 40-person logistics co. — Tues call ===
- Currently exports CSV from our dashboard every Monday, pastes into Sheets, runs a pivot. Takes her ~90 min/week.
- "Honestly the export is fine, it's that I can't filter by carrier before exporting so I download everything and trim." 
- Asked about Slack alerts — said she'd pay extra for that, currently uses a Zapier hack that breaks "maybe twice a month."
- Pricing: said $300/mo "felt fine" but renewal sticker shock at $480 was rough.

=== P2 — Devon K., founder, 8-person agency ===
- Doesn't use the dashboard. Onboarded once, never came back. "I forgot my password and the reset email went to spam, and I just… never logged back in."
- Uses our API directly via a script their CTO wrote.
- Wants webhooks. Mentioned twice.
- Said the docs are "ok but the auth section is rough."

=== P3 — anonymous, SMB owner, found us via Product Hunt ===
- Trial user. Hasn't converted. "I couldn't tell if it would work with QuickBooks without signing up." 
- Wanted a sandbox / demo data mode.
- Pricing page: "the per-seat thing confused me, I'm a team of one."

=== P4 — Priya S., RevOps at mid-market SaaS ===
- Big one: "we can't use you because you don't have SSO." Hard blocker.
- Also mentioned wanting carrier filtering (same as Maya).
- Said Slack alerts would be "nice but not why we'd buy."

=== P5 — Tomás L., solo consultant ===
- Loves the product. Renewed.
- Wishes there was a way to share a read-only view with his clients without paying for another seat.
- "The Zapier integration is the only reason I started, btw."
- Mentioned webhooks would be "cleaner than Zapier."

2. Cluster into themes and draft the problem statement

Now collapse the pain points into themes and force a single problem statement. The "force a single one" part matters — if you can't, you don't have a sprint, you have a roadmap.

Using the pain point table from the previous step, do three things:

A) CLUSTER. Group the rows into 3-6 themes. For each theme, give it a short name, list which row numbers belong to it, and note the total reach (sum of frequencies, with any double-counting flagged).

B) PROBLEM STATEMENT. Write ONE problem statement for the highest-signal theme using this format:
"[Specific user type] currently [current behavior/workaround] because [root cause], which costs them [concrete cost — time, money, or deals]. They would know we solved it when [observable success signal]."
Keep it under 60 words. No buzzwords. No "seamless," no "delight."

C) SECOND-TIER STATEMENTS. Write one-sentence problem statements for the other themes, in case the top one turns out to be wrong.

Output as three clearly labeled sections: ## Themes, ## Primary problem statement, ## Backup problem statements.

3. Score and rank using RICE

Now apply the prioritization math. We're using the formula (Reach x Impact x Confidence) / Effort as a forcing function — not because the numbers are precise, but because guessing them out loud surfaces disagreements with yourself.

Take the themes from the previous step and score each one using RICE.

For each theme, output a row with:
- Theme name
- Reach: how many users in our interview set (out of 5) + a rough extrapolation guess (low / med / high) for the broader base
- Impact: 0.25 (minimal), 0.5 (low), 1 (medium), 2 (high), 3 (massive) — based on whether this is a "nice to have" vs. a "blocking the deal" type problem
- Confidence: 50%, 80%, or 100% — be honest. One interview = 50%. Multiple corroborating + verbatim quote = 80%. Hard blocker stated explicitly = 100%.
- Effort: t-shirt size (S / M / L / XL) AND a rough person-week estimate. If you genuinely can't tell from the problem statement alone, say "needs scoping" and assign M as placeholder.
- RICE score: (Reach_count × Impact × Confidence_decimal) / Effort_weeks

Then output a ranked list, highest RICE first, with a one-sentence "why this rank" justification for each.

Finally, recommend: which ONE theme should be the focus of the next sprint, and which 1-2 should be explicitly deferred (with reason). Flag any theme where Confidence is below 80% as "validate before building."

4. Convert the winner into sprint-ready user stories

For the #1 ranked theme from the previous step, generate 3-5 user stories in this format:

"As a [specific user type from the interviews], I want to [capability] so that [outcome tied to the problem statement]."

Then for each story, add:
- Acceptance criteria (3-5 bullets, testable)
- Out of scope (1-2 bullets — what we are NOT doing this sprint)
- Open question for the founder to resolve before kickoff (1 bullet)

End with a "Kill criteria" section: what would we learn in the first 3 days of the sprint that should make us stop and re-scope? Be specific.

Gotchas

• Small-n bias. Five interviews is not a market. If your top theme came from one loud customer, the Confidence score should drop to 50% and you should validate before building. The model will happily generate a confident-looking problem statement from a single data point — that's on you to catch.
• Verbatim quotes drift. Re-check the quote column against your raw notes. The model occasionally tightens up paraphrases until they sound like a quote. If a quote isn't in your notes verbatim, mark it (paraphrased) before sharing with the team.
• RICE precision theater. The score is a sorting tool, not a truth. If the top two themes are within 20% of each other, treat them as tied and pick based on strategic fit, not the decimal.
• The "we already know this" trap. Sometimes the prioritized theme is something you've heard for six months and already decided not to build. That's a real signal — either build it or write down explicitly why you're still saying no.
• Notes quality is the ceiling. If your notes are "good call, Maya wants filters," you'll get a thin table. The workflow rewards notes that capture verbatim language and context, not your interpretations.

Time saved

A typical sprint planning prep — re-reading notes, clustering themes, drafting a problem statement, and roughing in priorities — runs 2-3 hours when done carefully and gets skipped or done in 20 rushed minutes when it isn't. This workflow gets you to a defensible problem statement and ranked stack in roughly 15-20 minutes of paste-and-review, with the verbatim quotes preserved so you can defend each call to your team. The savings are real on weeks you actually would have done the work; on weeks you'd have winged it, the value is in not winging it.

What we got when we ran it

We executed every prompt above, in order, against the sample input (model: claude-sonnet-4-6). Outputs below are real and unedited apart from length truncation.

Step 1 output

| # | Pain point (one sentence) | Who said it | Verbatim quote or paraphrase | Category | Frequency | |---|---|---|---|---|---| | 1 | Users cannot filter by carrier before exporting, forcing them to download all data and trim manually. | P1 (Maya R.), P4 (Priya S.) | "I can't filter by carrier before exporting so I download everything and trim." (Maya); also raised by Priya (paraphrased) | workflow | 2 | | 2 | The Slack alert integration relies on a fragile Zapier workaround that breaks regularly. | P1 (Maya R.) | "a Zapier hack that breaks maybe twice a month" | integration | 1 | | 3 | Renewal pricing increases without warning cause sticker shock for existing customers. | P1 (Maya R.) | "$300/mo felt fine but renewal sticker shock at $480 was rough" | pricing | 1 | | 4 | Password reset emails go to spam, causing users to permanently abandon the product after onboarding. | P2 (Devon K.) | "I forgot my password and the reset email went to spam, and I just… never logged back in." | onboarding | 1 | | 5 | The API auth documentation is unclear or insufficient. | P2 (Devon K.) | "the docs are ok but the auth section is rough" | integration | 1 | | 6 | Webhooks are not available, forcing users to rely on workarounds. | P2 (Devon K.), P5 (Tomás L.) | Mentioned twice by Devon (paraphrased); "webhooks would be cleaner

…output truncated at 250 words.

Step 2 output

Themes | Theme name | Row #s | Total reach | Notes | |---|---|---|---| | **Missing or broken integrations** | 2, 6, 10 | 4 | Rows 2 and 6 share one interviewee (Maya/Zapier); row 10 is independent. No double-counting across interviewees. | | **Data access and filtering gaps** | 1, 11 | 3 | Maya appears in row 1; Tomás in row 11. No overlap. | | **Pricing confusion and structure** | 3, 9 | 2 | Two different interviewees, no overlap. | | **Onboarding and re-entry failures** | 4, 8 | 2 | Two different interviewees, no overlap. | | **Pre-signup trust and clarity** | 7 | 1 | Single interviewee. | | **Auth and documentation gaps** | 5 | 1 | Single interviewee. | **Highest-signal theme: Missing or broken integrations** (reach: 4, raised by P1, P2, P4, P5) --- ## Primary problem statement Operations and technical users currently build fragile Zapier workarounds or write custom scripts because the product lacks webhooks and SSO, which costs them engineering time, recurring breakage, and — in at least one case — a full deal. They would know we solved it when they can connect their existing tools without writing or maintaining custom code. --- ## Backup problem statements - **Data access and filtering gaps:** Users who need carrier-level data currently export everything and reshape it manually in Sheets, burning ~90 min/week, because filtering is unavailable before export; solo consultants face the same access wall when sharing outputs with clients.

…output truncated at 250 words.

Step 3 output

RICE Scoring Table | Theme | Reach (interview set) | Reach extrapolation | Impact | Confidence | Effort | Effort (person-weeks) | RICE score | |---|---|---|---|---|---|---|---| | Missing or broken integrations | 4 of 5 | High — integration gaps are a known deal-blocker at scale | 2 | 80% | L | 8 | (4 × 2 × 0.80) / 8 = **0.80** | | Data access and filtering gaps | 2 of 5 | Med — filtering is table-stakes in ops tooling | 1 | 80% | S | 2 | (2 × 1 × 0.80) / 2 = **0.80** | | Pricing confusion and structure | 2 of 5 | Med — per-seat confusion is common in SMB tools | 1 | 50% | S | 1 | (2 × 1 × 0.50) / 1 = **1.00** | | Onboarding and re-entry failures | 2 of 5 | High — password/spam issues are systemic, not edge cases | 2 | 80% | S | 2 | (2 × 2 × 0.80) / 2 = **1.60** | | Pre-signup trust and clarity | 1 of 5 | Med — integration clarity affects most SaaS trial funnels | 1 | 50% | S | 1 | (1 × 1 × 0.50) / 1 = **0.50** | | Auth and documentation gaps | 1 of 5 | Med — poor auth docs are a known API adoption killer | 1 | 50% | M | 3 | (1 ×

…output truncated at 250 words.

Step 4 output

User Stories: Onboarding and Re-entry Failures --- ### Story 1 **As a new trial user who signed up via Product Hunt or a third-party link, I want the password reset email to reliably reach my inbox so that a single failed login attempt does not permanently end my relationship with the product.** **Acceptance criteria:** - Password reset emails are sent from an authenticated domain with SPF, DKIM, and DMARC records correctly configured - Reset email is delivered within 60 seconds of request in testing across Gmail, Outlook, and Apple Mail - Subject line and sender name do not contain words on common spam trigger lists (to be confirmed against a tool such as Mail-Tester) - A confirmation message is shown on screen after requesting reset that tells the user to check their spam folder, with the exact sender address named - QA sends 20 test reset emails across 5 email providers and measures a delivery-to-inbox rate of ≥95% **Out of scope:** - Redesigning the full login or authentication flow - Adding social login or SSO (tracked separately under integrations theme) **Open question for founder:** - What domain and sending service is the reset email currently sent from, and do we have access to DNS records to make SPF/DKIM changes, or does that require a third party? --- ### Story 2 **As a trial user evaluating the product before committing, I want access to a sandbox mode pre-populated with realistic demo data so that I can determine whether the product

…output truncated at 250 words.