George from 🕹prodmgmt.world Profile picture
Aug 4 12 tweets 3 min read Read on X
PMs: 60-hour weeks ≠ impact.

I wasted 2 years on work that looked productive but stalled my career. Elite PMs do the opposite.

Avoid these 6 fake productivity traps. Took me 2 years to spot, you’ll get them in 2 mins. 🧵 Image
1/ Writing detailed PRDs that nobody reads

I spent weeks crafting 20-page documents with perfect formatting.

Reality: Engineers skipped to the acceptance criteria. Stakeholders never opened them.

What to do instead: Start with a 1-page problem statement. Add details only when someone asks specific questions.
2/ Attending status update meetings

I thought being in every meeting made me seem essential.

Reality: Most meetings are information theater. You're not contributing, just consuming.

What to do instead: Ask "Is this for decision-making or just updates?" If updates, request async summaries instead.
3/ Over-documenting everything "for future reference"

I documented every decision, every conversation, every brainstorm.

Reality: Nobody ever referenced 90% of it. I was creating artifacts for an imaginary future team.

What to do instead: Document only what impacts current decisions. Everything else is procrastination disguised as diligence.
4/ Responding to every Slack message immediately

I thought fast responses showed dedication.

Reality: Constant context switching destroyed my ability to think strategically.

What to do instead: Check Slack 3x daily. Set clear expectations about response times. Use "office hours" for complex discussions.
5/ Creating perfect roadmaps that change weekly

I spent days color-coding timelines and dependency diagrams.

Reality: The roadmap was outdated before I finished it. Stakeholders cared about outcomes, not Gantt charts.

What to do instead: Create theme-based roadmaps focused on problems to solve, not features to ship.
6/ Doing competitive analysis without clear purpose

I researched every competitor feature "to stay informed."

Reality: Random competitive research is just procrastination with extra steps.

What to do instead: Only research competitors when you have a specific decision to make. Define the question before you start looking.
"But wait - these activities are PM best practices!"

I hear you. I felt the same way.

Here's what I learned: There's a difference between doing PM work and being a productive PM.
New PMs think more documentation = more value.
Experienced PMs know that clarity = value.

The hardest part isn't learning these principles.

It's having the confidence to say no to "urgent" requests that aren't actually important.

It's trusting that strategic thinking matters more than being visibly busy.

It's accepting that your worth isn't measured by hours worked.
I've collected systematic approaches to these productivity challenges, including frameworks for prioritization and stakeholder management.

You'll find them in
($89)prodmgmt.world/products/produ…
For specific prompts that help with documentation and analysis tasks, I've been testing out "AI Prompts for Product Work" - it has some clever shortcuts for these exact problems.

($15)prodmgmt.world/products/ai-pr…
The transformation isn't immediate.

But eliminate these 6 activities and you'll reclaim 10+ hours per week.

Use that time for customer conversations, strategic thinking, and actually solving problems.

That's where careers are built.

What's one activity you're going to eliminate this week?

• • •

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 4
William Zinsser, author of "On Writing Well," would roast 90% of product management writing.

Here's what he'd tell you: 🧵 Image
HARSH TRUTH #1: Your muddled writing reveals muddled thinking

❌ "We need to optimize our user acquisition funnel leveraging synergistic touchpoints"

✅ "We're losing 60% of users at signup. Here's why and how we'll fix it."

The first sounds smart. The second shows you actually understand the problem.
HARSH TRUTH #2: Your jargon is pushing people away

Zinsser calls jargon "the disease of American writing."

That "communication facilitation skills development intervention"?

Just call it "a workshop to help teams communicate better."

Your CEO will thank you. So will everyone else.
Read 12 tweets
Aug 3
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.
Read 13 tweets
Aug 3
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.
Read 18 tweets
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
Aug 1
This guy breaks down how PMs can win with AI.

Here are the insights on navigating the new reality for product managers that I picked up from this niche talk 🧵 Image
"What do I build and why will it win?"

For years, we buried this core question under layers of agile ceremonies and project management processes.

Now the environment strips away all that noise.

Fast-moving incumbents. New horizontal platforms eating entire use cases. Foundational tech shifts happening monthly, not yearly.
His examples hit hard: Chegg and Stack Overflow collapsed in months.

Meanwhile, ChatGPT and Anthropic consumed use cases that took entire companies decades to build.

The PM who survives this chaos does one thing differently.
Read 12 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

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!

:(