Claude Code for Product Managers: Build Your First Working Prototype in a Weekend (2026)

A weekend, about ten hours of your own time, and one small thing a stakeholder can click: that is the whole ambition of this guide.

Claude Code is an agentic coding tool from Anthropic: you describe what you want in plain English, and it reads your project folder, writes and edits files, runs commands and checks its own work. For a Product Manager (PM), it turns a written brief into a prototype people can click. It does not replace engineers or ship production software on its own.

Tool interfaces change; checked 4 Nov 2026. Every statement about Claude Code in this guide was checked on 4 November 2026 against Anthropic's official documentation (pages listed at the end). If a screen, a command or a menu differs from what you see, trust the live documentation and run claude --version to find out which version you have.

If you only remember one line from this guide, make it this: a prototype is evidence for a decision, so the brief decides how useful it is, your checks decide whether you can trust it, and git decides whether you can undo it. Git is the version-control tool engineers use to save a project at known points and go back to them.

Six questions PMs ask (quick answers)

• Who is this for? A PM, product lead or founder who can write a clear problem statement and has no engineering background. Anthropic's own beginner guide says you do not need to know how to code to start. You do need to be able to judge whether what comes back is right, and most of this guide is about that.
• What do I need? A paid Claude plan or a Claude Console account (the free claude.ai plan does not include Claude Code), a computer on a supported operating system, an internet connection, and an empty folder.
• Do I have to use a terminal? No. Anthropic's desktop app has a Code tab that runs Claude Code without one. The terminal gives you more control, and this guide shows both routes.
• How long does it take? The plan below uses about ten hours across Friday evening, Saturday and Sunday. That estimate is ours, not Anthropic's, and it has cut-off rules so you finish with something to show even if the idea is bigger than a weekend.
• What is the safest way to start? Use a new empty folder or a copy, use fake data only, approve each edit and command yourself until you have seen what the tool does, and put the folder under git before the first change.
• Who builds the real product? Engineers. A prototype is a clickable argument. Hand over the brief, the checks and the decisions, not the code as it stands.

A scene you will recognise

This is an illustrative scenario, not a real company. A PM at a fictional subscription-software company, Acme Billing, writes a Product Requirements Document (PRD) for letting customers change their own plan. The review meeting goes well until an engineer asks, "What happens when a team of four tries to downgrade to a plan that allows three?" The PRD is silent. Everyone in the room has a view, and nobody has a screen to point at.

Now imagine the PM spends one weekend building a clickable version of only that flow, with the rule written into a brief and checked by clicking. On Monday the question is answered by pressing Downgrade and reading the message, and the meeting spends its time on whether the rule is right instead of what the rule is.

That is the job of a prototype: it turns an unanswered question into a visible one. It is a smaller job than "build the product", which is why a weekend can be enough.

Who this guide is for, and who it is not for

What Claude Code is, and what it is not

Anthropic's documentation describes Claude Code as working in a loop of three phases: it gathers context, takes action, then verifies the result, and you can interrupt at any point. Its built-in tools fall into five groups: file operations, search, execution (shell commands, tests and git), web access and code intelligence. The same engine runs in the terminal, in IDE (Integrated Development Environment) extensions for Visual Studio Code and JetBrains, in a desktop app and in a browser at claude.ai/code.

Before Friday: what you need

The weekend at a glance

Two cut-off rules keep the weekend honest. If slice 1 is not working by Saturday midday, shrink the idea until it is. If a check is still failing on Sunday at 1 pm, put it on the known-gaps list and demo what works. A prototype with three honest gaps beats one that looks finished and is not.

Friday: set up safely

1. Install Claude Code (about 20 minutes)

Open a terminal, copy the command for your system from Anthropic's quickstart page, paste it and press Enter. These are the commands on that page on 4 Nov 2026. Because you are running a script, copy from Anthropic's live page, not from a blog, including this one.

macOS, Linux or WSL (Windows Subsystem for Linux):
curl -fsSL https://claude.ai/install.sh | bash

Windows PowerShell:
irm https://claude.ai/install.ps1 | iex

Homebrew:
brew install --cask claude-code

WinGet (Windows):
winget install Anthropic.ClaudeCode

The installer shows no progress while it downloads, so wait. When it finishes, open a new terminal window and run claude --version. A version number means it worked. If the shell says claude is not found, the install folder is not on your PATH yet; the troubleshooting table below has the fix. If you would rather skip the terminal, download the desktop app from Anthropic, sign in and open the Code tab. The app includes Claude Code, so you do not install anything else.

On Windows you can run Claude Code natively or inside WSL. Anthropic's setup page lists sandboxing as supported on WSL 2 but not on native Windows. Git for Windows is optional but recommended.

2. Make a safe room (about 15 minutes)

Never start in your Documents folder, your home folder or your company's real repository. Start in a new empty folder that holds nothing you would mind losing. Anthropic notes that Claude Code can work with your project files and with files elsewhere with your permission, and that starting it in your home directory makes it ask for trust every launch. A dedicated folder avoids both problems.

mkdir -p ~/prototypes/plan-change-flow
cd ~/prototypes/plan-change-flow
git init
git commit --allow-empty -m "Empty starting point"

On Windows, create the folder in File Explorer and use cd with its path. If git refuses to commit and asks who you are, set your name and email once with git config --global user.name "Your Name" and git config --global user.email "[email protected]", then repeat the last line. That empty commit is your first undo point. It also means the worktree feature, which needs at least one commit, will work later.

3. Start Claude Code and choose how much it may do without asking (about 15 minutes)

Type claude in that folder. On first use it opens your browser for sign-in. In the desktop app, open the Code tab, choose the Local environment and use Open folder to pick your new folder. In the terminal you cannot click, so use the arrow keys and press Esc to interrupt Claude at any time. /help lists commands. /exit leaves.

The setting that matters most is the permission mode. Press Shift+Tab to cycle through modes, and read the status bar to see which one you are in.

One thing may surprise you. According to the documentation, from Claude Code version 2.1.283 onward, auto mode is the built-in starting mode for interactive terminal and Visual Studio Code sessions. Check the status bar when you start, and press Shift+Tab until it says manual mode on. In the desktop app, look at the mode selector in the row under the prompt box. In Manual mode, the app shows a diff and waits for you to approve each change.

4. Run a harmless first task (about 20 minutes)

Use the example from Anthropic's terminal guide:

make me a simple webpage that says hello world

Watch what happens. Claude Code proposes creating a file and asks for permission. Approve it, then double-click the HTML (HyperText Markup Language) file it created to open it in your browser. Now practise the controls you will need on Saturday:

• Ask for a small change ("make the heading blue"), then run /diff to see what changed in your folder.
• Press Esc twice with an empty prompt, or run /rewind, and choose to restore the code. The change disappears.
• Ask it to create a folder called notes. That changes your disk, so Manual mode stops and asks. Read the permission prompt: it shows the command and asks whether to proceed. Commands that only read, such as ls, cat and git status, are on a built-in list that runs without asking.

That last prompt offers "Yes, and don't ask again" for some commands. For a shell command, that saves a permanent rule for that command in this repository. Do not click it for anything you could not explain to a colleague. You can review and remove rules with /permissions.

How to write the brief

The brief is the only thing standing between you and a confident, wrong prototype. Claude Code can read your folder, but it cannot read the meeting where a decision was made, the customer call you remember, or the constraint you assume everyone knows. Anthropic's best-practices page makes the same point: write down what the tool cannot find by reading your files. Budget about 50 minutes on Friday evening for the brief. It has four parts.

Acceptance checks matter most, because they are your test script and Claude's too. Anthropic's guidance is to give the tool something it can run that comes back pass or fail, so it can fix its own mistakes instead of waiting for you to find them. Make every check something a person can verify in 30 seconds.

A full example brief (illustrative)

The brief below is an illustrative example for a fictional app, Acme Billing. The app, its plans, its prices and its users are invented for this guide, not a real company or product. Copy the shape, not the content.

BRIEF.md
ILLUSTRATIVE EXAMPLE. Fictional app "Acme Billing". Not a real company.

PROBLEM
Customers on the Starter plan cannot change plan without emailing support.
Support handles every request by hand. The PRD (Product Requirements
Document) says nothing about downgrades, and we do not know which rules a
self-serve plan change needs.

USERS
1. Account owner of a small business (1 to 10 people). Not technical.
 Uses a laptop browser.
2. A support agent who will watch the demo and tell us what is missing.

THE DECISION THIS PROTOTYPE HELPS US MAKE
Is a self-serve plan change worth building, and which rules must the
first version include?

SCOPE
In: pick a plan, see a price preview, confirm, see a downgrade warning.
Out: payments, login, email, real accounts, mobile layout, any server.

PLANS (fictional)
Starter: ₹600 per month, up to 3 users.
Team: ₹1,500 per month, up to 10 users.

DEMO ACCOUNTS (a drop-down on the page)
A: Starter plan, 3 users, 12 days left in a 30-day cycle.
B: Team plan, 4 users, 20 days left in a 30-day cycle.
C: Team plan, 3 users, 20 days left in a 30-day cycle.

RULES
1. An upgrade takes effect today. The charge today is the price difference
 multiplied by days left, divided by days in the cycle.
2. A downgrade takes effect on the renewal date. Nothing is charged today.
3. A downgrade is blocked if the account has more users than the new plan
 allows.
4. Choosing the plan you are already on changes nothing and says so.

CONSTRAINTS
- Plain HTML, CSS (Cascading Style Sheets) and JavaScript in this folder.
 No framework, no build step, no server, no database, no login.
- Fake data only. No network requests.
- Do not install anything, delete anything or touch files outside this
 folder without asking me first.
- To run it, I will double-click index.html.

ACCEPTANCE CHECKS
1. Account A upgrades Starter to Team: the preview shows a charge of
 ₹360 today. (1,500 minus 600, times 12, divided by 30.)
2. Account B tries Team to Starter: blocked, the message names the
 3-user limit, and no confirmation screen appears.
3. Account A chooses Starter: the page says "You are already on
 Starter" and nothing changes.
4. Account C downgrades Team to Starter: the confirmation says it takes
 effect on the renewal date and that nothing is charged today.
5. Reloading the page returns to the start screen with no errors.
6. With the internet switched off, checks 1 to 4 still pass.
7. Everything is readable in a 1280 pixel wide window.

WORKING AGREEMENT
- Start by showing me a plan: every file you will create, in order, and
 every command you expect to run. Wait for my approval.
- Build the smallest working version first (check 1 only), then add one
 rule at a time.
- After each step, run every check you can and show me the exact output.
 Tell me which checks you could not run.
- Explain each file you create in one plain sentence.

Save it as BRIEF.md in your folder. Add a second, much shorter file called CLAUDE.md, which Claude Code reads at the start of every session. Anthropic's memory page recommends keeping each such file under 200 lines and writing instructions concrete enough to verify.

Working agreement for this folder
- This is a throwaway prototype. Plain HTML, CSS and JavaScript only.
- Read BRIEF.md before every task. If it and my message disagree, ask me.
- Work in small steps and run the checks after each one.
- Ask before installing, deleting or leaving this folder.
- Explain every file you create in one plain sentence.

Treat CLAUDE.md as guidance, not a lock. Anthropic says Claude treats it as context, and that anything that must happen every time belongs in a permission rule or a hook. The permission prompts are what actually protect you. For more on how these files work, see The Markdown Files That Power Claude Code and System Prompts and CLAUDE.md. The /init command can generate a starting CLAUDE.md for an existing project, but a new empty folder has nothing to analyse, so write this one by hand.

If you cannot write the brief yet

Do not guess. Anthropic's best-practices page suggests asking Claude to interview you until it could write the spec. Adapted for this example:

I want a clickable prototype of a self-serve plan change for a billing
app, but I have not thought it through. Interview me until you could
write the spec, then write it to BRIEF.md.

Answer its questions, read BRIEF.md carefully, fix anything it assumed, and then start a fresh session so the build begins with a clean context and a written definition of done.

Saturday: plan first, then build in slices

Start in plan mode (about 20 minutes)

Plan mode makes Claude research and propose without editing your files. Enter it with Shift+Tab until the status bar says plan mode on, or start one prompt with /plan. The @ sign pulls a file into the conversation.

/plan Read @BRIEF.md. List anything in it that is unclear or contradictory.
Then give me a step-by-step plan that builds the smallest working version
first. Name every file you will create and every command you expect to
run.

Read the plan like a reviewer

1. Does step 1 give you something you can click? If it starts with infrastructure, ask for a smaller first step.
2. Does it name every file it will create? Plain names, and one sentence for each.
3. Does it list its commands? Look for installs, downloads, deletes and anything that reaches the internet. Your brief said none were needed.
4. Does it restate your rules with your numbers? If it says "calculate proration" without 12, 30 and 360, it has not understood.
5. Does it name its assumptions and its open questions? A plan with none is hiding them.
6. Did it add anything you did not ask for? Login, a database, analytics, a framework. Cut it.
7. Does it say how it will check each step? If not, point it at your acceptance checks.

When the plan is ready, Claude asks how to proceed. The options include "Yes, manually approve edits", which lets you approve each edit, and "No, keep planning", which keeps you in plan mode while you tell Claude what to change. Choose manual approval for the first slice. Press Ctrl+G if you want to edit the plan in your text editor before it proceeds.

Build in four slices

After each slice, stop and review before you ask for the next. Run the page, run the checks yourself, and commit:

git add -A
git commit -m "Slice 1: upgrade preview shows 360 for Account A"

You can also ask Claude Code to commit for you, since it works with git conversationally. Do the first few yourself so the habit sticks.

Steer, do not hope

• Esc stops Claude mid-action and keeps everything up to that point. Use it the moment it heads somewhere you did not intend.
• Esc twice, or /rewind lets you roll the code, the conversation or both back to an earlier prompt.
• /clear starts over. Anthropic suggests that after two failed corrections on the same point, you clear the session and write one better prompt instead of a third correction, because the conversation now contains two wrong attempts for Claude to keep re-reading.
• /compact summarises a long session. /context shows what is taking up space. /usage shows your usage against your plan's limits.
• Type a correction and press Enter without stopping Claude. It reads the message as soon as its current tool calls finish and adjusts.

Anthropic's cost page explains why /clear between unrelated tasks matters: a long session sends its whole history with every new request, so a conversation that has been open for hours uses more of your plan than the work in it suggests.

How to review what it built

You will not read every line of code, and you do not need to. You need a method that finds the problems that matter. Use these four layers, in this order.

1. Read: the plan, the summary and the changes

Read the plan before the build and the summary after it. Then run /diff to see exactly which files changed. Ask the tool to explain: "List every file you created or changed, with one plain sentence each, and tell me which parts are guesses." Then trace one number through the code: "Show me where the upgrade charge is calculated and walk me through it using Account A's numbers." If the explanation does not match your rule, you have found a defect without reading a line of code.

2. Run: do the checks yourself

Claude saying "all checks pass" tells you little. Anthropic's own guidance is to ask for evidence: the command it ran and its output. Then do the checks by hand, in the browser, and record the result.

If you want an automatic version, ask Claude to write a small test file for the upgrade rule using your numbers, run it and show you the output. Anthropic also provides a /verify command that builds and runs the app and looks at the result, which can catch problems that tests miss.

3. Break it: edge cases

• The boundary: a team of exactly 3 users, then 4.
• The empty, the zero and the very large: no users, zero days left, a plan change on the last day of the cycle.
• The impatient user: double-click Confirm, press Back, reload in the middle of a flow.
• The different setup: another browser, a narrow window, the internet switched off.
• The awkward text: a long company name, accents, and Indian-language characters.
• The thing nobody asked: what does the page show if the user does nothing at all?

4. Get a second pair of eyes

Ask for a review from something that did not write the code. Anthropic's /code-review command reviews your changes for correctness bugs, and Anthropic describes this kind of review as running in a fresh subagent that never saw your conversation. To review against your own brief, Anthropic's best-practices page suggests a prompt of this shape: use a subagent to review the changes against BRIEF.md, check that every rule is implemented, report gaps that affect correctness and skip style. Keep the "skip style" part. Anthropic warns that a reviewer asked to find problems will always find something, and that fixing every finding adds layers and tests for cases that cannot happen. Better still, ask an engineer for twenty minutes on Sunday and bring your check table.

Undo, in three levels

Anthropic says checkpoints are for quick recovery inside a session and are not a replacement for version control. We tested the git commands above in a scratch folder: git restore . reverted an edited file but left a brand-new file in place. git log --oneline lists your commits, and git switch -c prototype-try starts a branch if you want to experiment without touching the main line.

Sunday: check, demo, hand off

Demo rules: say "prototype" in the first sentence, show the "fake data" banner, show a failing case on purpose, and list what is not built before anyone asks. Never demo with real customer data. If someone asks whether it can launch next week, the honest answer is the hand-off section below.

Safety rules, in one place

On the point of responsibility, Anthropic's security page is blunt:

"You're responsible for reviewing proposed code and commands for safety before approval."

On data, plan type matters. Anthropic's data-usage page says consumer plans (Free, Pro, Max and Ultra) have a setting that controls whether your data may be used to improve future models, and that for commercial plans (Team, Enterprise and API) it does not train generative models on Claude Code code or prompts unless the customer opts in. Retention periods also differ by plan. Read that page and your account's privacy settings before you decide what to type. Locally, Claude Code stores session transcripts as plain text under ~/.claude/projects/, for 30 days by default, so anything you paste is also sitting on your disk.

What not to prototype

Comprehension debt: shipping what you do not understand

This guide uses the term comprehension debt for the gap between what works and what anyone can explain. Code that passes its checks can still be code nobody on your team can describe, change safely or fix at 2 a.m. A coding agent can widen that gap quickly because it can produce working code faster than a person can read it. It is a risk for engineers, and often a bigger one for a PM, because you may not have the background to notice when something is odd.

Signs you are accumulating it:

• You cannot say, in a sentence, what each file does.
• You do not know why a library, a setting or a folder is there.
• The prototype passes your checks and you still would not bet on it with a new input.
• You are pasting error messages back to the tool without reading them.
• The demo works only on your laptop.

Four habits keep it small:

1. Explain it back. Pick any file at random and explain what it does and why, out loud, to a colleague. If you cannot, ask Claude to explain again in plainer words until you can, or mark that part "not understood".
2. Trace one number. Follow a single value, such as the ₹360 charge, from the screen to the rule and back. It is the fastest way to see whether the logic is yours.
3. Keep slices small. A small change is a change you can still follow. A thousand lines in one go is not.
4. Remove what you cannot explain. Anything that is not needed for a check can usually be deleted. Less code means less debt.

The rule that follows is simple. Never present something as "this is how it will work" if you do not understand how it works. Present it as "this is what we want it to do", and let engineers decide how.

How to hand off to engineers

Hand over the decision, not the code. A prototype is most useful to engineers as a precise, clickable specification.

Ask Claude to draft the note, then read and correct every line, because you are the one who will be asked about it.

Write HANDOFF.md for the engineers who will build the real version.
Sections: 1) The decision this prototype informs. 2) The rules, copied
from BRIEF.md. 3) What is real and what is faked, as a table. 4) Checks
that pass, checks that fail, checks not run. 5) Known gaps and open
questions. 6) Things I did not test. 7) A warning that this code is a
throwaway reference and has not been reviewed. Do not claim anything you
did not run.

In the meeting, lead with the decision, show the recording, walk through the rules, list the open questions, and ask the engineers what they would throw away. Offer the folder as a reference. If they say they would rewrite it, that is a normal answer.

What to learn next

• CLAUDE.md. A markdown file Claude Code reads at the start of each session. Project instructions live in ./CLAUDE.md or ./.claude/CLAUDE.md, and personal preferences in ~/.claude/CLAUDE.md. Run /memory to edit it. See the Markdown files guide.
• Slash commands. Type / to see what is available. The table below lists the ones used in this guide, as Anthropic describes them. The site's slash commands guide goes further.
• Hooks. User-defined shell commands that Claude Code runs at set points, such as after every file edit. Unlike a line in CLAUDE.md, a command hook runs every time. Run /hooks to see them. You can ask Claude to write one, but have an engineer read it before you rely on it.
• MCP (Model Context Protocol). An open standard for connecting AI tools to outside systems. You add a server with claude mcp add --transport http <name> <url> and check status with /mcp. Anthropic says to verify you trust each server, because servers that fetch outside content can expose you to prompt injection. Connecting a ticket system or a shared drive means connecting real data, so it is not a first-weekend task.
• Loops and wider tooling. Once you are comfortable, Loop Engineering for PMs and Marketers and the longer Loop Engineering guide cover letting a tool check and repeat its own work. The Claude Code ecosystem guide lists add-ons; treat every add-on as software you must trust.
• Learning material. Anthropic's Claude Academy lists a Claude Code 101 course of about 1.5 hours.

When it goes wrong: symptom, cause, fix

Frequently asked questions

Can a product manager with no coding experience use Claude Code?

Yes, to start. Anthropic's terminal guide for new users says you do not need to know how to code, and the desktop app removes the terminal. What you cannot skip is checking the output. A clear brief, numbered acceptance checks and a habit of running the result yourself do that job.

Do I need to use the terminal?

No. The desktop app has a Code tab that includes Claude Code, and Claude Code also runs in the browser at claude.ai/code and inside editors such as Visual Studio Code. The terminal offers the full command set, and Anthropic publishes a step-by-step terminal guide for first-time users.

Which plan do I need, and what does it cost?

Anthropic's documentation lists Pro, Max, Ultra, Team, Enterprise or a Claude Console account as ways to sign in, and says the free claude.ai plan does not include Claude Code. Prices and limits change, so check Anthropic's pricing page. Use /usage to see where your usage goes.

Is it safe to run on my work laptop?

It depends on your company's policy and on how you use it. Work in a new folder or a copy, use fake data, keep to Manual or Plan mode while you learn, and read every command before approving. Ask your security team first. This guide is not security or legal advice.

Will my prompts be used to train models?

That depends on your plan. Anthropic's data-usage page says consumer plans (Free, Pro, Max and Ultra) have a setting that controls whether your data may be used to improve future models, and that under commercial terms (Team, Enterprise and API) Anthropic does not train generative models on code or prompts sent to Claude Code unless the customer opts in. It also states that prompts and outputs travel over the network to Anthropic. Read the page for your plan and avoid pasting anything you should not share.

Can I share my prototype with a public link?

Not in this weekend's plan. Putting a prototype on the public internet raises security and data questions that deserve an engineer. Share a screen recording, or run it for people on your own screen. Anthropic's auto mode lists production deploys among the actions it blocks by default, a sign that deploying is not a casual step.

Can the prototype become the product?

Rarely, and never by default. It has not been reviewed, and you probably cannot explain most of it. That is the comprehension-debt problem. Treat it as a specification that happens to be clickable, and let engineers decide what to keep.

Does a prototype replace the PRD?

No. The PRD holds the problem, the evidence, the scope and the success measures. The prototype makes one part of it concrete. Use the brief and the checks to feed back into the PRD. For the wider practice, see AI-Native Product Development.

How is this different from asking an AI chat for code?

A chat gives you text that you copy somewhere. Claude Code works in your folder: it can create and edit files, run commands and test what it built, which is why the permission settings exist. That power is the reason to be careful.

Learn to build and evaluate AI products with us

To follow this series as each post publishes, join the Garage Labs community. If a weekend prototype leaves you wanting to build an AI product copilot, a RAG (Retrieval-Augmented Generation) knowledge assistant with citations, an autonomous research agent and an evaluation harness with live guidance, those are the builds in the Applied AI Practitioner Program, taught through live sessions and build labs. It expects 5+ years of experience, so read the programme page for the current schedule and details before you apply.

Found this useful? Share it with someone who needs it. Visit garagelabstech.com and follow Sumit Kumar Singh for more on LinkedIn.

Sources and further reading

Anthropic documentation pages read on 4 November 2026. Tool interfaces change; check the live pages.

• Anthropic, Claude Code overview
• Anthropic, Quickstart and Terminal guide for new users
• Anthropic, Advanced setup (system requirements, authentication) and Get started with the desktop app
• Anthropic, Choose a permission mode and Configure permissions
• Anthropic, Best practices, Common workflows and How Claude Code works
• Anthropic, How Claude remembers your project (CLAUDE.md) and Commands
• Anthropic, Checkpointing, Security and Data usage
• Anthropic, Claude Code and MCP, Automate actions with hooks and Manage costs effectively
• Anthropic, Supported regions and Claude Code 101 (Claude Academy)