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.

PMs: When a customer says “I want CSV export,” and you just write it down, you’re wasting the interview.

Here’s how to flip lazy feature requests into goldmine insights.

It took me 5 years of painful interviews to learn this. You’ll get it in 1 minute. 1/ The proper response is to probe the underlying need:

"What would CSV export allow you to do?"
"How are you handling this today?"
"Talk me through the last time this came up"

I've added prompts to AI Prompts for Product Work to help PMs dig deeper: 👉 ($15) 🛍️prodmgmt.world/products/ai-pr…

Burnout isn’t a personal failure, it’s a systems failure.

Most PM orgs burn you out by draining your brain in 3 conflicting ways.

I’ll teach you in 2 minutes what took me 7 years to realize as a product leader: ↓ 1/ Your neural architecture processes three distinct types of work:

- Strategic synthesis (prefrontal cortex)
- Social navigation (anterior cingulate)
- Tactical coordination (dorsolateral prefrontal)

Each system depletes independently but recovers interdependently.

User personas are the astrology of product management.

You don’t need better personas.

You need a better way to make product decisions.

I’ll show you what actually works in 3 mins ↓ 1/ Every month, I watch teams debate fictional personas while ignoring actual user behavior:

"Jessica, 35, urban professional, tech-savvy..."

Meanwhile their real users are screaming about basic problems in support tickets.

Tech debt isn’t fatal.

Explaining it poorly is.

I’ll show you how to make execs care + fund the fix.

Took me years. You’ll learn it in 3 mins ↓ 1/ First, a hard truth: If you're constantly fighting for engineering resources, you're already playing defense.

Stakeholders don't distrust tech because they're stubborn.

They distrust it because no one has shown them evidence of returns in THEIR language.

4 years of flawless decks and data meant nothing.

every stakeholder still said "no."

but another PM with simple slides got everything approved.

that's when it clicked:

they're not judging your work. they're judging you.

learn in 4 minutes what took me 4 years. 🧵 1/ stakeholder meetings are job interviews disguised as business discussions.

the stated criteria: roi, feasibility, strategic alignment, data quality, resource requirements.

the actual criteria: do i trust this person, does this advance my goals, will this make me look good, is the timing right.

Technical PMs are over-complicating hypotheses.

Non-technical PMs are under-specifying them.

After reviewing (and failing) many product experiments, here's the framework that I think actually works: 1/ Stop copying scientific papers.
Start with this simple structure:

[Action] will cause [Outcome] to [Direction] for [Users] under [Conditions]

Example:
"Adding social proof will cause conversion to increase for new users on mobile"

Product management has no clear progression, endless responsibilities, constant judgment calls.

That impostor feeling isn't a sign of inadequacy.

It's a sign you need a different learning system.

A thread on rebuilding confidence through systematic competence 💫 Reality check for product leaders first:

When your PM seems stuck in analysis paralysis or seeking endless consensus, they're not being risk-averse.

They're missing the systematic approach to building judgment.

The hardest part about product discovery isn't talking to customers.

It's admitting you don't know what to build.

Everyone expects you to be the customer expert with perfect intuition about user needs.

This creates an impossible tension. Here's how to resolve it: 🍺 1/ Here's the paradox that breaks most PMs:

Your job title suggests you should know what customers want.
Your stakeholders expect you to have the answers.
Your roadmap implies you've figured it out.

But the entire purpose of discovery is admitting you haven't figured it out yet.

your product strategy fails because you're building on hunches.

let me show you how to fix this: 1/ every failed product i've seen shares this trait: the team jumped straight from problem to solution without generating systematic insights.

product management is taught tactically, not strategically.
you've been trained to execute, not investigate.

Bug management in product teams is broken.

Not because we track too few bugs.

But because we've created heavyweight processes that:
• Waste engineering time
• Kill team morale
• Provide false security

Here's how to fix it: 1/ First, a truth that will anger some and relieve others:

Most bugs in your backlog will never get fixed.

Not because you're bad at your job.

But because if they were truly important, they'd already be fixed.

Product Leaders: This isn't a quality issue. It's resource optimization.

I wasted 2 years as a technical PM over-engineering prioritization: RICE, scoring matrices, endless grids.

The truth is my engineering brain already had the answer.

If you're a technical PM stuck in framework hell, this thread will save you 2 years in 2 minutes. 🧵 1/ Your engineering background already trained you for this:

You estimate uptime probabilities.
You calculate failure rates.
You think about cascading risks.
You model system performance under load.

This IS expected value thinking. You just need to apply it to bugs and features.

Most PMs chasing "technical skills" think they need to learn code.

But what they’re really chasing is credibility, confidence, and career security.

The myth of the "technical PM" keeps you stuck.

I'll teach you in 2 minutes what took me 5 years to see:
🧵 1/16 When someone says they want to be "technical," they're really saying they want job security in a world where engineers make the rules.

They want to belong in technical conversations instead of feeling like an outsider.

They want respect from people who think non-technical means less valuable.

This has nothing to do with code.

2/16

7 Micro-Challenges To Improve Your PM Skills

Most PM advice requires massive time investments or career risks.

Here are some pragmatic challenges to try, especially when you're overwhelmed 💫 1. The 10-Minute Stakeholder Map

After every meeting, spend 10 minutes noting:
- One thing that energized them
- One thing that concerned them
- One question you want to explore

Build your relationship database gradually, without the overwhelm.

Everyone's obsessed with finding the "perfect" strategy framework.

I spent my first 2 years as a PM collecting frameworks like baseball cards.

The result? Beautiful strategy docs that nobody followed.

Here's what I learned about what strategy actually is (and it's not what you think): Most people think strategy means picking the right framework.

Playing to Win, Jobs to be Done, OKRs, North Star - there's always a new one.

But here's the problem: frameworks are teaching tools, not strategy tools.

If you master every framework but can't make tough choices, you don't have strategy.

Your engineering team isn't resistant to change.

They're resistant to poorly thought-out changes pushed by PMs who don't understand technical implications.

A systematic analysis of how to get genuine engineering buy-in, backed by 7 years of learning it the hard way: 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.