George from 🕹prodmgmt.world Profile picture
Aug 3 13 tweets 3 min read Read on X
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


Also hit up @iannuttall and his youtube - he's the bestyoutube.com/playlist?list=…

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with George from 🕹prodmgmt.world

George from 🕹prodmgmt.world Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @nurijanian

Aug 2
"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.
Read 11 tweets
Jul 30
You've got this brilliant feature idea.

You've done the research, talked to users, even built a prototype.

But when you pitch it to the team, you get:

- "We don't have time"
- "What about technical debt?"
- "How does this fit our roadmap?"

Here's what I learned after 50+ feature pitches that failed:
The biggest mistake I see PMs make:

They think "buy-in" means convincing people their idea is good.

Wrong.

You're not selling a feature. You're selling a story.

And the story isn't about your solution, it's about a problem everyone already agrees exists.
Think of it like chess.

You can't just move your queen and expect to win.

Every move affects the entire board. Every stakeholder has their own pieces to protect.

Engineering wants to maintain code quality.
Design wants UX consistency.
Business wants predictable delivery.

Your job: Show how your move helps everyone win.
Read 13 tweets
Jul 29
Your technical skills got you the PM role.

But your stakeholder skills will make or break you.

I lost multiple battles as a PM by being "right" but ineffective.

Here's what I’d do differently now:
1/ First, understand why smart people push back against good data:

• They have context you don't
• They're optimizing for different goals
• They see risks you haven't considered
• They have pressure from their stakeholders
• Past experiences are coloring their judgment
2/ The immediate urge is to:

- Gather more data
- Build stronger arguments
- Rally support

Stop.

Your goal isn't to win the argument.
It's to make the best decision for the product AND maintain relationships.
Read 15 tweets
Jul 29
Your engineering background is a superpower for writing PRDs.

But only if you know how to translate technical depth into business impact.

After reviewing probably about ~ 100 technical PRDs last year, here's what separates great ones from the rest 🧠 Image
1/ First, a hard truth:

Your technical expertise can actually work against you when writing PRDs for non-technical stakeholders.

The more you know, the harder it becomes to explain simply.

This is why senior engineers often struggle more than juniors when becoming PMs.
2/ The root cause isn't your technical knowledge.

It's approaching PRDs like technical specifications.

Engineering docs optimize for completeness.
Business docs optimize for decisions.

Different tools for different jobs.
Read 22 tweets
Jul 28
Most PMs burn out... Not from overwork, but misalignment.

They thought they'd build great products.
Instead: endless stakeholder alignment and decks.

After 100+ PM interviews and 200+ JD analyses, I decoded the hidden red flags.

I'll teach you in 5 minutes what took me years:
"Strategic thinking" isn't what you think it is

Most PMs assume strategic work means:
• Vision creation
• Market analysis
• Product direction
But in 70% of companies, "strategic" work actually means:

• Creating alignment decks
• Navigating organizational politics
• Endless stakeholder meetings
• Minimal building, maximum presenting

Test: Ask "What percentage of strategic work involves creating vs. communicating?"
Read 13 tweets
Jul 28
Product Management Maxims: Hard-earned wisdom for the daily work

A thread of practical rules that will save you years of painful lessons. ⚡
1. If you want good requirements, talk to five customers. If you want great requirements, watch five customers struggle with your product.

People lie about what they need. They never lie about what frustrates them.
2. If your product meetings are full of debate, you lack data. If they're silent, you lack trust.

Good teams argue about interpretations, not facts. Silent teams hide disagreement.
Read 17 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(