Engineers-turned-PMs destroy design relationships in predictable...
George from 🕹prodmgmt.world@nurijanian
48 views
Mar 26, 2025
~3 min read
Advertisement
1
Engineers-turned-PMs destroy design relationships in predictable ways.
I made every mistake for 4 years before finding the solution.
The 2-minute framework that saved countless products: 👇
I made every mistake for 4 years before finding the solution.
The 2-minute framework that saved countless products: 👇
2
Most orgs create an artificial competition between PMs and designers:
"Who owns the user experience?"
"Who decides what we build?"
"Who represents the user?"
This toxic setup wastes time, creates resentment, and ultimately ships worse products.
"Who owns the user experience?"
"Who decides what we build?"
"Who represents the user?"
This toxic setup wastes time, creates resentment, and ultimately ships worse products.
3
The real issue isn't role definition – it's mental models.
As a technical PM, I'd instinctively jump to solutions, sketch UI ideas in meetings, and inadvertently step all over my designers' expertise.
My engineering brain wanted to "solve" before fully understanding.
As a technical PM, I'd instinctively jump to solutions, sketch UI ideas in meetings, and inadvertently step all over my designers' expertise.
My engineering brain wanted to "solve" before fully understanding.
4
The breakthrough came when I realized PMs and designers operate in fundamentally different cognitive spaces:
PMs work primarily in the problem space – WHY we're building
Designers work primarily in the solution space – HOW it works
This overlap is where the friction happens.
PMs work primarily in the problem space – WHY we're building
Designers work primarily in the solution space – HOW it works
This overlap is where the friction happens.
5
Many PMs think their job is to define what to build (it's not).
The PM's actual role is to define problems worth solving, establish success metrics, and manage constraints.
The designer's role is to explore the solution space within those parameters.
The PM's actual role is to define problems worth solving, establish success metrics, and manage constraints.
The designer's role is to explore the solution space within those parameters.
6
From a PM who failed at this repeatedly:
- Don't prescribe solutions
- Don't provide UI mockups
- Don't do the designer's job
Instead:
- Define clear problems
- Set clear constraints
- Establish clear metrics
- Let designers do their craft
- Don't prescribe solutions
- Don't provide UI mockups
- Don't do the designer's job
Instead:
- Define clear problems
- Set clear constraints
- Establish clear metrics
- Let designers do their craft
7
Effective PMs create the conditions for great design to happen, not the design itself.
What does this look like in practice?
BAD: "We need a dashboard that shows MRR, churn, and acquisition costs with filters for time periods."
GOOD: "Users need to understand what's driving revenue changes so they can make better pricing decisions."
What does this look like in practice?
BAD: "We need a dashboard that shows MRR, churn, and acquisition costs with filters for time periods."
GOOD: "Users need to understand what's driving revenue changes so they can make better pricing decisions."
8
When I learned to focus on problems vs solutions, my relationships with designers transformed overnight.
Suddenly we weren't competing - we were collaborating from our respective strengths. The tension disappeared.
Suddenly we weren't competing - we were collaborating from our respective strengths. The tension disappeared.
9
I know you're thinking: "But I have good UI ideas! I'm close to customers! Sometimes designers need direction!"
You're right. And that's the trap.
Just because you CAN do some aspects of design doesn't mean you SHOULD.
You're right. And that's the trap.
Just because you CAN do some aspects of design doesn't mean you SHOULD.
10
The hard part for technical PMs is accepting that brilliant point solutions often miss the bigger system.
Your role isn't to have no opinion. It's to:
1. Frame the right problems
2. Set clear constraints
3. Ask great questions
4. Test outcomes vs. intentions
5. Provide business context
Leave the solution exploration to expert designers.
Your role isn't to have no opinion. It's to:
1. Frame the right problems
2. Set clear constraints
3. Ask great questions
4. Test outcomes vs. intentions
5. Provide business context
Leave the solution exploration to expert designers.
11
"But my designer is junior and needs guidance!"
Then mentor them on design thinking, don't do their job for them.
"But I have to move fast and don't have time!"
This approach is actually faster because you avoid rework from poorly conceived solutions.
Then mentor them on design thinking, don't do their job for them.
"But I have to move fast and don't have time!"
This approach is actually faster because you avoid rework from poorly conceived solutions.
12
PMs who succeed at this partnership use a simple model:
1. PM frames the problem, constraints, and success metrics
2. Designer explores solution space and proposes approaches
3. PM and designer evaluate solutions against metrics
4. PM handles stakeholder alignment and tradeoffs
5. Designer refines the final approach
1. PM frames the problem, constraints, and success metrics
2. Designer explores solution space and proposes approaches
3. PM and designer evaluate solutions against metrics
4. PM handles stakeholder alignment and tradeoffs
5. Designer refines the final approach
13
I used to think my technical background made me a better PM because I could "speak design."
I was wrong. It made me dangerous because I skipped steps and jumped to solutions.
I was wrong. It made me dangerous because I skipped steps and jumped to solutions.
14
The most valuable resources that helped me overcome this:
1. Asking my designers to call me out when overstepping
2. Learning proper problem framing
3. Developing a repository of great design briefs
1. Asking my designers to call me out when overstepping
2. Learning proper problem framing
3. Developing a repository of great design briefs
15
For # 3, I've collected templates in tiny.cc/product-bundle that helped me structure better design briefs.
Game-changing for technical PMs like me.
Game-changing for technical PMs like me.
16
What I've found most helpful: Before any project, have an explicit conversation with your designer about:
1. Who makes what decisions
2. How you'll handle disagreements
3. What success looks like for both of you
4. How you'll communicate throughout
This foundation prevents 90% of issues.
1. Who makes what decisions
2. How you'll handle disagreements
3. What success looks like for both of you
4. How you'll communicate throughout
This foundation prevents 90% of issues.
17
To my fellow technical PMs: Your engineering background is an asset ONLY if you recognize when it becomes a liability.
Your job isn't to design solutions.
Your job is to set the conditions for great solutions to emerge.
Let me know if this resonates with your experience. ↓
Your job isn't to design solutions.
Your job is to set the conditions for great solutions to emerge.
Let me know if this resonates with your experience. ↓
