Product Managers Must Get Into Coding... If They Want to Fail
Product managers must get into coding... if they want to fail.
In one of my startup stints, I was installing an IDE to explore code. I was even thinking of fixing a few bugs myself. Seemed productive. Seemed like I was "getting closer to the product."
The CEO noticed and stopped me.
After briefly discussing my intention, he said: "It's not that getting into the code or coding is wrong. But if you get into that mindset, you'll start worrying too much about the how. That will be a disaster for you as a PM."
I understood his point intellectually. It took me years to fully internalize why he was right.
TL;DR: When PMs think in implementation, they unconsciously constrain the vision. They lead with "how hard would this be?" instead of "what would be ideal?" The best products come alive when PMs hold the what and why long enough for engineering to find brilliant hows. Your job is to be ambitious about outcomes, not realistic about implementation.
The moment I saw it firsthand
While I understood my CEO's advice, I saw the damage of the coding mindset firsthand in another startup.
In an executive meeting, the CEO shared some ideas based on his customer meetings. Fresh insights. Exciting possibilities.
The product head instantly responded with implementation limitations. "That would require rearchitecting the data layer." "We don't have the infrastructure for that." "That's at least a 6-month effort."
At first, I was puzzled. Why move so quickly from idea to constraints? The CEO was sharing a customer need, and the response was immediately about what's hard.
Then it clicked. He had been an engineer for too long. The implementation lens had become his natural instinct. Every idea, every possibility, every customer request got immediately filtered through "but how would we build that?"
That filter killed ideas before they had a chance to breathe.
The "how" mindset vs. the "what" mindset
As PMs, our role is to keep asking:
- Why should this be built? (What's the user need? The business case?)
- What should it look like if we get it right? (What's the ideal outcome?)
The "how" will always matter. Engineering constraints are real. Technical debt is real. Infrastructure limitations are real.
But if you lead with the how, you'll always settle for less.
Here's the pattern:
| PM mindset | Response to a bold idea |
|---|---|
| How-first (engineering brain) | "That would be really complex. Let's scope it down." |
| What-first (product brain) | "That's ambitious. Let's define what ideal looks like, then figure out how to get there." |
The first PM produces incremental improvements. Safe bets. Technically feasible but uninspiring.
The second PM produces breakthroughs. Because they hold the vision long enough for engineering to find creative paths that nobody would have discovered if the idea had been killed in minute one.
Why the coding instinct is dangerous for PMs
When you code (or think in code), your brain develops a specific pattern:
- You hear an idea
- You immediately decompose it into technical components
- You estimate complexity based on those components
- You decide whether it's "feasible" or "too hard"
This happens unconsciously. You don't choose to do it. Your brain just pattern-matches from technical experience.
The problem: "feasible" and "valuable" are completely different dimensions. Something can be technically hard but extremely valuable. Something can be technically easy but worthless.
When the how-filter kicks in automatically, you:
- Kill ideas that are hard but transformative
- Approve ideas that are easy but incremental
- Unconsciously scope down everything to fit what feels implementable
- Lose the ability to push engineering toward ambitious solutions
You become an engineering manager with a PM title. Not a product leader.
The best products come from ambitious "whats"
Think about the products that changed industries:
- iPhone: "A phone with no keyboard, just a screen you touch." Engineering in 2005 said "that's impossible at consumer prices." Apple held the vision until engineering found the how.
- Spotify: "All music, instantly, legally, for a monthly fee." The licensing alone seemed impossible. They held the what long enough to make the how work.
- Notion: "One tool that replaces docs, wikis, databases, and project management." Engineering complexity was enormous. They held the vision and shipped iteratively toward it.
In each case, if the PM (or founder) had led with "how hard is this?", the product would have been scoped down to something forgettable.
Engineering brilliance thrives when it's challenged by ambitious whats and compelling whys. Give engineers a small, safe problem and they'll solve it adequately. Give them an ambitious, meaningful problem and they'll find solutions you never imagined.
"But shouldn't PMs understand technology?"
Yes. Absolutely. Understanding technology and coding are different things.
Understanding technology means:
- Knowing what's possible (at a high level)
- Understanding architectural trade-offs (without designing the architecture)
- Being able to have intelligent conversations with engineers
- Knowing when something is genuinely infeasible vs. just hard
- Understanding technical debt and its implications
Coding means:
- Thinking in implementation details
- Defaulting to "how" before "what"
- Feeling the weight of technical complexity personally
- Unconsciously scoping down to what feels buildable
The first is an asset. The second is a trap.
You can understand that a real-time recommendation engine is complex without knowing how to build one. That understanding helps you plan timelines and trade-offs. But you don't need to feel the complexity in your bones to make good product decisions.
What I've observed in PM-engineer dynamics
The best dynamics I've seen:
PM: "Here's what customers need. Here's what ideal looks like. I know this is ambitious. How do we get there?"
Engineer: "That's hard, but interesting. What if we... [creative approach]?"
The worst dynamics:
PM (with coding background): "I looked at the code. I think we can do a simpler version by just adding a field to this table and..."
Engineer: "...okay, I guess we're doing it your way."
In the second scenario, the PM has constrained the solution to what they personally can envision implementing. The engineer doesn't push back because the PM has already prescribed the how. The result is mediocre because the PM's implementation vision is always narrower than what a full-time engineer could imagine.
The temptation is real
If you're a PM who feels tempted to code, I get it. Especially in early-stage startups where "everyone does everything." It feels productive. It feels like you're contributing directly. It feels like you're "getting your hands dirty."
But remember:
- It's not about whether you can. Many PMs have engineering backgrounds. They could code.
- It's about whether you should. Your unique value is holding the vision, understanding customers, and making strategic choices. Nobody else on the team does that. Many people on the team can code.
If you spend your time coding, who's talking to customers? Who's thinking about strategy? Who's holding the vision long enough for engineering to find brilliant solutions?
The bottom line
Yes, the how will always matter. Technical constraints are real. Timelines are real. Engineering capacity is real.
But if you lead with the how, you'll always settle for less. You'll build what's easy instead of what's impactful. You'll scope down instead of finding creative paths. You'll become a technical PM who ships incremental improvements instead of a product leader who drives transformational outcomes.
The best products come alive when PMs hold the vision long enough, even when the implementation looks impossible at first. Because that's when engineering does its most creative, most brilliant work.
So if you're a PM who feels tempted to code, remember: it's not about whether you can. It's about whether you should. And the answer, almost always, is no.
How ProductResume helps
Your PM resume should communicate product thinking, not implementation thinking. If your bullets read like engineering contributions ("built," "coded," "implemented"), they signal the wrong mindset to hiring managers. Reframe toward outcomes and strategy. Score your PM resume to see whether your experience signals product leadership or execution.