Loading…
Loading…

In the past few weeks I have done something I haven't done in a long time: I have been building things for myself. Several fully fledged apps, including a licensing usage analyzer, a competitive signal aggregator, a web shop for testing and demo, and more, all built between meetings, all solving real friction in my team and my workflow.
And then the one that stopped me in my tracks: a working prototype of a new solution that takes what Tricentis Tosca does best in structured, model-based coverage, and combines it with the agility of Testim, reimagined entirely for the agentic era.
Months of work in the old world. Days in this one. The builds took days. The decisions they forced took longer.
That gap between what AI enables and what judgment demands is what nobody is writing about. In my previous articles, I described the structural shift from Feature Factory to Intelligence Factory and shared how Gemini and Claude have become genuine thinking partners. Both were net-positive narratives. They should be. The leverage is real, and the joy of building has genuinely returned.
But there is a harder conversation on the other side of that leverage. When a Product Manager can build, everything changes: not just for the PM, but for the entire team, the product process, and the nature of leadership itself.
When engineering scarcity was the norm, the PM's job was partly about restraint. You had to say no constantly, not always because the idea was bad, but because the bandwidth wasn't there. Scarcity created discipline by default.
Agentic AI has removed that forcing function.
Today, a PM with Claude Code, a Vercel sandbox, and a few well-crafted prompts can spin up a working prototype before the design team has opened Figma. What used to require a sprint can happen before lunch. This is genuinely extraordinary. It is also, if you're not careful, a trap.
The most common failure mode I am watching unfold right now isn't that PMs are slow to adopt AI. It is that they're using it to avoid the hard decisions. Building another prototype is productive-feeling. Deciding which prototype to kill, and why, is uncomfortable. When the cost of creation drops to near zero, the discipline of elimination becomes the rarest and most valuable skill in the room.
The Intelligence Factory is open. But a factory that produces everything produces nothing of value.
The Agile era gave us a clean division of labor that became foundational doctrine: Product Managers own the What and the Why. Engineers own the How. It was a sensible contract. PMs focused on outcomes; engineers held the keys to implementation.
That contract is now under fundamental renegotiation.
When a PM can Vibe code a full stack application, the boundaries between "What, Why, and How" collapse. The PM who builds a working prototype hasn't just described the outcome; they've demonstrated a possible path to it. They've made implicit engineering decisions in the act of building. The "How" has leaked into the PM's domain whether anyone intended it or not.
This creates a dynamic that nobody is talking about openly enough. For years, "is this technically feasible?" was a check on PM ambition that engineers owned entirely. When a PM shows up with a working prototype, that check no longer functions the same way. The conversation shifts from feasibility to quality, scalability, and maintainability.
I have experienced both sides of this over 30 years. I've been the engineer skeptical of the PM's vision, and I've been the PM who had to earn technical credibility the hard way. What I am seeing now is a third state: the PM who demonstrates functional feasibility, then hands it to engineering as a proof of concept with explicit respect for what professional engineering actually involves.
The Full Stack PM isn't trying to replace engineers. They're trying to eliminate the translation layer: the costly, lossy process of converting intent into specification into implementation. The prototype is a communication tool, not a deliverable.
Done right, this makes engineering teams faster. Done wrong, with a PM who ships prototypes and implies they are production-ready, it creates resentment and technical debt simultaneously.
The teams navigating this well share one habit: the PM is explicit about what the prototype is and isn't. "I built this to show the interaction model. You will rebuild it properly for scale. Here is what I learned about the data dependencies."
Article 1 in this series introduced the idea of Proof of Intent: the PM as the human validator ensuring AI-generated artifacts align with ethics and strategy. I want to push that concept further.
AI systems are inherently "lossy." They optimize for coherence and plausibility. They are structurally incapable of the judgment that comes from sitting in a customer meeting where something felt wrong before the data confirmed it.
When I look back at my time at SAP, Sauce Labs and Tricentis, the decisions I got right were rarely the ones where I had the most data. They were the ones where I knew when to override the model or the roadmap and say: this isn't right, even though I can't fully articulate why yet.
In the agentic era, that instinct becomes the circuit breaker. The PM who can build great stuff needs an equally strong capability to shut it down. To look at a beautifully generated PRD or a compelling prototype and say: not this, not now.
The machine will always give you a next step. The leader decides whether to take it.
In engineering, "full stack" means working across the entire system. The Full Stack PM of 2026 means something analogous: the ability to move fluidly between the highest level of strategic intent and the lowest level of technical execution, without losing fidelity at either end.
This isn't about PMs becoming engineers. It's about eliminating the "altitude problem": the organizational fog that builds up between "what we are trying to achieve" and "what we are actually building."
Forty years ago, I was typing BASIC and Assembly code from magazines on a Commodore 64, learning to think computationally. Thirty years of Software and Quality Engineering taught me that the distance between what software is supposed to do and what it actually does is where all the real work lives. Today, that background isn't nostalgia. It's the lens through which I evaluate everything the AI produces.
Three decades in enterprise software taught me where buildings collapse. The agentic era is the first time both have mattered simultaneously at the senior leadership level.
The Feature Factory measured PMs by velocity. The Intelligence Factory will measure PMs by the quality of their judgment under conditions of abundance.
Anyone can approve features when everything is buildable. The leader's job is to create coherence. That requires something AI cannot generate on demand: a point of view earned through time, failure, and deep domain understanding.
The Full Stack PM isn't defined by the ability to build. That is table stakes now. They are defined by the ability to decide what's worth building, to communicate that decision with enough technical credibility that engineers trust the direction, and to shut down the machine when it's optimizing for the wrong thing.
Strategist. Builder. Circuit breaker.
That is the full stack.