The Product Managers Role Is Shrinking - Are You on the Right Side of It?
The gap between “product thinking” and “product building” is closing. PMs who stay upstream are becoming irrelevant.
The Handoff Is Not a Strategy
There’s a version of product management that sounds like leadership but functions like relay racing. You gather research, synthesize insights, write a crisp brief, hand it to engineering, and wait. Then you translate the output back into business language for stakeholders. Then you do it again. The loop closes — slowly — and somewhere in the middle, real decisions get made by people who aren’t you.
This model had a long run. And for a while, it made sense.
But the conditions that made it sensible are evaporating. The tools have changed. The speed has changed. The cost of building a prototype has dropped to near zero. And engineering teams — increasingly capable of moving from idea to deployed product faster than a PM can finish a PRD — are quietly asking a question they haven’t always had the standing to ask: what, exactly, are you contributing here?
This isn’t an attack on product management as a discipline. It’s a description of a split that is widening inside the profession — between PMs who have stayed upstream, comfortable in the realm of strategy and documentation, and PMs who have moved into the build loop, taking accountability for shipped outcomes rather than approved artifacts. The first group is becoming a coordination overhead. The second is becoming indispensable.
Why the Old Model Worked
To understand why this is changing, it helps to understand why the division of labor existed in the first place.
For most of software’s commercial history, building was genuinely hard. Shipping a feature meant weeks of development time, careful planning around release cycles, and real risk if you got the spec wrong. The cost of a bad requirement was enormous — not just in rework, but in delayed timelines and burned engineering trust. In that environment, it made sense to invest heavily in the what before touching the how. A PM who could translate business needs into precise, unambiguous specifications was genuinely valuable. The handoff was a feature of the system, not a flaw.
The structure reflected a few hard realities:
Tooling demanded specialisation. Understanding the technical stack, the deployment pipeline, and the database schema required years of experience. Non-technical PMs weren’t expected to have this fluency — and weren’t penalised for lacking it.
Org charts reinforced separation. Product and engineering often lived in different reporting chains. PMs managed up and across; engineers managed technical delivery.
Spec-first reduced expensive rework. With long release cycles, a bad requirement caught before build was worth far more than one caught after. Formalising the handoff was risk management.
The system worked — slowly, sometimes frustratingly — but it scaled because the roles were clear and the interfaces were defined.
What Changed
Three things collapsed the distance between thinking and building, and they reinforced each other
AI-assisted development. What used to take a senior engineer two days now takes a capable engineer two hours, with the right tools in play. Copilot, Cursor, Claude — the actual mechanics of translating an idea into working code have been partially automated. If anything the degree of automation is only going up. This means the build-time cost of experimentation has dropped dramatically. You can now generate, test, and discard three implementations in the time it previously took to spec one. The Product Manager who thinks the spec is the hard part is working with the wrong mental model of where time actually goes.
No-code and low-code tooling matured. The range of things that can be built without engineers has expanded far past landing pages and simple automations. Sophisticated data pipelines, internal tools, interactive prototypes, even lightweight production applications — these are increasingly within reach of someone who understands what they want but doesn’t write code professionally. A PM who can use these tools can close loops in hours that previously took sprint cycles. A PM who can’t is dependent on engineering capacity for even basic exploration.
Iteration speed compressed timelines. Continuous deployment, feature flags, and A/B testing infrastructure mean that the gap between “we think this is right” and “we know this is right” has narrowed. Products ship in days, not quarters. In that environment, the formal handoff process becomes a bottleneck. By the time a brief is written, reviewed, refined, and accepted, the context may have already shifted. The PM who operates at the speed of documents is working at the wrong cadence for the environment.
The net effect: The “translation layer” that Product Manager’s provided — converting business needs into engineering inputs, and engineering outputs into business language — is partially redundant. And the parts that remain valuable are precisely the parts that require judgment applied to real, working systems — not judgment applied to hypothetical ones.
What Upstream-Only PMs Get Wrong
The PM who stays upstream doesn’t usually think of themselves as upstream. They think of themselves as strategic. They write well. They run good meetings. They push back on stakeholders with confidence.
But something quietly goes wrong in how they relate to the product,
They optimise for the artifact, not the outcome. The roadmap becomes the deliverable. The PRD becomes the proof of work. The strategy deck becomes the thing that gets presented, refined, and celebrated — while what actually ships gets reviewed mostly through the lens of whether it matched the plan, not whether it worked.
📍 Real-world problem that we saw : PM spent three weeks perfecting a requirements doc for a new onboarding flow. Engineering teams built it to spec. We shipped, but activation rates did not move. The PM’s response: “The implementation didn’t match the vision.” but outcome finally did not match expectation.
Their feedback loops are broken. When a PM isn’t in the build, they hear about problems indirectly — engineering tells them something was more complex than expected, customer success flags an issue in a monthly call, a dashboard metric moves in the wrong direction two weeks after launch. The signal is real, but it’s attenuated and delayed.
By contrast, a PM who is present in the build — reviewing behaviour in staging, running their own test sessions, watching error logs — has access to ground truth in near-real time. The quality of their decisions reflects it.
They lose credibility with engineering over time. Engineers are pragmatists. They respect people who understand what they’re asking for — not at a code level, but at the level of system complexity, tradeoff space, and implementation risk. A PM who consistently:
Underestimates what’s hard
Overestimates what’s easy
Can’t distinguish a styling change from an architectural one
...eventually gets managed. Engineers start filtering what they bring to them. They work around, not with.
They confuse having opinions with having accountability. Anyone can have a product opinion. The question is whether you’re willing to own the deployed result — not the spec that preceded it, but the actual experience in the hands of actual users.
What Shipping Actually Means for a PM
Being a PM who can ship doesn’t mean writing production code. That’s a red herring that often gets used to dismiss this conversation before it starts. The argument isn’t that PMs should become engineers. It’s that PMs should stop treating the build as a black box.
Fluency over expertise. A shipping PM understands what’s hard and what isn’t. They know the difference between “this requires a schema migration” and “this is a config change.” They know when an engineering estimate sounds off and can have the conversation to find out why. They don’t need to write the code — they need to reason about it at the right altitude.
Presence in the build loop. This means:
Reviewing pull requests for behaviour, not syntax
Spending time in staging environments before launch, not after
Being the person who notices the edge case at 4pm rather than the person who files a bug report from a user complaint three days later
Having shared context with the team, not just shared documents
📍 Example in practice: A Product Manager at a fintech startup that I spoke to made it a habit to click through every staging build before it went to QA — not to do QA’s job, but to check that the experience felt right. In one case, she explained to me how she caught that a confirmation screen was technically correct but emotionally jarring — it showed a large red number that was actually positive context. Two-minute fix. It would have been a support ticket and a UX patch cycle otherwise.
Prototyping to communicate. One of the highest-leverage things a PM can do with modern tools is build a rough prototype that conveys intent — not to hand off, but to align. A five-minute prototype built in a no-code tool or assembled from a design system is worth more than three pages of written requirements. It reduces ambiguity, surfaces assumptions early, and communicates respect for the engineering team’s time.
Owning the deployed experience. A shipping PM doesn’t declare victory when the feature merges to main. They declare victory when users are getting value and the system is behaving as expected. That requires being engaged post-launch — diagnostically, not anxiously. What do the logs say? What does the support queue look like? What does the cohort data show? These aren’t questions to delegate — they’re questions to answer directly.
The New PM Profile
The PMs who are thriving in the current environment share a set of characteristics that cut against the traditional archetype:
Curious about implementation, not just ideation. They find it genuinely interesting to understand how a system works, not just what it does. This shapes how they ask questions, run sprint reviews, and engage at the start of a build rather than at the end.
Comfortable with ambiguity in technical form. They can sit in a half-broken staging environment and make useful observations. They can read a stack trace and extract the relevant information even if they can’t fix the problem.
They ship small things independently. Internal tools, Loom walkthroughs, data analyses, quick prototypes — a constant stream of small, useful outputs that exist outside the formal product development process. It builds intuition and demonstrates to the team that they produce, not just direct.
They lead by reducing friction, not adding process. When something goes wrong, their instinct is to remove what’s slowing the build down — including themselves when necessary.
The River Is Drying Up
Product management as a discipline is not disappearing. The need for people who can synthesize context, make tradeoff decisions, and connect user needs to business goals isn’t going away. If anything, that judgment is becoming more valuable as the cost of building falls — because you can now afford to build more things, which means the question of which things matters more, not less.
But the job is contracting around people who can operate close to the work. The comfortable middle — strategy on one side, engineering on the other, PM safely in between — is compressing. The people who positioned themselves there because it was a safe place to generate documents and run meetings are finding the territory shrinking under them.
The PMs who will lead the next decade of product development are the ones who figured out, early, that thinking and building were never supposed to be separate jobs. They just temporarily ended up that way because building was hard. Building is getting easier. The separation is closing.
The question every PM needs to answer — honestly, not strategically — is which side of that closing gap they’re on.
The gap between product thinking and product building is closing. The PMs who close it themselves will shape what gets built. The ones who wait for others to close it will find themselves describing a product someone else made.