تجاوز إلى المحتوى
جرّب المرجع الدورة المحفوظات
العربية
← كل playbooks المؤسّسون ومديرو المنتج

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.

متقدّم ~half a day

متى تلجأ إلى هذا

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. 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.

جهّز هذا أولًا

  • The triggering request *plus* the wider feedback pile — support-export.csv, sales-notes.md, transcripts — so you can test whether one email is actually a pattern.
  • Your codebase, openable in Claude Code, 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.

الـ 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.

    أنت تطلب 
    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.

    ما تحصل عليه 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.

    أنت تطلب 
    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.

    ما تحصل عليه 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.

    أنت تطلب 
    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?

    ما تحصل عليه 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. Asking where the feature would actually live turns a guess about effort into a scope you can defend to eng.

    أنت تطلب 
    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.

    ما تحصل عليه 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.

    أنت تطلب 
    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.

    ما تحصل عليه 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.

اجعله ملكك

  • **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:** wire the chain into a /feature-intake custom command (see the *Features* tab) so every customer request gets run through the same evidence gauntlet, not just the ones that shout loudest.

انتبه إلى

  • 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.

ستحصل في النهاية على 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.