Stop doing these 'best practices' in as a Product Manager:

- Backlog grooming
- Writing JIRA tickets
- Leading stand-ups
- Playing scrum master

A thread on what to do instead (from someone who learned the hard way) 🎞️ 1/ Stop running the daily standup

"But who'll run it if I don't?"
Startup: Your tech lead/senior eng
BigCo: Team lead/EM

Why? Every minute you spend running process is a minute not spent on:

- Finding highest-impact problems
- Aligning stakeholders on vision
- Uncovering hidden assumptions

Leaders: Coach PMs to attend but not lead.

I spent 3 years working with an engineering team that openly despised product managers.

Every interaction felt like negotiating with someone who wanted me to fail.

Here's what that toxic dynamic taught me about when to fight and when to walk away:

1/17 The warning signs were there from day one:

- Requirements were never "detailed enough" but they wouldn't explain what they needed
- Status updates? "You're the PM, you should know"
- Questions? "Stop wasting our time"
- Meetings? Either I was micromanaging or not involved enough

2/17

a senior PM i worked with was stuck at her level for 4 years.

great execution. strong metrics. glowing reviews.

then i asked her one question that changed everything:

"what story are you telling yourself about who you are?"

the answer revealed why 80% of PMs plateau 🧵 1/ she said: "i'm a high agency PM who gets things done no matter what."

"and how's that working for you?"

"great! my team knows i'll always deliver."

"then why haven't you been promoted?"

silence.

Junior PMs watch scapegoating destroy their teams and think they're powerless to stop it.

Half true.

You can't fix your org's mimetic dynamics. But you control more than you think.

7 specific moves that work when you have no authority: ↓ 1. Control your language in written updates

When you write status updates or post-mortems, use "we decided X" not "Person Y did X."

Bad: "Engineering skipped tests to hit the deadline."

Good: "We chose speed over testing given the customer commitment."

Same information. Zero blame. The difference matters when leadership looks for someone to sacrifice.

You don't avoid the chaos. You filter it.

Most PMs drown in context from devs, design, stakeholders, and user feedback that changes every 4 hours.

Your brain can't hold this. Stop pretending.

The filtering system that actually works: 🧵 1/ Every junior PM thinks they need to process everything.

Track every Slack thread. Attend every meeting. Read every doc. Respond to every ping.

Reality: 90% of "urgent" context has a 4-hour half-life.

You need better filters, not less chaos.

Product sense is real.

But many PMs who claim to have it are using it as an excuse to avoid actual customer research.

I think I know what's the real deal: Real product sense comes from pattern recognition across thousands of user interactions, not from reading case studies or doing framework exercises.

The PM with 10 years of experience who says "I just know" actually means "I've seen this exact failure mode 47 times before."

Your first product strategy doc isn't about perfection.

It's about structured thinking + stakeholder alignment.

After helping a few of my fellow PMs craft their first strategy, here's the exact process that works 👇 [1/20] First, let's address the elephant: You're probably overwhelmed by fancy frameworks and "thought leadership" posts.

Put those aside. We're going to build this step-by-step, with real examples.

If you inherit a product with massive tech debt, then your first 30 days will define if your engineers stay or quit.

I've watched 5 engineering teams implode because their PMs made the same mistakes.

For 4 years, I had to fix a few such disasters.

Here's what actually works: 1/ First, breathe. If you're feeling overwhelmed, that's normal.

Technical debt isn't just a technical problem.
It's a trust problem.
It's a morale problem.
It's a business problem.

But there's a way through this.

If you run product at a small startup, you've probably got a messy Jira board, an unused roadmap tool, and 3 different planning docs.

And you're falling behind every week.

Here's the planning system that actually works when you're small:
⚡️ Most rookie mistake?

If you're a team of 1-3 PMs, you don't need:
- Elaborate roadmap tools
- Complex prioritization frameworks
- Feature scoring systems
- Multi-level initiative tracking

You need speed and clarity. Here's why:

First time I had to present product metrics, I bombed completely.

Execs asked why I chose them.
Engineers asked how we'd track them.

I had no real answers.

Here's how to build your metrics understanding from zero: While building , I discovered something crucial:

Product sense - whether for product discovery or metrics - comes from understanding basic patterns first.

Get started today:prodmgmt.world

Technical PMs often tell me they struggle with customer interviews.

"I feel like I'm just going through a checklist but not getting real insights."

After mentoring a few PMs and conducting ~ 500+ interviews myself, here's what actually works: First, let's address the elephant in the room:

Most interview templates or discussion guides fail because they're trying to script a human conversation.

Your engineering brain wants structure, but customers need space to tell their story.

The solution isn't another template. It's a systematic approach to conversation.

Let's dive in 👇🏼

Most PMs struggle with hostile stakeholders.

Common advice: "Be more strategic." "Manage up better."

If that worked, you'd already be doing it.

I spent 2 years getting steamrolled until I learned behavioral psychology.

1/8 Hostile stakeholders aren't angry about your product decisions.

They're angry because they feel unheard, disrespected, or afraid of losing control.

You're using logic to solve an emotional problem, which makes defensive people more defensive.

2/8

Your perfectly detailed spec is worth exactly $0 if nothing gets built.

Here's what senior PMs know about PRDs: 1/ Your PRD needs just 3 sections:
• Context (why & what)
• Usage scenarios (who & when)
• Milestones (how & when)

That's it. No 20-page specs. No solution architecture. No implementation details.

spent 4 years being the wrong kind of PM before i learned the cheat codes

watched hundreds struggle with the same mistakes

these 7 shortcuts will save you years of pain 🧵 cheat code #1: move revenue and they let you do whatever you want

i was the settings menu PM. zero leverage. zero impact. zero respect.

switched to revenue features. suddenly everyone returns my calls.

startup: work on pricing, checkout, activation
bigco: own the P&L features

stay close to the cash register

I've been consuming PM content for 8 years and 90% of it made me worse at my job.

Not because it was wrong.

Because I was looking for answers in everyone else's context instead of understanding my own.

Here's what actually helps: The PM content industrial complex has two modes:

Fortune cookie wisdom ("be curious!" "embrace ambiguity!")

Or tactical theater ("5 ways to write better PRDs!")

Neither helps when your eng lead is undermining you in meetings.

Your CEO forwards an angry customer email at 11 PM.

Next day, your roadmap is in chaos.

Sound familiar?

I watched good strategies fail for 2 years due to recency bias. Here's the system that fixed it: 1/ The Reality Check

First, let's address the elephant: You can't completely eliminate recency bias.

Your CEO will always care more about the customer they just talked to.

Your sales team will always push the deal they're about to close.

Your support team will always escalate the latest critical bug.

Don't fight this. Engineer for it.

"Documentation is killing me"

That was me 3 years ago, overwhelmed by 5 unfinished PRDs.

My ADHD brain struggled with the usual "sit down and write" method every PM book suggests.

Here's what finally worked after many failures: 1/ The Voice Note Method

Stop trying to write perfect prose immediately. Instead:

• Walk around and talk through your thoughts
• Record voice notes explaining the problem/solution
• Use Otter or Rev or many other similar apps to transcribe
• Clean up the transcription

Your brain works better in motion. Use it.

Your stakeholders aren't crazy.

After 6 years of product management, I've realized: every "difficult" stakeholder behavior has a hidden logic.

A thread on the psychology of product stakeholders 🧠 1/ Sales: The Future-Focused Hunters

What they see:
• Revenue targets looming
• Competitors taking deals
• Prospects making demands
• Commission at risk

What they feel:
• Urgency to close deals
• Fear of losing opportunities
• Frustration with product gaps
• Personal financial pressure

This is why they:
• Push for custom features
• Make promises to customers
• Escalate to leadership
• Sound desperate sometimes

Technical folks transitioning to product often struggle with strategic thinking.

Not because they can't think strategically.

But because they're stuck solving the wrong problems.

After mentoring a few bring PMs, here's what actually works for developing strategic thinking🧵 1/ First, let's destroy a myth:

"Strategic thinking means having a grand vision"

No. Strategic thinking starts with being comfortable in the problem space before jumping to solutions.

I made this mistake for 2 years as a PM, trying to come up with solutions before understanding problems.

My first year as a PM, I burned bridges by saying 'no' wrong:

- Lost eng team trust
- Damaged stakeholder relationships
- Got labeled as 'not a team player'

Until I discovered this counterintuitive approach to saying no (that actually builds stronger relationships)

🧵 1/ The conventional wisdom is broken:
- "Just say no firmly"
- "Stand your ground"
- "Protect the roadmap"

These create adversaries, not allies.

The hard truth: Your 'no' is probably making you look weak, not strong.

You left engineering because you were tired of:

- PMs who don't understand system dependencies
- "Product people" who can't think in flows
- Leaders who demand random features
- Roadmaps built on hope

But what if product management was actually about systems?

"Thinking in Systems" blew my mind: 1/ Most technical people are trained to see the world as a series of cause-and-effect relationships:

- Input → Process → Output
- Problem → Solution
- Bug → Fix

But products are systems, with:

- Multiple feedback loops
- Delays
- Unintended consequences