your engineering background sabotages your product career in...

your engineering background sabotages your product career in predictable ways.

focusing on tech details, ignoring complex ideas, and favoring architecture over user needs leads to failure.

i've developed a system to transform engineers into effective product leaders. 🧵👇

1/ The biggest trap: thinking you need to solve everything

Your engineering brain wants to jump straight to HOW
- How to implement it
- How to optimize it
- How to scale it

But great PMs spend 80% of their time on WHAT and WHY

2/ "But my eng team expects technical solutions from me!"

This is where most technical PMs get stuck. You feel pressure to prove your technical worth.

Reality: Engineers respect PMs who bring clarity about the problem more than those who dive into implementation details

3/ Common objection: "If I don't specify the solution, we'll build the wrong thing!"

Truth: Over-specifying actually increases that risk

Instead:
- Define clear success metrics
- Document constraints
- Let the team explore solutions
- Guide with tradeoff discussions

4/ "My team moves faster when I give them the solution"

Short term: Yes
Long term: You're killing team ownership & creativity

What to do instead:
- Share context, not solutions
- Ask probing questions
- Let them surprise you with better approaches
- Build technical credibility through understanding, not directing

5/ The hardest part: fighting your own instincts

Your brain will scream "I know exactly how to build this!"

Stop. Ask these questions first:
- What problem are we solving?
- Who has this problem?
- How do we know it's real?
- What happens if we do nothing?

6/ "But I was hired for my technical expertise!"

Yes, but not to be the solution architect

Your technical background helps you:
- Understand feasibility
- Spot technical risks early
- Speak eng's language
- Challenge estimates intelligently

Not to design the solution

7/ Here's what worked for me:

- Force yourself to write the PRD without ANY technical solutions for the first draft
- Do customer interviews before opening your IDE
- Set a "24-hour rule" before proposing solutions
- Practice saying "What do you think we should do?"

8/ The transformation happened when I started measuring different things:

Old metrics:
- Technical elegance
- Implementation speed
- Feature completeness

New metrics:
- Customer problem solved
- Team ownership
- Long-term maintainability

9/ Common fear: "What if the team builds something that's technically suboptimal?"

Better question: "What if we build something technically perfect that solves the wrong problem?"

Let the team own the technical decisions. Your job is to ensure they're solving the right problem.

10/ Tools that helped me break free:

- Opportunity Solution Trees
- Problem statement templates
- JTBD interviews

I've collected these + more PM techniques and frameworks in prodmgmt.world

Follow @nurijanian for more PM insights 🤘🏼