Why 95% of Product Managers Can't Read Code (And Why That's a $1.85T Problem)

I sat in a product review meeting at a Series B fintech startup where the VP of Product confidently proposed moving a feature's deadline up by two weeks. The engineering director's face went pale. "That's literally impossible," she said. "We'd have to refactor the payment service first, and that touches core systems."

The VP asked: "Can't we just... not refactor it? Just add the feature?"

The director explained, technically and patiently, why "just add the feature" would create a catastrophic technical debt bomb. The VP listened, nodded, and said: "I understand you're saying it's hard. But can't we try?"

What happened next was a 45-minute argument that neither side won. The VP didn't understand why the code needed to be refactored. The engineer couldn't articulate it without getting into implementation details. They both got frustrated. A compromise was reached that satisfied nobody. The feature shipped later than the original deadline and broke other systems.

This scene plays out thousands of times daily at tech companies worldwide. And it costs the industry staggering amounts of money.

Here's the uncomfortable truth: roughly 95% of product managers cannot read code.

Not because they're bad at their jobs. Not because they're unintelligent. But because:

1. Most PMs come from non-technical backgrounds (consulting, MBA programs, sales)
2. Reading code is a skill that takes years to develop
3. Most companies don't train PMs to understand their codebase
4. The incentive structure doesn't reward technical understanding in PMs

Meanwhile, 100% of engineering decisions have business consequences. And 100% of business decisions have engineering consequences. But the people making those decisions can't see the other half of the picture.

The result is what researcher Jonathon Nightingale (formerly of Mozilla) calls "the alignment tax" - the organizational friction and inefficiency created when business and engineering operate in separate mental models.

Let's walk through how this actually breaks down in organizations:

Scenario 1: Underestimated Complexity

The PM looks at a feature request: "Add multi-currency support to the checkout flow."

Surface area: one page, four input fields, maybe a dropdown to select currency.

The engineer sighs and says: "Two weeks minimum."

The PM thinks: "That seems long. It's just adding a currency field."

What the engineer can see but the PM can't:

• The payment processor API needs to be re-integrated (it currently doesn't support multi-currency)
• The tax calculation engine was hardcoded for USD
• The shipping cost service isn't currency-aware
• The reporting dashboard has assumptions about single currency
• The inventory system ties pricing to single currency
• Three different microservices all need changes

But since the PM can't read the code and the engineer can't easily show her without getting into 30 minutes of architecture explanation, they end up in: "Trust my estimate" vs. "That seems excessive."

The compromise: ship in 1.5 weeks, sacrifice quality, spend the next quarter fixing bugs.

Cost: One engineer burnt out from death-march shipping. Two other engineers distracted by production issues. One customer incident due to incomplete integration. Three weeks of engineering time spent on firefighting rather than planned work.

Scenario 2: Invisible Technical Debt

The engineering team has been flagging a recurring problem: "The user authentication service is a bottleneck for every new feature."

The PM hears "we need to refactor."

The PM thinks: "Refactoring doesn't create customer value. Let's keep shipping features."

What's happening in the code:

• Every new feature needs to integrate with auth
• The current auth service is monolithic and tightly coupled to the old API design
• New features that need custom auth logic get hacked into the existing service
• Each hack makes the service slower and harder to modify
• The service now has 30,000 lines in a single file
• New engineers can't understand it
• Features that should take 2 days now take 5 days because of auth integration complexity

But the PM can't see this. She sees: "Auth refactor" in the backlog and moves it to the bottom. Features move up.

Six months later: the team's velocity has dropped 40%. What should be a 3-day feature takes a week. The PM is confused - the team seems to be slowing down even though we're fixing bugs and not adding people to the project.

Cost: Lost feature velocity that compounds over time. New hire onboarding time extends from 6 weeks to 12. One senior engineer leaves because she's frustrated with the constant hacks. New hiring round costs $120k and takes 3 months. The refactor that would have taken 2 engineer-weeks of focus now would require 8 weeks because the problem is worse.

Scenario 3: Misaligned Roadmap

The PM builds a 12-month product roadmap without consulting the engineering architecture.

Months 1-3: Build feature A Months 4-6: Build feature B Months 7-9: Build feature C Months 10-12: Build feature D

What the PM can't see: Features A, B, and C all need a shared foundation that doesn't exist. They weren't planned to be built together, so no architectural work was scheduled. Each feature ends up with its own partial solution to the shared problem.

The team ships it. It works. But the code is fragile. Every feature took longer than estimated because engineers had to work around missing foundation. Future engineers struggle to understand why the same concept is implemented three different ways.

Cost: Six months of team time spent on rework and architectural cleanup. A second-order effect of low code quality is low developer morale - people don't like working in fragile systems.

The Economist, citing research from McKinsey and BCG, estimated that poor communication between product and engineering costs the software industry approximately $1.85 trillion annually in:

• Rework and bug fixes
• Technical debt management
• Extended timelines
• Team turnover
• Opportunity cost (features that never shipped because teams were firefighting)

That's not hyperbole. That's the sum of every engineering organization globally spending time on things they wouldn't need to do if product and engineering started from the same understanding.

This isn't about PMs learning to code (though that helps). It's about PMs understanding:

• Dependency relationships: What systems does my feature touch?
• Coupling: When I change this, what breaks?
• Technical debt: What work have we deferred that will bite us later?
• Tradeoffs: What quality are we sacrificing for speed?
• Feasibility: Is this architecturally possible, or are we asking for something that contradicts our system design?

When PMs understand these dimensions, they make better roadmap decisions. They understand why an estimate is what it is. They can evaluate "ship fast and pay technical debt" vs. "ship slower but build right" with their eyes open.

The best tech companies I've observed handle this problem in three ways:

1. Architecture Access Tools

Some teams now use tools designed to make codebase knowledge accessible to non-technical stakeholders. Rather than forcing the PM to learn to code, you make your codebase searchable, queryable, and explainable.

A PM with access to an architecture visualization tool can:

• Ask: "How many services does the checkout flow touch?" (and get an answer visually)
• Understand: "These two features are in the same service, so they affect each other"
• See: "The payment processing service is responsible for X, Y, and Z - adding this new currency requirement touches all three"

This doesn't replace learning; it augments understanding.

2. Engineers in Product Meetings

Forward-thinking companies have engineering leads in product planning meetings from the start. Not to say "no" to ideas, but to make feasibility and dependency information visible. This means PMs have access to expert feedback on complexity and tradeoffs right when roadmap decisions are being made.

3. Structured Technical Communication

The best product-engineering relationships I've seen have a ritual where engineers can formally surface technical concerns. This isn't a meeting where engineers complain about technical debt - it's a structured opportunity to show the business impact of technical decisions.

"If we don't refactor the auth service now, we'll lose 6 weeks of velocity per quarter for the next year, costing us approximately $X in opportunity cost and team turnover" is a language PMs understand.

If you're a PM who wants to improve this relationship with your engineering team:

Week 1: Spend 2-3 hours with your engineering lead reviewing the core systems. Don't try to understand everything. Ask: "What are the critical paths? What do most features depend on?"

Week 2: Attend a technical design review. Don't contribute; just listen and ask clarifying questions.

Week 3: Review your next feature request with an engineer before planning it. Ask: "What systems does this touch? What existing code do we need to understand?"

Month 2+: Make it routine. Build a shared mental model of the system. The conversations get faster and more productive.

If you're an engineering leader:

Don't expect PMs to learn to code, but give them tools and access. Consider lightweight architecture documentation or visualization tools (including modern codebase intelligence platforms) that make your system legible to non-engineers.

Invest in communication rituals that let technical concerns surface in business terms, not implementation details.

Hire product people with technical backgrounds when you can. And invest in training for product people who aren't.

Companies that crack this problem - where PMs genuinely understand their systems and engineers genuinely understand business context - experience:

• 30-40% better estimation accuracy (fewer surprises)
• Faster feature shipping (better roadmap planning that accounts for dependencies)
• Lower technical debt accumulation (tradeoffs are explicit)
• Better retention (engineers aren't frustrated by misaligned priorities)
• Higher quality products (decisions are made with full information)

It's not that technical PMs are smarter. It's that they're operating with better information, and their decisions reflect that.

Here's what most enterprises don't want to admit: your engineering timeline isn't actually 6 weeks for that feature. It's 6 weeks of pure engineering work plus 2-4 weeks of the PM-engineer communication gap (hidden estimates, rework from misalignment, architectural surprises halfway through).

That's not a technical problem. It's an information problem.

And it's fixable. Not overnight. But much faster than most companies think.

The companies that are quietly winning in their markets tend to have one thing in common: their product and engineering teams are fluent in each other's languages. The PM can talk about system dependencies. The engineer can talk about business impact.

If that's not true at your company, that gap isn't a personality problem. It's a capability problem. And it's treatable.

---

• The Economist: Why Tech Companies Should Invest in Better Product-Engineering Alignment
• Stack Overflow Developer Survey 2023: Product Management & Engineering Communication
• DORA State of DevOps 2023: Communication as a DevOps Capability
• Harvard Business Review: The Engineering-Product Partnership