Claude Code first week for product managers: a day by day ramp

Why a week, and why one artefact rather than a tour?

Because tool tours do not survive contact with a Tuesday. The failure mode for a product manager picking up an agentic tool is not that it is too hard; it is that the first week gets spent on impressive demos that have nothing to do with the work sitting in your inbox, and week two never happens. A ramp that attaches to real work by Friday survives, because by then something already depends on it.

The other reason is evaluation. You cannot judge whether an agent's output is good until you have compared one against a source you already knew the answer to. That comparison is the actual curriculum of week one, and it needs small, checkable tasks rather than a large impressive one.

Day 1: install, log in, and ask one question that changes nothing

Install Claude Code using the command for your platform from Anthropic's quickstart, then run claude --version and confirm it prints a version number followed by the words Claude Code. Start a session inside a real folder, log in through the browser prompt, and ask what this project does.

Stop there. The temptation on day one is to keep going because it is working, and the cost is that your first real evaluation happens when you are tired and invested. Twenty minutes, one read-only answer, done.

Day 2: write the CLAUDE.md file, after it has already been wrong once

By now you have seen the tool assume something about your project that is not true. That assumption is your first CLAUDE.md entry. Anthropic's guidance is to add to the file when Claude makes the same mistake twice, when a review catches something it should have known, or when you type the same correction you typed last session.

Keep it short. The recommendation is under 200 lines per file, because longer files consume context and reduce how consistently the instructions are followed, and the practical version of that for a product folder is ten lines: what the product is, who it is for, which document is canonical, which is stale, and the naming convention. Running /init gives you a starting draft to cut down rather than a blank page.

Day 3: one read-only task you already know the answer to

Pick something you could verify in two minutes: summarise last month's changes, list where a metric is defined, find every place a feature name appears. You are not looking for a useful output. You are calibrating, and the only way to calibrate is to ask a question whose answer you can check instantly.

This is the day most people skip and the day that decides everything afterwards. An agent that is right four times out of five looks identical to one that is right five times out of five until you have deliberately checked. Anthropic's best-practice guidance frames the general version of this as having the agent show evidence rather than assert success: the command it ran and what it returned, not a claim that the work is done.

Day 4: one small change, fully reviewed, with a constraint attached

Now make something change. Pick a task small enough that you can hold the whole thing in your head, and write the request in two halves: what you want, and what must not change. The second half is the part that separates a week-one PM from a week-four one.

Then read the entire diff, not the part you were watching. Builders Camp's Claude Code for Product Managers bootcamp builds its practical challenge on precisely this failure: a PM asks for a character counter, gets a working character counter plus an unrequested refactor of the submission handler, skims the diff because the counter is correct, and discovers the next day that every feedback submission has silently stopped saving. The challenge is rated intermediate and takes about 90 minutes, and the deliverable is a five-item personal checklist for reviewing agent-written changes.

Day 5: ship one artefact to a colleague

Something real leaves your machine. A release note built from the actual history, a spec updated against the code that exists, a support export grouped into themes with the rows cited. It does not have to be large and it does have to be sent, because sending it is what forces the last check you would otherwise skip.

Then write the second list, the one nobody tells you to write: the things you tried this week that were not worth it. Most PMs find at least two. Prioritisation calls that got faster inputs but no better answer. A document the agent summarised into something shorter and less useful than the original. That list is what keeps month two honest.

What should feel different by Friday, and what should not?

Three things should feel different:

• You write requests with an explicit out-of-scope clause, without being reminded.
• You read a whole diff or a whole output before reacting to the part you asked for.
• You clear a session when it drifts instead of arguing with it.

What should not feel different is your confidence about shipping unreviewed work. Anthropic's security documentation is direct that the tool only has the permissions you grant it and that you are responsible for reviewing proposed code and commands before approval. A first week that ends with you trusting the output more than you did on Monday, rather than checking it better, has gone wrong in a way that will show up later.

The honest case against running this week at all

Some product jobs have almost no file-shaped work in them. If your week is stakeholder alignment, hiring loops and three standing meetings, and the artefacts you produce are slides assembled live in a room, then a file-based agent sitting in a terminal has very little surface to attach to, and the five days above will feel like homework. That is a real answer, not a failure of will, and it is worth reaching on day three rather than month three.

The test is concrete. Count the deliverables you produced in the last two weeks that existed as a document, an export or a repository file at some point. If the number is under three, the ramp is premature and the better first move is a chat tool for drafting and synthesis, where the input can be pasted and nothing needs to live on disk. Come back when a recurring deliverable is genuinely file-shaped, because that is the condition the whole workflow depends on.

What week two looks like when week one worked

The jobs stop being one-offs and start being written down. The CLAUDE.md file gains the two corrections you kept retyping. A task you ran on Wednesday gets run again without rebuilding the prompt, and the output is consistent enough that someone else starts expecting it on a schedule. That is the point where the tool stops being a thing you are trying and starts being part of how the week runs.

Builders Camp's Claude Code for Product Managers bootcamp covers that structured version in 1 week, across 2 live sessions and 8 self-paced microlessons, taught by Andre Albuquerque, ending in a graded certification quiz and the diff-review challenge described above. The 7-day free trial starts on the bootcamp's first day and requires no credit card, which lines up with exactly the kind of week this guide describes.

See the Claude Code for Product Managers bootcamp

If the goal is building products rather than running PM workflows, the Vibe Coding Expert Track bundles this with prototyping and shipping, and Building with Claude Code goes deeper into skills, agents and automation pipelines. For the adjacent tool comparison, see how to build a prototype with Cursor, for the chat-based habits that carry over, ChatGPT for product managers, and for the term behind day four, vibe coding.