TL;DR
For two decades, the unwritten rule of product was one PM per four to six engineers. AI broke the math. Engineering throughput in small teams has increased by roughly 3–5x over the past 18 months. Product judgment throughput isn’t. The bottleneck has moved from the keyboard to the whiteboard, and founders, who are almost always the de facto PMs, are sitting right where the new constraint lives. This post argues four things: The PM-to-Engineer Ratio Is Inverting.
- The 1:4 ratio existed because the build was the constraint. It isn’t anymore.
- Effective small teams are now operating closer to two PMs of judgment per one engineer of throughput usually inside the same heads, badly.
- Going faster without better product judgment is just a faster way to ship something your customers don’t want.
- You don’t need to hire a PM. You need to systematize product thinking the same way you systematized deployment six years ago.
If you’re a product manager or founder, this is the structural shift to plan around in 2026.
When The Build Process Was The Constraint
For most of my career as a PM, my job had been to stay one sprint ahead of engineering. The cadence was forgiving. Engineers were the bottleneck; I had time to think, time to talk to customers, time to write a proper spec, time to argue with myself before I committed to a direction. The whole social contract of product management you decide, they build assumed building took longer than deciding.
That contract is dead. And almost no PM or founder I talk to has updated their operating system to reflect it.
This is the post where I try to update mine, out loud.
Why the Old Ratio Existed
The 1:4 ratio (one PM to four to six engineers) wasn’t a number someone made up at a conference. It reflected an actual physical constraint: engineering output was the pace-setter. Writing code, reviewing it, testing it, deploying it, and supporting it through a release took weeks. A PM could comfortably manage the backlog, run discovery, talk to customers, and stay ahead of four engineers without becoming the bottleneck themselves.
In that world, product thinking was treated as overhead. Important, but secondary to getting code shipped. The PM’s job was to stay one sprint ahead of the team and make sure no one was blocked waiting on a decision. Whole org charts were designed around the assumption that you would always need more engineers than thinkers, because every additional engineer added measurable throughput, and every additional PM added meeting overhead.
This model worked because the constraint was always build capacity. If you could hire more engineers, you could ship more. So you hired engineers.
I trained my entire instinct as a product leader inside that constraint. So did most of the founders reading this.
What’s Inverting It
AI-assisted development has fundamentally changed the denominator. The same engineering team that used to ship a non-trivial feature in two weeks can now ship it in two days. Pull request throughput is up. Scaffolding, boilerplate, tests, migrations, and even first-pass UI all accelerated. Small engineering teams are shipping roughly 3x as much as they shipped a year ago. It’s Claude Code, Cursor, and the discipline these teams bring to using them.
The constraint has shifted. It’s no longer can we build it fast enough. It’s do we know what to build fast enough.
Some of the strongest small teams I’m watching are operating at the equivalent of two PMs per one engineer, not because they doubled their PM headcount, but because the product judgment required to direct accelerated engineering output has roughly doubled. You need more decision-making throughput, more prioritization cycles, more customer contact hours, and more clarity about which bets are learning bets and which are revenue bets. (If that distinction matters to you, see Build to Learn, Build to Earn it’s the verb the Product Onion was missing, and it’s the same logic at work here.)
The bottleneck moved from the keyboard to the whiteboard. And founders are sitting right at that whiteboard, usually with a cup of coffee getting cold next to a half-written customer interview script.
The Founder Implication (The Uncomfortable Version)
Here’s the part most founder-facing content soft-pedals: you are already the PM. You are doing discovery, making prioritization calls, writing specs on the back of napkins, and deciding what’s on the roadmap, usually between 9 PM investor emails and 6 AM supplier calls. The ratio inversion does not give you the option to keep treating product thinking as something you’ll hire for in Q3.
It validates that this is the work. The strategic work, the customer-talking work, the “why are we even building this” work that’s not pre-work for the real job. That is the job, and it has roughly doubled in volume because engineering can now consume your product judgment at a much higher rate than before.
The warning that comes with it: if your engineering capacity is accelerating and your product thinking isn’t keeping up, you’ll ship faster into the wrong thing. Velocity without judgment is just a faster path to a more expensive mistake. I’ve watched this play out at Trevean every time I’ve let the engineering pace pull me into reactive mode. The features still ship. They ship into a vacuum where customer signal hasn’t caught up with the build capacity, and then they sit there on the dashboard, looking like progress while quietly being noise.
This is also why the ratio inversion connects directly to The Control Trap. The instinct, when judgment becomes the bottleneck, is to clamp down and insist on approving every decision, to slow the engineering pace back to your thinking pace. That’s the wrong move. The right move is to raise the level of the decisions you’re making and push the lower-level ones down with better context, not less. A bottleneck founder who hoards decisions is a slower version of the same problem.
Where PMs and Founders Almost Always Get This Wrong
Most PMs and Founders treat the inversion as a velocity problem. The answer is to add more meetings, add more reviews, and add more PM-flavored ceremonies around the engineering output to slow it down to a pace you can match. That is the wrong way to approach the problem on two levels.
First, it punishes the team for doing their jobs well. It becomes demoralizing in the specific way that micromanagement always is. (Same disease as the sent-email-editing scene from The Control Trap, just dressed in different clothes.)
Second, and more importantly, it doesn’t actually fix the underlying problem. Product thinking doesn’t get sharper because you added a Wednesday review meeting. It gets sharper when you start running Persona Feature Testers in the gap between customer interviews, start writing a one-page outcomes brief at the start of every sprint instead of a list of features, and start letting ship more decisions at Level 4 (decide and tell me) on anything inside his clear scope of mastery.
The fix isn’t slowing the engineers down. It’s scaling up the production of the product judgment: a different problem, a completely different solution.
What to Actually Do About It
You don’t need to hire a PM. You need to systematize product thinking so it can scale with your engineering velocity. Four things have actually worked:
1. Outcomes first, not features first.
Keep a living outcomes document, not a roadmap, an outcomes list. What does success look like for each initiative, in a sentence that a customer would recognize? Update it weekly. This forces the product question upstream of the build, where it belongs. (For the structural version of this, see Why Thematic Roadmaps Are the Communication Tool Most Founders Never Learn outcomes are the input, themes are the output.)
2. Compress the feedback cycle.
If your engineers can ship in two days, you need customer feedback in one. Build feedback into the product itself: in-app prompts, direct outreach within 48 hours of a feature touching a real user, persona pressure-tests before the sprint, not during the retro. Treat customer signal latency as a real engineering metric. If the gap between “shipped” and “we know what they think” is longer than the gap between “decided” and “shipped,” you have the new bottleneck right there.
3. Run a two-speed roadmap.
Separate build-to-learn bets from build-to-earn commitments. Not everything in your sprint should be revenue-driving. Some things are hypotheses with a kill criterion attached. Label them that way so you know what to measure and so the team knows what success looks like. A learning bet that ships and produces no learning is a worse outcome than a feature that ships and produces no revenue.
4. Protect the thinking time like it’s the production database.
Treat your PM time as the bottleneck it now is. Block it on the calendar. Defend it from coordination work. Resist the urge to fill it with status updates and Slack triage. Strategy and discovery are your highest-leverage activities as a founder, and they’re the ones that quietly get squeezed into the cracks unless you fight for them. I block 7 to 10 AM five days a week as customer-and-thinking time. It is the single highest-ROI calendar block I run.
If you only do one of these, do the second one. The compression of the customer feedback cycle is the lever that brings the product judgment side of the ratio into alignment. Everything else is downstream.
The Bigger Picture: Why This Connects to the Product Onion
The ratio inversion isn’t just a staffing story. It’s a signal about where leverage lives in a modern product company, and it maps cleanly onto the Product Onion framework.
For a long time, leverage was in the outer layers. Write more code. Ship more features. Run faster. The interior layers, who are we for, what do they actually need, what’s the core problem we’re solving, were treated as the slow, hard, philosophical part you visited once a year at an offsite. The outer layers ate most of the operating budget.
Leverage is now in the interior layers. The teams that know precisely who they’re for, what those customers actually need, and what outcome would constitute success, those are the ones who win when everyone’s outer-layer engineering capacity is roughly equal. AI didn’t kill the differentiation game. It moved the differentiation game from outer-layer execution to inner-layer clarity.
In a world where a competitor can clone your feature set in weeks, the only durable moat is knowing your customer better than they do, and updating that knowledge faster than anyone else. That’s not a tooling problem. That’s a learning-machine problem. And the founder is the person who decides whether the learning machine is honest, fast, and pointed at the right questions. (This was also the implicit thesis of the 100-posts retrospective the tools were never the lever; the question you finally got brave enough to ask was the lever.)
The ratio is inverting. The question is whether your product thinking is keeping pace.
Your Move
Three things to try this week if you suspect the ratio has flipped on you.
Audit your last ten decisions.
Pull them up. Mark each one with the time you spent thinking about it versus the time engineering spent building it. If the second number is consistently smaller than the first, the ratio has already flipped at your company, and your operating system hasn’t noticed yet.
Pick one feature in flight and ask: Do I actually know what success looks like?
Not “did we scope it.” Not “is the spec written.” Do you have a sentence, a real, customer-recognizable sentence that describes what changes for them when this ships? If not, you’re shipping into a vacuum. Stop building. Write the sentence. Then resume.
Block 90 minutes tomorrow morning, before Slack opens, for thinking and customer talking only.
No tickets. No reviews. No coordination. Just the work that produces a product judgment. Do it once. See what falls out of your head when nothing is competing for the cycles.
Hit reply and tell me which one you ran and what changed. I’m collecting these for a future issue of The PM’s Spice Rack, and the most interesting patterns will almost certainly come from founders, not from frameworks.
The ratio is inverting. Your job, if you’re the founder doing both, is to make sure your thinking moves up the stack at least as fast as your shipping does.
Frequently Asked Questions
What is the PM-to-engineer ratio?
The PM-to-engineer ratio is the rough staffing convention that, for most of the last twenty years, prescribed roughly one product manager per four to six engineers on a software team. The ratio reflected the historical reality that engineering throughput was the binding constraint on shipping product, so PM headcount was scaled to keep up with, but not exceed, engineering capacity.
Why is the PM-to-engineer ratio changing in 2026?
AI-assisted development has roughly tripled engineering throughput on small teams in the last 18 months. The bottleneck on shipping product has shifted from build capacity to product judgment, knowing what to build, who it’s for, and how to measure whether it worked. As a result, effective teams are operating closer to 2 units of product judgment per 1 unit of engineering throughput, a near-inversion of the historical ratio.
Does this mean founders should hire more PMs?
Not necessarily. For most early-stage founders, hiring a PM is the wrong first move. The better move is to systematize product thinking outcomes, documents, compressed feedback loops, two-speed roadmaps that separate learning bets from earning bets, and protected blocks for strategic work. A PM hire only pays off once those systems are in place; without them, an additional PM adds coordination overhead without solving the underlying judgment-throughput problem.
What is a build-to-learn versus a build-to-earn bet?
A build-to-learn bet is a feature you ship primarily to generate evidence for a hypothesis about customer behavior, willingness to pay, or a workflow assumption. A build-to-earn bet is a feature you ship primarily to capture revenue or retention from an already-validated hypothesis. Healthy roadmaps run both kinds simultaneously and label them clearly so the team knows whether the success metric is “we learned something” or “we made money.” See Build to Learn, Build to Earn for the full framework.
How does the ratio inversion connect to the Product Onion framework?
The Product Onion argues that the durable layers of a product live at the core (who you serve, what they actually need, what outcome counts as success). The disposable layers live on the surface (specific features, specific tools, specific implementations). For most of the last decade, leverage was concentrated in the surface layers, which is why the engineering-heavy ratio worked. The ratio inversion is what happens when AI commoditizes surface-layer execution and forces leverage back into the interior layers, the layers that produce product judgment.
What is the most important practice to adopt first?
Compress the customer feedback cycle. If your engineering team can ship a feature in two days, your team needs to know what customers think within one. The single highest-leverage move for most founders is to shorten the time between “shipped” and “we have a credible signal about whether it worked.” Everything else, outcomes documents, two-speed roadmaps, protected thinking time compounds on top of that loop.
Doesn’t slowing engineering down solve the same problem?
It might feel like it does, but it doesn’t. Slowing engineering down to match the slower pace of product judgment punishes the team for being effective and disguises the real problem rather than solving it. The right answer is to scale up the production of product judgment to match engineering throughput through systems, customer contact, and protected thinking time, rather than to throttle the part of the system that’s working.
How do I know if the ratio has already flipped at my company?
Three signals. First, you regularly find yourself approving features the night before or the morning of the build, rather than days in advance. Second, your engineers have idle moments waiting on you to make decisions, instead of the other way around. Third, when you ask “what does success look like for this feature,” the answer is in scope language (“we shipped X”) instead of customer language (“customers can now do Y”). Any one of those signals means the bottleneck has moved.
What should a founder protect on their calendar to stay on top of things?
A daily 90-minute block, ideally early morning, before Slack and email open, for thinking and customer-talking work. No tickets, no reviews, no coordination. The block is for the kind of work that produces product judgment, which is now the binding constraint on shipping. Treat the block the same way you’d treat a production database: with hard guardrails, real respect, and a recovery plan if something forces you to skip it.
How does this connect to leadership and delegation?
Tightly. When product judgment becomes the bottleneck, the founder’s instinct is to clamp down on decisions, which is exactly the failure mode described in The Control Trap. The right response is the opposite: raise the level of the decisions you personally make, push the lower-level decisions down with strong context, and let the team operate at higher delegation levels inside their scope of mastery. Founders who hoard decisions in response to the ratio inversion become slower versions of the same bottleneck.
Dan Blizinski is the founder of Trevean Spice and the writer behind The Product Manager’s Journal, where he writes about PM frameworks that come from actually building things, not just theorizing about them. New here? Grab the free Startup PM Toolkit, five frameworks he actually uses.