--- title: "Your First Week With Claude Code as a PM" description: "A five day Claude Code ramp for product managers, ending with one real artefact shipped: install, context file, first read only task, first review, first fix." canonical_url: "https://builderscamp.com/guides/tools/claude-code-first-week-for-product-managers" date_published: "2026-09-18" date_modified: "2026-09-18" author: "Andre Albuquerque, Guilherme Salgueiro" publisher: "Builders Camp" guide_class: "tools" --- # Claude Code first week for product managers: a day by day ramp **TL;DR:** Five days, 30 to 45 minutes each, ending with one artefact a colleague actually read. The ramp works because each day adds exactly one new capability: install on day one, a context file on day two, a read only task on day three, a reviewed change on day four, and a real deliverable on day five. ## 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](https://builderscamp.com/bootcamps/claude-code-for-product-managers?utm_source=guide&utm_medium=organic&utm_campaign=claude-code-first-week-for-product-managers) 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](https://builderscamp.com/guides/tools/build-a-prototype-with-cursor), for the chat-based habits that carry over, [ChatGPT for product managers](https://builderscamp.com/guides/tools/chatgpt-for-product-managers), and for the term behind day four, [vibe coding](https://builderscamp.com/guides/glossary/vibe-coding). ## Frequently asked questions ### How much time does the first week actually take? Around 30 to 45 minutes a day for five days, with the first day being the longest because of the install. That is deliberately smaller than a training course, because the point is to attach the tool to work you were already doing this week rather than to carve out a project for it. ### What should I have at the end of day five? One artefact that went to a colleague, a CLAUDE.md file under 200 lines, and a short list of the tasks you tried that were not worth it. The negative list matters as much as the artefact, because it is what stops you from spending month two forcing the tool onto work it is bad at. ### What if I do not have access to a code repository? Run the whole week against a folder of product documents. Specs, research notes, exports and meeting transcripts are files, and Claude Code reads and writes files. Days one to four work unchanged, and day five becomes a document you improve rather than a code change you review. ### Should I start with a big task to see what the tool can do? No. A large first task means your first evaluation is a multi-file change in an environment you have used for ten minutes, which teaches you nothing except whether to trust it, and you have no basis for that judgement yet. Start with something you could have done yourself in twenty minutes. ### When should I write the CLAUDE.md file? Day two, after you have watched the tool make one wrong assumption. Writing it on day one means guessing at what needs saying. Anthropic frames this well: add to CLAUDE.md when you type the same correction you typed last session, and keep the file under 200 lines because longer files consume context and get followed less consistently. ### How do I stop a session going badly? Clear it. Anthropic's best-practice guidance treats the context window as the most important resource to manage, noting that performance degrades as it fills, so an hour-old session that has stopped following your instructions is usually a context problem rather than a prompting one. ### Is one week enough to decide whether this is for me? It is enough to decide whether it fits your current work. It is not enough to judge the ceiling, because most of the value shows up when the instructions are written down and the same jobs run weekly, which is a month-two effect rather than a week-one one. ## Sources - [Anthropic: Claude Code quickstart](https://docs.claude.com/en/docs/claude-code/quickstart) - [Anthropic: How Claude remembers your project](https://docs.claude.com/en/docs/claude-code/memory) - [Anthropic: Best practices for Claude Code](https://docs.claude.com/en/docs/claude-code/best-practices) - [Anthropic: Claude Code security](https://docs.claude.com/en/docs/claude-code/security) ## How this guide was made Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.