ع
Start Topics Teams Reference What's new Saved
playbook

From customer request to roadmap-ready, end to end

Take a request from inbox to roadmap-ready — synthesize the demand, spec it, prototype it, scope it against the code, and write the decision memo — so you commit eng time on evidence, the big one that ties the set together.

advanced ~half a day
when to reach for this

A request lands — "can you add a way to save articles for later?" — and the lazy paths are equally bad: build it on a hunch, or bury it because you're not sure. This is the capstone that walks the whole arc in one afternoon: prove the demand is real, sharpen it into a spec, build something clickable to decide, read the code to scope it, and write the memo that commits the resources. The whole arc runs in Claude Desktop — you paste feedback into the chat, double-click an HTML prototype to click through it, and open your repo's folder to scope the work; no terminal required. It chains the other five Founders & PMs playbooks into a single flow, so by the time the feature hits the roadmap, every claim behind it — that customers want it, that it's well-defined, that the flow works, that we can build it, that it's worth it — is backed by something real.

gather this first
  • The triggering request plus the wider feedback pile — support-export.csv, sales-notes.md, transcripts — dropped into the Claude Desktop chat, so you can test whether one email is actually a pattern.
  • Your codebase, openable as a folder in Claude Desktop, and your decision criteria for the quarter (what you optimize for: speed, cost, retention).
  • A roadmap-feature.md working doc to accumulate the spec, the decision note, the scope, and the memo as you go — the through-line that ties the steps together.
the workflow

  1. Prove the demand is real — Synthesize feedback into a roadmap signal

    Start by testing whether the request is a pattern or one loud voice. Building the rest of the arc on a single email is how you spend an afternoon validating noise.

    you ask
    Run the feedback synthesis on the attached files (names already replaced with [customer-n]): is 'save articles for later' a real pattern? How many DISTINCT customers raised it, across which segments, and pull the verbatim quotes behind it. Be honest if it's really just one loud account.

    what you get back A grounded verdict with receipts — "real pattern: 6 of 14 distinct customers across two segments; quotes attached." Or the honest version — "one enterprise account, mentioned 5 times — loud, not broad." If it's noise, you've saved the whole afternoon; if it's real, you carry the quotes forward as evidence.

    If this step says "not a pattern," stop here — that's a successful outcome. Killing a feature on evidence is the cheapest win in the whole flow.

  2. Sharpen it into a spec — Pressure-test an idea into a v1 spec

    Turn the validated demand into a crisp v1, using the customer quotes as the source of the user stories so the spec stays tethered to what people actually asked for.

    you ask
    Using those customer quotes as the source, write a v1 spec for 'save articles for later': 4-6 user stories drawn from the quotes, the edge cases I'm not thinking about, and an explicit out-of-scope line for v1. Append it to roadmap-feature.md.

    what you get back A one-page spec where the stories trace to real quotes, the edge cases are decided (save twice → no-op; deleted article → 'no longer available'), and v1 explicitly excludes folders and cross-device sync. The demand is now a buildable definition.

  3. Build it to decide — Build a clickable prototype to decide

    Make the spec clickable before committing eng. Reacting to a real flow catches the "oh, the Saved tab should be top-level" problems while they're free to fix.

    you ask
    From the spec, build a single self-contained prototype.html (HTML/CSS/JS inline, openable by double-click) with 5 fake articles, a Save button, and a Saved tab. I'll click it and tell you what feels off. Then write the 5-line decision note: does the flow work, what must change, is it worth eng time?

    what you get back An openable prototype.html you click through, then a short decision note — "flow works once Save shows a confirmed state and the Saved tab is top-level; worth building; open risk: unpublished articles." The prototype is a throwaway you built to decide; the note is what you keep.

    A prototype is to decide, not to ship — once the decision note is written, the page has done its job. Don't hand the fake-data HTML to eng as a head start.

  4. Scope it against the code — Read your codebase in plain English

    Ground the build in reality. Open the repo's folder in Claude Desktop and ask in plain English — reading code to scope it needs no terminal and no engineer in the room. Asking where the feature would actually live turns a guess about effort into a scope you can defend to eng.

    you ask
    Open our codebase. For this saved-articles feature, which existing files would an engineer most likely touch, what new files/tables would be needed, and roughly how big is the work (small/medium/large)? I'm scoping the eng conversation, not writing the code.

    what you get back A grounded scope — "touches the article list component and the data layer; needs a new saved_articles table, a Saved view, and a save/unsave API route; medium effort." The estimate is now anchored to what it really touches, not a number you made up.

  5. Commit the resources — Turn options into a decision you can defend

    Pull the whole arc into a single memo that makes the call. This is the document you circulate — and because every input is evidence-backed, it survives scrutiny.

    you ask
    Assemble a one-page decision memo / PRD from roadmap-feature.md: the problem and who it's for, the demand evidence (distinct customer count + quotes), the v1 spec and scope line, the prototype decision note, the eng scope and effort, a clear build/defer recommendation with reasoning, the biggest risk, and the open questions. Then red-team it as a skeptical exec.

    what you get back A roadmap-ready memo — "Build saved-articles in v1: wanted by 6 distinct customers (quotes), medium eng effort, prototype-validated flow; recommend this quarter; biggest risk: unpublished-article handling; open question: retention impact unmeasured" — plus a red-team pass. A call you can defend line by line.

make it your own
  • It dies at step 1: if Synthesize feedback into a roadmap signal says the demand isn't real, that is the deliverable — a documented, evidence-based 'not now' you can send the requesting customer, no further steps needed.
  • Build vs buy fork: if the scope from Read your codebase in plain English comes back 'large,' branch the final step into a full Turn options into a decision you can defend comparing build vs an off-the-shelf option.
  • Make it a standing process (Power Track): wire the chain into a /feature-intake custom command (see the Capabilities tab) so every customer request gets run through the same evidence gauntlet, not just the ones that shout loudest. Custom commands are an opt-in Power-Track step — on Desktop you can keep the chain's prompts in a note and run them in sequence instead.
watch out for
  • Verify the load-bearing facts at every handoff — the distinct-customer count, the eng effort estimate, the quotes. A confident wrong number compounds across five steps; the memo is only as honest as the figures feeding it, so check them against the source, not Claude's recall.
  • This is real customer data and your own proprietary code. De-identify feedback ([customer-n]) before any prompt, treat the codebase as confidential, and remember the memo is exactly the kind of doc that gets forwarded — keep specifics out of anything you wouldn't show the whole company.
  • Claude runs the gauntlet; you commit the resources. It synthesizes, specs, prototypes, scopes, and drafts the memo — but putting a feature on the roadmap is a human decision you own and defend. The whole point is to make that call on evidence, not to remove your judgment from it.

you'll end up with A roadmap-ready decision memo / PRD where every claim — that customers want it, that it's well-defined, that the flow works, that you can build it, that it's worth it — is backed by a real artifact from the five playbooks it chains, so you commit engineering time on evidence instead of a hunch.

Questions people ask

How long does this full chain actually take?
About half a day the first time through — roughly 40 minutes for feedback synthesis, 20 minutes for the spec, 30 minutes for the prototype, 30 minutes scoping the codebase, and 30 minutes on the decision memo. The time is front-loaded in gathering your inputs; once those are ready, Claude does the assembling at each step.
What do I need to prepare before starting?
You need the triggering request plus your wider feedback files (support export, sales notes, transcripts with names replaced by [customer-n]), your codebase opened as a folder in Claude Desktop, and a `roadmap-feature.md` working doc. The whole arc runs in Desktop — no terminal needed. Your decision criteria for the quarter — what you optimise for — are also essential so the final memo is weighted your way.
Is it safe to feed my codebase and customer feedback into this flow?
Keep both in your sanctioned environment — do not paste proprietary code snippets or raw support exports into public tools. De-identify all customer feedback with `[customer-n]` labels before it enters any prompt, and treat the resulting memo as internal-only, since it summarises both sources.
What if the flow dies at step 1 because the demand isn't real?
That's a successful outcome, not a failure. A documented, evidence-based 'not now' you can send to the requesting customer is exactly what this step is designed to produce — stopping early means you've saved the rest of the afternoon, which is the cheapest win in the whole flow.