I don't know if there's a way for product managers to not be obsolete, but we're going to try...
Claude Code can be your superpower (for a bit)
(not sponsored, but Anthropic hit me up)
Here are 10+ techniques that will change how you work with code/eng teams:
1/ Codebase Q&A is your new superpower
Stop asking engineers "where is the login feature implemented?"
Claude Code can:
• Identify where specific features live in the code
• Analyze Git history to understand how code evolved
• Summarize team contributions and recent shipments
• Pull context from GitHub issues and PRs
You get answers in minutes, not meeting requests.
2/ Use it as your planning thought partner
Before writing any requirements, tell Claude Code: "brainstorm ideas and outline a plan for implementing [feature]."
This validates your approach before engineering even sees it.
Pro tip: Ask for multiple options. Engineers appreciate when PMs come with thoughtful alternatives, not just demands.
3/ Prioritize analysis order in your instructions
Always tell Claude Code what to analyze first.
Example: "Analyze the user registration form before reviewing the UI mockup."
Understanding the form structure gives context for evaluating the design. This sequencing prevents misaligned outputs.
4/ Integrate your team's actual tools
Don't work in isolation. Connect Claude Code to:
• Your issue tracker (Linear, Jira)
• Observability tools (Sentry, DataDog)
• Team CLI tools
• Project documentation
This gives Claude Code the same context your engineers have.
5/ Create feedback loops for quality
Set up Claude Code to verify its own work:
• Run unit tests automatically
• Take screenshots of UI changes
• Use tools like Playwright for visual verification
This lets Claude Code iterate and improve outputs without constant human oversight.
6/ Focus on "leaf nodes" for autonomous work
Let Claude Code work on parts of the system that other components don't heavily depend on.
Think: individual API endpoints, isolated UI components, utility functions.
Keep human oversight on core architecture and critical user flows.
7/ Set up "reasonable heuristics" like managing an intern
Give Claude Code guiding principles, not just task lists:
• "Irreversibility rule" - avoid destructive actions without explicit confirmation
• "Budget" tool calls - limit how many API calls it makes per task
• "Graceful degradation" - always have a fallback when something fails
These heuristics prevent Claude Code from going off track in unpredictable ways.
8/ Manage context windows strategically
Claude Code has a 200,000 token limit. For long projects:
• Use "compaction" - summarize previous conversations to start fresh
• Enable Claude to write to external memory files
• Break complex features into smaller, context-manageable chunks
Don't let context overflow kill your momentum on multi-day projects.
9/ Create team-wide Claude contexts with claude.md files
Stop re-explaining your project setup every time.
Include in your claude.md:
• Architectural decisions and why they were made
• Style guides and coding standards
• Common commands and workflows
• Project-specific context and constraints
This ensures consistency across your entire team's Claude Code usage.
Go into individual sub-folders and run /init again to go deeper
10/ As Claude Code handles larger chunks of work (hours, soon days/weeks), think of yourself as "Claude's PM." You can finally be an asshole to your engineers, and they will still oblige (this is a joke btw)
Your job shifts from reviewing every line to:
• Defining clear success criteria
• Setting strategic direction
• Ensuring outputs align with user needs
• Managing technical debt accumulation
11/ Communicate limitations explicitly
Train Claude Code to tell you when it can't deliver:
• "This contact form is front-end only - it won't actually send emails"
• "I can't access your database to test this feature end-to-end"
• "This approach might work but could impact performance"
Limits curb false confidence.
12/ Anthropic just dropped a whole playlist on Claude Code, so check it out
Most PM learning focuses on frameworks and best practices.
But after 8 years in product, I've learned more from studying what successful PMs actually produce than from any course.
Here's an experiment worth trying (with important caveats) 🧵
The insight: Instead of asking PMs to explain their decisions, study the artifacts they create when making those decisions.
PRDs, roadmaps, customer research notes, stakeholder emails.
But here's what most advice gets wrong about this approach...
Caveat 1: Success in product has massive context dependencies.
A decision that worked brilliantly at a Series A startup might be terrible at a Fortune 500 company. Market timing, resources, team dynamics, and plain luck all matter more than we admit.
"Everyone can now vibe code features - CPO, customer success, data analysts."
PM's immediate reaction: "If everyone's building... what makes me irreplaceable?"
I watched this exact conversation unfold. The conclusion might surprise you: 🧵
The PM's fear is real:
• CPO has strategy vision AND can build
• CX has customer proximity AND can build
• Data analysts have insight depth AND can build
• Engineers have technical judgment AND can build
Where's the PM's unique value?
Standard advice: "Become an amplifier! Be the synthesizer! Orchestrate the chaos!"
But here's the brutal truth:
Engineers can orchestrate features.
AI can synthesize insights.
Anyone can "amplify" with the right tools.