The old path looped through seven steps; the new one keeps just four

AI doesn't let founders skip any stage — what it removes is the default binding between stages. Entering a new stage used to automatically mean hiring more people, picking up a new skill set, and raising another round. That binding is now undone.

The playbook is specific about what AI replaces at each step. In research, it's an on-call domain expert for competitive analysis, market sizing, financial modeling, and drafting investment memos. In coding, it's an engineer who's always online and never blocked, compressing what used to be a whole team's workload into something a founder can deliver solo. In operations, it's an on-demand automated ops team — updating the CRM as deals move, writing the weekly report itself, and keeping product docs in sync as the product changes.

The upshot: the founder's role shifts wholesale — from the "doer" writing code, managing people, and handling daily chores, to the "orchestrator" generating ideas and directing these AI tools to execute them. The playbook flags one change here as the most consequential: it lets people with industry experience but no engineering background start companies too, widening the founder pool well beyond engineers.

Same Claude, three different workspaces

The playbook is explicit: Chat, Claude Cowork, and Claude Code all run on the same Claude — the only difference is the workspace wrapped around it. Pick the wrong one and something that should be effortless turns clunky. The table below is a selection framework you can use as-is.

The playbook's rule of thumb: Chat handles the endless small stuff of running a company — pulling a one-line takeaway out of a dense investment memo, fact-checking a claim before a board meeting. Claude Cowork handles the genuinely time-consuming knowledge work — turning a folder of customer call transcripts into a themed findings doc, pulling metrics from connected tools every Monday morning into a KPI brief. Claude Code is the coding environment that stands in for an engineer on the team — going from prototype to production, migrating old MVP-era code — none of it has to wait on more hires.

Task is a quick question, a rewrite, or brainstorming → use Chat (fast, conversational, no setup needed). Task is research, analysis, or turning your files and systems into a finished document → use Claude Cowork (reads folders, connects to integrations, runs skills, can be scheduled). Task is writing code, testing, or shipping software → use Claude Code (reads the codebase directly, has diffs, git, a dev environment). All three run on the same Claude — the only difference is the workspace wrapped around it.

Don't rush to code — nail down whether this is even a real problem

Every founder starts from the same place: a problem they can't stop thinking about. The Idea stage has one rule — no building until the evidence is in. The work here is research, customer interviews, competitive analysis, and an honest look at the evidence stacked against you, and all of it has to happen before Claude Code writes a single line of production code.

The playbook lays out the Idea stage as a sequence of questions to answer in order: Is this problem real, specific, and frequent enough to build a company around? Who has it, and does that add up to a market? Is anyone else already solving it, and how well? What would a solution actually need to do to fix it, and does my idea do that? Together they answer the one question that matters: is this worth building?

The key is getting specific before you move. "Everyone hates doing expense reports" is just an observation — you can't test it. Turn it into a testable hypothesis, and it actually holds up.

Exit criteria: all three questions must answer yes

The Idea stage's exit condition is problem-solution fit — solid qualitative evidence (mostly from real conversations) proving you're solving a real problem for real people, before you go build the solution. All three questions need to answer yes before you move on:

Three traps at this stage

How to work through the Idea stage with Claude

Start by sharpening your hypothesis until it's actually testable. Claude is most useful here for forcing specificity: exactly who has this problem, how often, how bad, what they do about it now. A problem statement that can't answer those isn't testable yet.

Describe your problem statement to Claude and have it help sharpen it into a testable hypothesis. Bad example: "contract review is too slow" — untestable. Good example: "in-house legal teams at mid-size companies spend 3+ days per contract review because redline changes get managed over email instead of a single version-controlled document" — testable. Once the hypothesis is sharpened, the next step is having Claude flip around and attack your idea, specifically hunting for evidence that would disprove it.

Next comes competition. The playbook names a founder-specific blind spot called competitor neglect — being so focused on your own vision and execution that you systematically underrate what everyone else in the space is doing. The fix is to have Claude argue the other side: why a specific competitor would win, and you would lose.

Have Claude map your competitive landscape in layers: direct competitors, indirect competitors, potential acquirers, and adjacent players who could cross into your space. Then have it argue why each layer is a genuine threat to you — not hand you the weakest, easiest-to-dismiss version of the argument.

Then there's designing customer interviews. The playbook says the most common rookie mistake is asking a broad, future-facing question ("would you use a product like this?") instead of a specific, past-facing one ("walk me through the last time you ran into this problem"). Have Claude audit your hand-written questions and flag anything leading, hypothetical, or too broad.

Write your interview questions by hand first, then have Claude review them. Explicitly ask it to flag which questions are leading, which are future-facing hypotheticals (like "would you use a product like this?"), which are too broad, and which are likely to draw a people-pleasing answer instead of a real one. Then have it design follow-up prompts for the two or three points in the interview where the other person is most likely to dodge.

Only once validation is solid and the solution concept has been stress-tested does Claude Code enter the picture. This step isn't about building the real product — it's about creating a hands-on sample of the functionality for real people to touch, to use in conversations with customers and investors.

Identify the single core interaction your solution depends on, and have Claude Code build only that. Once it's built, put it in front of 5 people who match your validated target user profile, watch their genuine reactions, and decide whether to keep building or go back and revalidate.

Building it is just the start — proving someone can't live without it is what counts

Many founders treat the MVP as a pure construction phase, but at its core it's still evidence-gathering — just now the evidence is about the solution: whether a real, identifiable group of people finds it valuable enough to use, come back to, pay for, and recommend.

The playbook sets three goals for the MVP stage. First, turn the validated problem into a product real users will use — the smallest, most focused version, not a full build stuffed with roadmap features. Second, move fast without racking up technical debt that compounds. Third, invest in durable context from day one — that's what keeps AI acting as an amplifier instead of a source of entropy. Its exit condition is real evidence of product-market fit — meaning at least one of retention, payment, or referral has been proven out.

Four traps, two distinctly of the AI era

Before opening Claude Code, walk Claude through what you're building: the core problem the product solves, who it serves, and the realistic scale you expect over the next six months. Have it help define the architectural principles to follow at the MVP stage, the dependencies to avoid, and the tradeoffs you're consciously accepting at this stage. Save the output of that conversation as a CLAUDE.md file — the architectural context doc every subsequent Claude Code session should read.

Before any real user touches the product, hand the core application code to Claude with a clearly scoped review task: check authentication and session management, data exposure in API responses, input validation and injection risk, and dependencies with known vulnerabilities. Take every finding seriously, and route anything touching authentication, secrets, or data handling through human review.

The playbook notes: Claude Code's AI scanning is an aid, not a replacement for security tools, and it doesn't replace human review at higher-risk points either. There's also Claude Code Security, which can scan further for vulnerabilities and produce patches for human review — at time of publication it was still in a limited beta, so check availability before relying on it.

Exit criteria: the Sean Ellis test plus the effort test

Declaring product-market fit and moving from MVP to Launch ultimately comes down to a judgment call that blends founder instinct with collected evidence. The playbook offers two useful yardsticks. The first is the Sean Ellis test: ask active users one question — how would you feel if you could no longer use this product tomorrow? If more than 40% say "very disappointed," that's a meaningful signal of product-market fit.

The second is the effort test: before you find product-market fit, retention runs on the founder's constant effort — frequent outreach, incentives, manual follow-up. After you find it, the product starts doing that work on its own. When the feeling shifts from "you're pushing users along" to "the product is pulling users in," that change in where the effort comes from is one of the clearest signs something real has happened.

If three iterations haven't moved the needle

If you've run three or more iterations and the key product-market fit metrics still haven't budged, the playbook says that's not failure — it's the system working as designed. The MVP stage exists specifically to surface this information before you over-invest in the wrong answer. Before deciding what's next, run a diagnosis with Claude.

If you've completed three or more iterations and the key product-market fit metrics still haven't improved, don't rush to decide what's next — run a diagnosis with Claude first. Feed it your retention data, user feedback, and original problem hypothesis, and ask three questions: is there a segment in this data reacting noticeably differently from everyone else? Is the gap between the value you designed for and the value users actually experience a positioning problem or a product problem? What conditions would the current product need to meet to reach genuine product-market fit, and given what you're seeing now, is that realistic?

From "I carry it alone" to "the system runs itself"

If the MVP stage proves the product deserves to exist, the Launch stage proves the business deserves to grow. Beyond getting the product production-ready, you also have to harden the infrastructure underneath it and actually build a company around it.

The playbook flags a specific turning point here: during Idea and MVP, the company is naturally founder-centric because you need full situational awareness and a tight feedback loop. By Launch, a founder still gripping every thread by hand becomes the bottleneck. The goal isn't to remove yourself from the company — it's to build the operational systems that free up your attention for the decisions only a founder can make.

Exit criteria: all three must hold at once

How to tell you've become the bottleneck

The fix is a thorough inventory of everything you personally handle, from the smallest task to the highest-stakes decision — sorting out what can be systematized, what can be delegated (not necessarily to you), and what genuinely still deserves a founder's time and attention.

The playbook flags two more items you can't skip: the technical debt taken on for speed during MVP now starts accruing interest, getting more expensive the longer it's deferred, so a systematic architecture audit, targeted refactoring, and real test-coverage expansion are due. Security and compliance can no longer be put off either — once you're handling real user data, processing payments, or selling into a regulated industry, every compliance requirement that didn't apply at the prototype stage now does. Treat everything that surfaces as mandatory, not optional.

Have Claude Code run a full architecture audit on the MVP codebase and produce a prioritized list: structurally fragile spots, test-coverage gaps, refactoring candidates. Hand that list to Claude and have it schedule the debt paydown across the next few sprints: what must be fixed before the next release, what can run in parallel with new feature work, and what's acceptable debt to carry at this stage.

The moat grows out of the data flywheel and workflow lock-in

Entering the Scale stage, the founder's role shifts once more, from builder to outward-facing executive, with the daily work increasingly about the company itself rather than the product. In scale terms, this is the move from thousands of users to millions, from one market to several. The goal changes from steering by gut feel close to the user, to building systematic growth backed by a mature operating organization.

For an AI-native startup, the playbook says, what you should be building at this stage is a moat held up by accumulated depth: the expertise baked into the product, the depth of integration with the other tools and platforms the product and its users depend on, and proprietary system data and workflows. Its exit condition is no longer a single milestone but a threshold event — the company staying sustainable even as the founder handles less and less of the day-to-day directly.

Any one of these three outcomes counts, and all of them share the same prerequisites: growth that's systematic and auditable, a product moat that holds up under scrutiny, and an organization mature and sustainable enough to run itself. Get here, the playbook says, and congratulations — your startup has turned from a bet into a business.

Moat one: the compounding user-data flywheel

Users generate behavioral signals as they interact with the product — which outputs they accept, which they reject — and those signals feed the roadmap. Over time you learn the patterns, preferences, and edge cases specific to your particular user base. That's what compounding means here: every improvement makes the product more useful, driving more usage, generating more feedback, which drives further improvement.

The playbook stresses that this data is time-locked, context-specific, and impossible for a copycat to replicate — you can't buy the behavioral fingerprint left by thousands of users refining their workflows inside your product.

Feed Claude the state of your product interaction data: what you've collected, for how long, and what you've learned about how usage evolves over time. Have it identify the three strongest behavioral patterns and design a feedback loop for each that translates into systematic product improvement. Then have it help you draft a one-page moat narrative: how your data flywheel started turning, how long it's been turning, and why a well-funded competitor starting today still couldn't catch up within two years.

Moat two: deep workflow lock-in

Data network effects make a product harder to copy; workflow lock-in makes it harder to leave. The longer users run your product in their daily operations, the deeper it embeds — they build automations on top of it, train staff on it, connect it to data sources and other tools. The prompts they've developed, the processes they've refined, the outputs they've standardized, all take shape around how your product works. At that point, switching vendors stops being a product decision and becomes an entire operational project. The playbook has you use Claude to segment customers by integration depth first, to see where the product has really stuck and where it still needs to go deeper.

The hardest part of Scale: genuinely letting go

For a founder who's been hands-on since day one, handing off the operational layer is both a structural problem and a psychological one. Hand off too much too fast — especially to AI automation systems — and key decisions get made without the context only a founder can provide. Hold on too long and you become the bottleneck again. The core challenge is surfacing the institutional knowledge that lives only in the founder's head or scattered across undocumented workflows, and encoding it into a documented, auditable, transferable system. The playbook's approach is to have Claude map the bottlenecks, then simulate what happens if you disappear for a week.

Have Claude map the bottlenecks in your current operating layer: every workflow, decision, and approval that passes through your hands. Then have it simulate what happens to each one if you're completely unreachable for a week. Whichever workflows stall are the ones where you're still too involved, slowing things down.

Case studies: what a grown-in moat looks like

The playbook closes with case studies from more than a dozen real companies; two numbers make the case for "accumulated depth" best:

The four-stage prompt cheat sheet

Every exercise from the playbook is collected here, grouped by stage, so you can find your current stage and copy directly. The tool assignments stay consistent: Claude for research and strategy, Claude Code for writing code, Claude Cowork for operations automation.

What founders need to do hasn't changed: find a real problem, build something that solves it, grow it into a company that matters. What's changed is the road to get there — AI compresses quarters into weeks, and a validation cycle that used to take months into an afternoon.The Founder's Playbook · Anthropic

The playbook does two things. First, it attaches a "graduation checklist" to every stage, turning "should I move on" from a gut call into something you can check off. Second, it names a shift: AI has broken the old binding where entering a new stage automatically meant expanding the team and raising another round — the bottleneck moves from what you're capable of building to what you choose to build. So how exactly do these "exit criteria" hold you back? See the figure below.

The four stages are Idea, MVP (the minimum viable product — build only the most essential version), Launch, and Scale. The playbook turns each stage into a "gate." Follow along as XiaoHu builds a tool that automatically reconciles expense reports for mid-size companies:

The four stages work like four gates — each one only opens once you've checked off that stage's exit criteria; if you can't check them all, don't move on yet. The playbook turns "should I move on" from gut feel into a checklist.

Every gate's exit criteria come with a ready-to-copy Claude prompt (research and strategy use Claude, coding uses Claude Code, operations automation uses Claude Cowork — the full set of 10 is in the article's cheat sheet, ready to copy in full). Each stage also lists traps unique to the AI era — mistaking a prototype for validation, scope creep from features being too easy to add, self-deception from having AI argue your own case for you — with warning signs and fixes covered in the full article.

Most people have no real sense of "AI makes startups faster." The playbook gives a concrete scale: validating a startup idea used to take months — now it's compressed into an afternoon.