Engineering excellence killed your product strategy.

A technical background in product is both a blessing and a curse.

Here's what coaching technical PMs has taught me about making this transition work: 1/ Engineering minds optimize for:

- Technical elegance
- System efficiency
- Perfect architecture
- Clean code

Product minds optimize for:
- Market fit
- Business outcomes
- User value
- Speed to learning

The truth about becoming a Platform PM without an engineering background:

Most advice tells you to "learn to code" or "master system design."

I've found a completely different path that actually works.

A thread on what really matters 👇 1/ First, let's bust the biggest myth:

You DON'T need to be an expert in every technical area.

What you DO need:
• Deep expertise in 1-2 specific domains
• Understanding of technical limitations
• Ability to translate between business and tech

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

User personas are the astrology of product management.

Teams spend months crafting detailed profiles just to feel like they understand their users.

But like horoscopes, they give the illusion of insight without the substance of real understanding.

Here's the hard truth 🔭 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.

Your OKRs keep failing because they're masquerading as strategy.

It's not about writing better OKRs - it's about having a strategy that makes OKRs worth writing.

After mentoring dozens of PMs through this exact challenge, here's the framework that actually works: 1/ First, let's understand what strategy isn't:

• A collection of targets
• A list of initiatives
• A set of KPIs

Strategy is a coherent set of choices about where to play and how to win.

Everything else - including OKRs - flows from these choices.

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.

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

They think logic will save them.

After mentoring a few folks, I've noticed a pattern no one talks about: 2/
If you bend too much or too lite, you lose influence.

Here's the painful truth about stakeholder resistance:

Your stakeholders aren't fighting your logic.

They're protecting themselves from threats you don't even see.

5 years ago, I was a PM with zero confidence.

Someone recommended "The Six Pillars of Self-Esteem" by Nathaniel Branden.

It changed everything about how I approach life.

Here's what actually works for building genuine product confidence ↓ 1/ Most PMs try to build confidence through Faking it

The hard truth:

All that, even if you get some validation, goes into an endless pit with no bottom.

Real confidence comes from developing self efficacy - that feeling that “whatever happens, I will figure it out.”

The "start with the problem" crowd is going to hate this.

But sometimes executives hand you the solution first.

And if you try to fight it, you've already lost.

Here’s how to win as a PM: 1/ typical advice isn't helping:
"resist quick fixes!"
"do thorough research!"
"focus on the problem first!"

real situation:
CEO: "competitors have mobile apps by Q3."
VP: "enterprise clients want mobile."
sales: "we're losing deals without it."

what's next?

Most people read strategy advice backwards.

They look at the final, polished rules and try to copy them.

But clarity comes from a deeper process.

Let's see if I can show you how to reverse engineer how smart strategists actually develop this clarity 🔍 First principle: Clear strategy emerges from painful experience.

This Russian PE firm didn't start with perfect rules.

They likely:
1. Lost money to mafia-connected businesses
2. Saw competitors fail in unfamiliar industries
3. Watched others chase massive but hollow opportunities

PM advice: "Track user patterns!"

Cool. But HOW?

After years of fumbling through this myself and mentoring new PMs, let’s see if I can break this down into actionable steps, starting with: 👇 1. Usage Patterns 📊

Drop-offs in flows:
• Set up funnel tracking (GA/Amplitude/Mixpanel)
• Track each step completion %
• Look for >20% drops between steps
• Record device/browser/time
• Tag user segments

The truth about becoming a Platform PM without an engineering background:

Most advice tells you to "learn to code" or "master system design."

I've found a completely different path that actually works.

A thread on what really matters 👇 1/ First, let's bust the biggest myth:

You DON'T need to be an expert in every technical area.

What you DO need:
• Deep expertise in 1-2 specific domains
• Understanding of technical limitations
• Ability to translate between business and tech

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

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.

Your fancy product strategy docs are scaring away engineers.

@johncutlefish created this simple "Plan on a Page" checklist that changed how I think about product planning.

No more 30-page strategy docs that no one reads.

Here's how to actually use it: [2/15]

First, understand what we're NOT doing:

• Creating another deck that sits in Confluence
• Writing essays about vision
• Making promises we can't keep

Instead, we're building a single-page "contract" between your team and the org.

A great Growth PM taught me: our biggest blocker isn't process or resources - it's our psychological relationship with uncertainty and risk.

I've seen these patterns across both B2B and B2C product teams.

Understanding them transforms how you operate.

Here's what I learned: 1/ First, we need to understand 2 fundamentally different operating modes:

Fear-based:
• Overanalyzing
• Seeking perfection
• Avoiding criticism
• Fear of failure

Opportunity-based:
• Focus on upside
• Accepting good-enough data
• Active learning
• "What if this works?"

PMs struggle with to-dos by treating product management like engineering: focusing on throughput and fearing mistakes.

But great product work is a game of oblique angles & needs a different mindset.

Try this framework adapted from @tferriss to break free from the box you're in: 1. Start before the chaos

Wake up 90 mins before you open Slack/email

This isn't about being a morning person

It's about choosing signal over noise

The New PM's Guide to Quick Wins That Actually Last

Most "quick win" tips for new PMs are useless.

"Fix bugs!"
"Get low-hanging fruit!"
"Prove immediate impact!"

After coaching numerous PMs, here's what truly builds lasting impact in your first 90 days: 1/ The Quick Win Paradox

Your first 90 days aren't about quick wins.

They're about quick INSIGHTS that lead to lasting wins.

Bad quick wins:
• Random bug fixes
• Vanity metrics jumps
• Low-value features

Good quick wins:
• Insight velocity
• Relationship capital
• Decision clarity

Your team just spent 3 weeks on user interviews.

The insights sit in a document.

No one looks at them.

Nothing changed.

After 6 years of doing product research as a PM, making mistakes and learning from great leaders, here's what actually works: 1/ The Inconvenient Truth

Most product research fails not because it's too shallow, but because it's:
• Too broad
• Too late
• Too disconnected from decisions

You don't need more research time.
You need research that changes decisions.

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.