ع
Start Topics Teams Reference What's new Saved
tracks

Founders & PMs

Go from a vague idea to a spec, a clickable prototype, or a clear decision — and read your own codebase without a developer in the room — all from the Claude Desktop chat, no terminal required.

11 playbooks
playbooks

Full worked systems, not one-off prompts — each walks the whole workflow end to end. Pick one and follow it.

Build a product-context doc Claude can actually use

Capture what you're building, who it's for, and what you're betting on into one reusable doc — then feed it into every other Founders playbook so "our strategy" finally points at something concrete.

medium ~1 hour to build, reused forever open the playbook

Map your market and your competitors into a reusable brief

Turn the messy reality of who-else-is-out-there into a reusable market-landscape.md that grounds your roadmap, your board narrative, and every positioning call.

medium ~45 min to build, refresh quarterly open the playbook

Read your codebase in plain English

Point Claude at your own repo and ask what happens when a user signs up, which files run in what order, and where a new feature would live — no developer in the room.

medium ~30 min open the playbook

Pressure-test an idea into a v1 spec

Turn a vague feature idea into a crisp v1 spec — user stories, the edge cases you're not thinking about, and an explicit out-of-scope line — before anyone builds.

easy ~20 min open the playbook

Build a clickable prototype to decide

Turn a spec into a single openable web page you can click through — a throwaway you build to feel the flow and make the call, never to ship.

medium ~30 min open the playbook

Synthesize feedback into a roadmap signal

Turn a pile of support exports, sales notes, and interview transcripts into the recurring themes, a real-pattern-vs-loud-one-off read, and a few bets — each traceable to what customers actually said.

medium ~40 min open the playbook

Turn options into a decision you can defend

Lay tradeoffs side by side and get a recommendation with its reasoning and the biggest risk of each path — so you're sanity-checking a call, not starting one cold.

medium ~30 min open the playbook

The weekly stakeholder & investor update system

Turn a metrics export, a few Slack threads, and your own brain-dump into a crisp, on-message update — internal or investor — in about 20 minutes, and faster every week.

easy ~20 min, weekly open the 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 open the playbook

Run quarterly planning and prioritization end to end

Synthesize your strategy, market read, and customer feedback into a defensible one-page quarterly plan — themes, committed initiatives with success metrics, and an explicit cut list — in an afternoon instead of a week of meetings.

advanced ~half a day, once a quarter open the playbook

Build the board & investor narrative

Turn the quarter's strategy, market read, and what actually happened into a coherent board story — a pre-read, a metrics-backed deck outline, and tough-question prep you can defend in the room.

advanced ~2–3 hours per board cycle open the playbook
Go deeper

Founders & PMs with Claude, in depth

The playbooks above are single jobs. These are the long reads behind them — how the work fits together across a quarter, what good looks like, and the judgement calls the prompts assume you have already made. Read in any order.

Guardrails

The non-negotiables before any of this ships. Read the operating guide for the full data, brand, legal, and rollout playbook.

  • Verify before you commit eng time — or a number. Claude states a fact, an effort estimate, or a metric with total confidence and can be wrong. Confirm anything you'll act on, say to a board, or put on a roadmap against the source. A spec or a memo is a starting point, not gospel.
  • A prototype is to react to, never to ship. Treat anything Claude builds as a throwaway you click to feel the flow and kill a bad idea cheaply — production is a separate, deliberate build that engineering owns. Treating the prototype as a head start is how you end up shipping fake-data spaghetti.
  • Keep the sensitive stuff out of a general chat. Specs, public market material, and your own codebase are fine to share; the cap table, unreleased financials, customer PII, and anything under NDA stay in a workspace your company has approved — and you approve each read in the 'Ask permissions' prompt.
  • Give Claude your real source of truth. Feed it your product-context.md and market-landscape.md so "our strategy" and "our market" point at real documents — built once in the Stage 1 playbooks, inherited by every spec, decision, and plan.
  • You own the call; Claude drafts the case for it. Ask for the tradeoffs and a recommendation with reasoning, then make the decision and the cut list yourself — a roadmap you can't defend to your team or your board is worthless.
  • Adapt for Arabic, don't translate. Product docs and customer-facing copy for the region get a real Arabic register, not a machine-translated English doc — a first-class peer of the English, not a fallback.
Read the operating guide

Questions people ask

Do I need to write code to use this?
No. You open the Claude Desktop app and describe what you want in plain language — a spec, a clickable prototype, a read on your own codebase — and Claude does the writing. You react and decide; you don't author the code, and you never touch a terminal.
Can a prototype Claude builds go straight to customers?
No — treat a prototype as a throwaway you build to learn and react to, never as production code. It's there so you can feel the flow and kill a bad idea cheaply before any real engineering starts.
Can it really read my company's codebase?
Yes. Point Claude at your repo and ask, in plain English, what happens when a user signs up — it names the real files and the path. That's how you walk into the eng conversation already knowing the shape of it.
What's a realistic first task?
Pressure-testing a vague feature request into a short spec: ask Claude for the user stories, the edge cases you're missing, and what's explicitly out of scope for v1. The out-of-scope line alone is where it earns its keep.