After studying high-performing PMs for years, I noticed something strange:

The most impactful product managers often do LESS than their peers.

They write shorter docs. Hold fewer meetings. Create simpler processes.

They've mastered making impact look effortless.

Here's how: I spent my first 3 years as a PM writing 30-page PRDs no one read and creating complex processes no one followed.

I thought "good product work = hard product work."

But what if the opposite is true? What if making it harder actually reduces your impact?

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

Roadmaps 101: Not a schedule. Not a backlog. A communication tool.

Here’s how to get it right: 1. Why You Need a Roadmap

If you don't have a roadmap, three bad things happen. Your team builds random features. Your stakeholders constantly ask when things will be ready. Your customers don't understand what's coming next.

If you have a roadmap, everyone knows what's important and when to expect it.

Most PMs bomb this interview question:

“Tell me about a time you influenced without authority.”

It’s not about persuasion.

Here’s what they’re really testing: First, understand what kills most answers.

Candidates tell stories about convincing people. They talk about charisma. They focus on winning arguments.

But that's not influence without authority. That's just being loud.

If you tell a story about winning a debate, then you already failed.

Everyone asks, "How do I break into PM?" but nobody asks, "What would I actually DO as a PM?"

Here's the truth every aspiring, junior or jaded product manager needs to hear: 1/ Most of you would hate this job. Let me show you what product managers really do all day.

Product managers often end up as professional cat herders who write documents that nobody reads.

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

It's 2 AM and you're googling "how to use ChatGPT for product requirements without getting fired"

Let me save you the panic attack.

Here's the truth nobody's telling you about AI and product work: 1/ Everyone is already using it.

That senior PM who produces flawless PRDs in 2 hours? AI.
The PM who suddenly writes eloquent user stories? AI.
Your manager who "just has a gift" for structuring requirements? Also AI.

You're not cheating. You're catching up.

I spent 2 years collecting every product framework I could find.

But frameworks alone nearly killed my product career.

Here's the thinking process that actually works for new product initiatives (after many failed attempts):

The Anti-Framework Framework™️ 🔽 First, a hard truth:

Most PMs jump straight to solutions or frameworks because it feels productive.

But starting with frameworks is like trying to navigate using someone else's map.

You need a compass first.

PMs think promotion is about past wins.

It’s not. It’s a bet on your future impact.

Here's the promotion framework that actually works: 1. The Promotion Paradox Every PM Faces
You're stuck between two impossible demands:

- Be indispensable (so they value you)
- Be replaceable (so they can promote you)

As a Product Manager, ditch these so-called 'best practices':

- Tinkering with the backlog
- Crafting JIRA cards
- Steering stand-up meetings
- Acting like the scrum master

Here's what to embrace instead, from someone who's been through the trenches. 🧵 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.

How to avoid product management theater - my notes from the Marty Cagan episode 🧵
1️⃣ The brutal truth Marty shared:

You're not a product manager.
You're a backlog administrator wearing a $150k costume.

Your engineers don't disrespect you.
They disrespect a role that shouldn't exist.

(This hit me like a truck)

Brilliant PMs often wait for permission instead of claiming their product authority. After 8 years, here's how I learned to stop waiting and start owning decisions. I'll teach you in 2 minutes what took me years to figure out: 1/ The hard truth: No one will ever hand you a "product authority license."

Your engineering lead won't.
Your CEO won't.
Your users won't.

Authority in product management is earned through consistent, confident decision-making.

90 days to turn your VP from blocker to sponsor.

7 VPs, 8 yrs... I’ll teach you in 2 min what took me a long time 🧵 1/ First, accept this reality:

Your VP has 99 problems, and your product is just one of them.

They're dealing with:
- Board pressure
- Peer conflicts
- Resource constraints
- Strategic pivots
- Team scaling

Understanding this context changes everything.

Engineers resist half-baked asks, not change.

It took me 7 yrs to earn real buy-in.

Learn how in 2 mins: 1/ First, a hard truth:
Technical debt isn't just "engineering problems."

It's the accumulated cost of business decisions prioritizing speed over sustainability.

Acknowledging this reality is step one to building trust.

PMs: Your feature list isn't the problem. It's the starting point of real strategy.

I’ll teach you in 3 mins what took me 7 years to learn. 🧠 1/ That feature list you're hiding? Pull it out.

Those detailed requirements you're embarrassed about? They're not the problem.

The problem is the gap between where you are and where "thought leaders" say you should be.

PMs: stop chasing one metric.

Do this instead ↓ 1/ The common advice is dangerous:

"Pick ONE metric"
"Make it simple"
"Get everyone aligned"

This creates tunnel vision and drives wrong behaviors.

Man, product managers are always supposed to just magically know what users want, and half the time, they don't even get the damn resources they need. It's a bit of a mess, honestly.

I spent 6 years learning how to run discovery solo.

You’ll learn it in 60 seconds. 1/ First, let's address the elephant: Yes, having dedicated researchers would be ideal.

But I've led product at both startups and large corps, and here's the truth:

Some of my best insights came from scrappy research when I had zero budget.

AI won’t replace PMs. But bad judgment will.

How to stay irreplaceable, explained in ~ 2 minutes (with tools to help, scroll to the end) 🧵 1/ AI is turning the PM role from "decision maker" to "decision architect."

You're no longer paid to have all the answers.

You're paid to ask the right questions and execute fast.

(In fact, it's always been like that.)

"Why is this our priority right now?"
- Your CEO, in front of the entire leadership team

I built a system to never fear that question again.

For PMs who want to command the room, not just survive it 📚 1/ The moment they challenge your priorities, three things happen:

- Your heart rate spikes
- Your mind goes blank
- Your authority crumbles

But it's not about confidence.
It's about preparation.

Your product decisions take weeks.

A poker player would make them in minutes.

Not because they're reckless.

Because they have better tools for thinking fast under pressure.

Here’s how you can harvest these insights too: 1. Stop using good outcomes to validate your process.

A successful feature ≠ good decision
Failed experiment ≠ bad decision

Track your decisions BEFORE knowing outcomes. Compare your expected probability of success vs actual.

This exposes your true hit rate.

Engineers-turned-PMs keep making the same fatal mistake in stakeholder meetings:

They assume everyone understands their reasoning.

After mentoring a few technical PMs, I've noticed a pattern that's killing their credibility 🧵 1/ Most engineers approach stakeholder communication like they're talking to AI:

Dump all the information → Let someone else parse through it → Hope they reach the right conclusion

But stakeholders aren't ChatGPT. They need the conclusion first, not last.