PM Standard Work Guide
For every PM on our product team, whether or not you know how to code. This guide has one job: take you from 'afraid to try, don't know where to start' to 'can't live without it.'
First things first: relax and dive in
If your gut reaction to Claude Code right now is "I've heard it's powerful, but I have no idea where to start" — that's completely normal. Let's bust three myths first.
Myth 1: I don't know code, so I can't use it
Wrong. In fact, not knowing code is actually an advantage. You're not weighed down by "how hard is this to implement" — you just focus on articulating your idea clearly. And articulating ideas clearly? That's exactly what product managers are trained to do. The future is "Speak it. AI builds it": say the word, and AI makes it real.
Myth 2: I'll break something or cause a disaster
Wrong. In your own project directory, you can experiment freely. The worst that can happen is it does something wrong, and you say "that's not right, try again."
Myth 3: It's a tool I need to learn to "operate"
Reframe it: it's not a tool — it's your direct report. An all-around intern who never gets tired, is always on call, and can do a little bit of everything. You just need to give clear instructions, the way you would with a person.
Step one: learn to talk to it in 5 minutes
No commands to learn. Go into your project folder and just talk. Three core phrases cover everything.
Start with the simplest thing
Build me a webpage with the title "Hello" and a light blue background, then start a local server so I can see it in the browser.
When the page appears in the browser — congratulations, you're already using it.
Three core phrases
- "Help me build..." — assign the task
- "This isn't right, it should be..." — give feedback
- "Before you start, ask me a few questions" — let it help you think it through
Core beliefs: four premises
| Premise | What it means |
|---|---|
| You don't need to code — you need to describe | It's an idea-to-product translator. The clearer you are, the better it delivers. |
| Anyone can use it — at any depth | No prerequisites, only proficiency levels. |
| Prototype = something that actually runs | Clickable, interactive, testable by real users — not a static image. |
| The whole team shifts together | This becomes the team's new default — not a personal experiment. |
Five-stage workflow (detailed breakdown)
PM work broken into five stages. Each stage: goal, how to talk to it, definition of done, common beginner pitfalls.
Discover
Goal: understand what users want, what competitors are doing, where the market is heading.
/competitor-watch analyze [competitor URL], focus on [pricing/AI features], output a comparison report
Can explain the user's biggest pain in three sentences; know how competitors solve it and where your differentiation lies.
Asking too broadly. Fix: give a specific subject + specific focus + specific output format.
Define
Goal: turn a fuzzy idea into a clear requirement (PRD) anyone can act on.
/office-hours I want to build [idea], don't give me solutions yet — ask me 5 key questions first → /prd-generator write a complete PRD
Clear success metrics; edge cases listed; someone who wasn't in the room can understand it.
Jumping straight to "write a PRD" — it fills in details by guessing. Fix: always make it ask you questions first.
Design
Goal: before building, see roughly "what it might look like" and lock a direction.
/design-shotgun make 3 style options for the login page: A minimal B corporate C playful — side-by-side comparison page
A direction is chosen; key pages have a clear shape in your head.
Seeking perfection right away, getting stuck in revision loops. Fix: ask for 3 rough options first, then pick from what you see.
Develop Prototype
Goal: turn the design into a prototype that's clickable, interactive, and testable by real users. Core mantra: small steps, fast cycles.
/design-html build it into a prototype → then add one feature at a time: "change chart to brand blue" "add export CSV button"… iterate through conversation
Actually running in the browser; main flow clickable without errors; fake data good enough for a demo.
Throwing 20 requirements at it at once. Fix: one at a time! Don't obsess over prototype code quality.
Validate
Goal: let real users try it and make decisions with data, not gut feeling.
/qa test this prototype — click through everything clickable, find errors, dead ends, and anything unexpected, then make a list
Main flow runs without obvious bugs; real users have tried it; can answer with evidence whether it's worth continuing.
Clicking through it yourself for two minutes and calling it done. Fix: always give it to someone else — stay silent and watch where they get stuck.
Capability growth path
No need to level up all at once — grow at this pace.
The floor: a safety net, not a cage
These 5 guardrails are exactly why you can experiment freely and use it boldly above the floor.
- Don't feed it real sensitive data — use fake or anonymized data for prototypes.
- Don't write secrets into code — get test-only credentials from the team.
- You confirm irreversible actions yourself — publishing, deleting, spending money: you press the final button.
- Don't touch production systems — prototypes only run locally or in test environments.
- When in doubt, ask — compliance, payments, privacy, tech stack choices: check with team lead first.
Three-week growth roadmap
| Week | Goal | What to do |
|---|---|---|
| Week 1 | Break the fear | Set up environment, run your first webpage, practice 3 conversations per day. |
| Week 2 | One real run-through | Take a real small requirement through the full "write PRD → build prototype" loop. |
| Week 3 | Independent full loop | Complete the full "idea → prototype → colleague tries it → improve" cycle on your own. |
Appendix
A · Four prompting principles
| Principle | ❌ Like this | ✅ Like this |
|---|---|---|
| Be specific | Make a good-looking page | Login page, centered card, email + password, blue button #3B82F6 |
| Give context | Add an export feature | Add an export button in the top-right of the dashboard, download current filtered results as CSV |
| Go step by step | 15 requirements at once | One at a time — see the result before giving the next |
| Give a reference | Adjust the colors | Primary color #3B82F6, reference Stripe's color palette |
B · Quick skill reference
Type / in any conversation to see the full list. Most-used by PMs: /office-hours to sharpen ideas · /prd-generator for PRDs · /competitor-watch for competitive research · /design-shotgun for multi-option design · /design-html for prototypes · /qa for testing · /make-pdf to convert to PDF.
C · Beginner FAQ
Q: It did it wrong, and I don't know code — how do I fix it?
Just say "this isn't right, what I want is..." It'll fix it on its own.
Q: Can prototypes be used as a real product for users?
They can handle limited trials, but can't go to production. Production requires engineering to rebuild it at production quality.
Q: How long does a prototype take?
Simple ones take a few hours; complex ones take a day. If nothing's out after 1 day, the requirement is too big — break it smaller.
Q: I'm afraid of wasting time on trial and error.
Trial and error is the core value of this way of working. The faster you fail, the faster you find the right direction.
