George from 🕹prodmgmt.world Profile picture
Oct 10 10 tweets 2 min read Read on X
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."
The biggest lie in product management: trusting your gut without feeding it data first.

That senior PM who makes seemingly instant good calls has already internalized 500+ customer conversations, watched multiple product cycles play out, run dozens of failed experiments, and burned through every bad assumption at least twice.
Most PMs confuse product sense with personal preference.

"I think users would love dark mode" = personal preference
"Users abandon at this step because cognitive load spikes when we ask for 7 inputs at once" = product sense

One is opinion. The other is pattern recognition.
The interview industrial complex turned product sense into performance art.

Designing an alarm clock in 45 minutes tests your ability to bullshit coherently, not your ability to recognize real user problems.

Meanwhile, actual product sense looks boring: spreadsheets of user behavior, session recordings, support ticket patterns.
Companies that actually care about product sense don't test it with hypotheticals.

They ask:
- Walk me through a product decision where you were wrong. What signals did you miss?
- Show me how you changed your mind based on user data
- Explain a complex tradeoff you made and why
- What assumption did you validate that surprised you?
- Describe a time you shipped something users hated. What did you learn?
Product sense without evidence is just expensive guessing.

The PMs who ship successful products combine systematic user observation (not just interviews), technical constraints awareness (what's actually possible), and business model understanding (what creates value).

Not vibes. Systems.
Stop calling it product sense. Call it what it really is:

Accumulated evidence from direct user contact, interpreted through experience, applied with intellectual honesty about what you don't know.

Everything else is just confident ignorance dressed up as intuition.
The PMs who actually have product sense never talk about having product sense.

They talk about specific user behaviors, conversion funnel bottlenecks, and technical tradeoffs.

Because they're too busy building products that work to philosophize about abstract concepts.
Want to build product sense the right way? Stop guessing, start shipping.

I've packed 135+ AI prompts for customer research, data analysis, and decision-making into one system.

For the ones who actually do the work:

prodmgmt.world/products/ai-pr…

• • •

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

Oct 10
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.
2/ Most PMs batch emails. Elite PMs batch context.

First hour: Strategic inputs (roadmap, vision, major decisions)
Mid-morning: Dev blockers and design reviews
Early afternoon: Tactical inputs (bugs, features, quick wins)
Late afternoon: Stakeholder updates
End of day: FYI inputs (updates, announcements)

Context switching kills. Batching saves.
Read 6 tweets
Oct 9
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 👇 Image
[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.
[2/20] Start with the scaffold, not the masterpiece:

1. Current State
2. Desired Future
3. Path to Get There
4. Success Metrics

That's it. Everything else is decoration.
Read 21 tweets
Oct 9
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.
2/ Most new PMs make this critical mistake:

They try to understand *all* the technical debt first.

Don't.

Instead, map the impact first:
- Which issues block new features?
- Which ones cause production incidents?
- Which ones slow down development?
Read 14 tweets
Oct 8
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:
The hard truth:

Your small team can only build 2-3 meaningful things per quarter.

That's it.

No fancy tool will change this fundamental constraint.

(For product leaders: this is why your small-team PMs need different expectations)
Read 11 tweets
Oct 7
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
1. Start With Your Domain

Before touching any "product" metrics:
Look at an area you understand well:
• Personal budgeting
• Weight loss tracking
• Any domain where you've used numbers

Study how those metrics work:
• What gets measured
• How they connect
• What indicates success

This builds your pattern recognition.
Read 11 tweets
Oct 6
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 👇🏼
1/ The Preparation Paradox

Rookie mistake: Preparing 20 specific questions and moving through them without exploring any curiosities.
Pro move: Preparing 3-5 conversation areas

Your goal isn't to survey your users live.
It's to understand their world to solve real problems.
Read 12 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!

:(