How to Use Claude Code When You Don't Write Code: A PM's First Week

I keep meeting product managers who think Claude Code is off-limits to them because they don't write code. It isn't. The skill that makes Claude Code useful is the same skill a PM already has with engineers: delegate the work, verify the output, ask better questions when something looks off.

This guide is how to use Claude Code without touching a single line of code yourself, structured as a realistic first week. Follow it in order and by day five or six you'll be running real discovery-to-delivery work from inside your own product's codebase.

A quick note on expectations: Productboard's 2026 product management survey found that 100% of surveyed product teams now use AI tools, and 94% use them daily or often. But most guidance on how to use Claude Code is written for engineers, full of terminal jargon and flags that assume you already know what a pull request is. This is the path for everyone else.

As Boris Cherny, Head of Claude Code at Anthropic, put it on Lenny's Podcast: "I think by the end of the year, everyone's gonna be a product manager, and everyone codes." That shift is exactly what this guide is built for: giving you the muscle to work inside a real codebase without ever needing to write the code yourself.

Step 1: Get Yourself Inside a Real Codebase

You cannot learn Claude Code from a blank folder. You need an actual application to point it at, because the entire value of the tool is that it reads and reasons over real context, not toy examples.

The ideal setup: ask your engineering team to give you local access to your own product's codebase. You don't need write permissions to the main branch, and you don't need full-stack access. Even a frontend-only checkout is enough to start.

If that's not available yet, clone an open-source app instead. Excalidraw is a good pick: it's a real, actively maintained product with a clean structure, not a tutorial repo built to be easy.

Either way, the goal of step 1 is simply positioning: have a folder open in Claude Code that represents a genuine, non-trivial product.

Step 2: Interrogate the Codebase to Learn the Fundamentals

Before you touch anything, use the codebase as your teacher. Open Claude Code inside the folder and start asking it questions about itself: what does this app do, how is it structured, what are the main user flows.

This is also where you learn the tool's own fundamentals, because you'll naturally need them to have a real conversation with the codebase:

• The different Claude models available, and what each is suited for
• How to switch models mid-session depending on the task
• How to pick the right effort or thinking level for a question (a quick "what does this file do" doesn't need the same depth as "why is this architecture built this way")

You're not writing anything yet. You're building the muscle of asking good questions and reading the answers critically, which is the exact same instinct you already use in a spec review with an engineer.

Step 3: Run It Locally and Make Small Changes

Now get the app running on your machine. Ask Claude Code to walk you through starting the local server, and let it handle the setup.

Once it's running, make small, low-stakes changes: reword a button label, tweak a spacing value, adjust a piece of copy. The changes themselves are not the point. The point is learning two things that everything after this step depends on:

1. Context-window management. What Claude Code is currently "looking at," and how to point it at exactly the file you mean instead of letting it guess.
2. Interacting with local files. How edits actually land on disk, how to review a diff before accepting it, how to undo something that went wrong.

By the end of step 3, you should be comfortable making a change, seeing it reflected in the running app, and understanding why it worked.

Step 4: Connect MCP Servers and Start Real Work

This is where Claude Code stops being a learning exercise and starts being a work tool. Connect MCP servers for the tools you already use: Lovable, Jira, Linear, Notion.

With those connected, you can run your actual discovery-to-delivery tasks from inside the app's context instead of switching between five disconnected tools. Claude Code can read a ticket in Jira, check it against what the code actually does, and flag the mismatch before it becomes a standup surprise.

This step is also where the developer-oriented content most people find when they search how to use Claude Code stops applying to you. Nobody writes the MCP setup guide for a PM's actual stack. That's the gap this article exists to close.

Step 5: Two Flagship Examples to Anchor the Habit

Two concrete workflows are worth building into muscle memory in your first week, because they show what "genuinely non-technical" delegation looks like in practice.

Example A: Turn a working prototype into user stories. Build a small prototype locally (from step 3's changes, or something slightly bigger), then ask Claude Code to write user stories directly from what that prototype actually does, not from a spec written in the abstract. Store the output in Notion, or have it break the stories straight into Linear issues. The stories come out grounded in real behavior instead of guesswork.

Example B: Build a Lovable prototype from inside your codebase's context. Instead of starting a new Lovable project from a blank prompt, drive it from Claude Code using your existing app's codebase as context. The prototype inherits your actual design patterns, data shapes, and conventions, so it looks and behaves like it belongs to your product instead of a generic demo.

Both examples follow the same principle: you are not writing code, you are directing a capable assistant using the same judgment you'd use directing a developer, then verifying what comes back.

Step 6: Automate What You Keep Repeating

By the end of the week, you'll notice yourself copy-pasting the same prompts over and over: the same instructions for turning a prototype into stories, the same checklist for reviewing a spec.

That's your signal to automate. Extract those repeated prompts into:

• Subagents: specialized workers with their own instructions and context, for a task you delegate often
• Custom commands: a saved, reusable prompt you can trigger with a short slash command
• Skills: bundled instructions plus reference material Claude Code loads automatically when relevant

The real leverage comes from combining custom commands with subagents: a command that kicks off a subagent to do the heavy lifting while you stay in your main conversation. This is the same instinct as writing a good runbook for a new hire, except the "hire" runs the same way every single time.

What "Good" Looks Like After One Week

If you get through all six steps in a week, that's already a strong outcome. Most people who search how to use Claude Code assume the ramp is measured in months and gated behind a computer science degree. It isn't.

The recurring theme across every step: you never needed to read code. You needed to delegate clearly and verify carefully, the exact skill you already use every day with your engineering team. Claude Code just gives you a direct line into the codebase instead of relying entirely on someone else to translate it for you.