The PM Who Can Build Is Now Table Stakes

I've been reviewing PM job descriptions lately, out of curiosity more than necessity, and the gap between what companies say they want and what will actually matter in 18 months is striking. Strong communicator. Stakeholder alignment. Data-driven decision making. Experience with agile methodologies.

These aren't wrong. They're just increasingly insufficient. And the companies still optimizing for them are about to find out the hard way.

The bar moved. Again.

I recently wrote about the Full Stack PM: the product manager who can operate across the full depth of the creation process when needed. Not a developer, but someone who can build working artifacts, compress the feedback loop between insight and execution, and show up to an engineering conversation as a co-creator rather than a translator.

At the time, that felt forward-looking. A trajectory, not a requirement.

"Vibe coding", using natural language prompts with AI tools like Cursor to generate functional code, changed the timeline. What used to require months of deliberate skill-building, learning enough to prototype, read code, or have an informed opinion about technical tradeoffs, now has a much lower entry point. The tools moved. Which means the expectation moves with them.

The Full Stack PM is no longer an edge case worth celebrating. It's the new baseline.

What "able to build" actually means now.

Let me be precise here, because this gets misread, and I am not advocating for "Shadow IT."

The goal is not for PMs to ship production code that engineering will have to maintain later. That's how technical debt spirals. The goal is the fastest path to evidence. The Full Stack PM isn't just a coder; they are an architect of validation.

I'm saying every PM needs to be able to externalize their thinking into something tangible without waiting for engineering capacity to do it for them. A working prototype that proves (or disproves) the hypothesis. A functional mockup that clarifies a user flow. A data pipeline that answers the question they've been waiting three sprints to get engineering to prioritize.

With agentic tools, that capability is within reach of anyone with clear thinking and product instinct. The technical barrier is no longer the constraint. Which means the PMs who still use "I'm not technical" as a reason to stay upstream of execution are making a choice, not describing a limitation.

The distinction matters. And hiring managers are starting to notice it.

The interview question nobody is asking yet.

Here's the tell. When you interview a PM candidate today, you probably ask about their process for prioritization, how they handle stakeholder conflict, what metrics they owned and how they moved them. All legitimate.

But here's the question almost nobody is asking: "Walk me through the last time you built something yourself to prove a point. What did the artifact reveal that the spec couldn't, and did you have the discipline to kill the idea if the prototype failed?"

The candidates who have a crisp answer to that question are operating at a different level. They've already internalized that execution is part of thinking, not downstream of it. They don't wait for permission or capacity. They make the thing, learn from it, and know when to let it go.

That instinct used to be rare. It's becoming trainable. Which means the PMs who don't develop it are going to look increasingly slow next to the ones who did.

What this means for hiring managers and CPOs.

If you're building a product team right now, your job descriptions are probably lying to you. Not intentionally, but structurally. They're optimized for the PM who succeeds in the current system, not the one who will define the next one.

The signals worth screening for have changed. You cannot afford to hire passengers; you need drivers. Can this person move from insight to artifact without a handoff? Do they have opinions about implementation, not just outcomes? Have they shipped anything, even something small, on their own initiative?

These aren't trick questions or extra credit. They're the new table stakes. The PMs who can answer them are going to compress your feedback loops, reduce your dependency on engineering capacity for early-stage validation, and show up to product reviews with evidence instead of slides.

The uncomfortable implication.

If you're a PM reading this and feeling some friction, that's useful information. Not a verdict, but a signal worth taking seriously.

The agentic era doesn't require you to become an engineer. It requires you to stop treating "I can't build it" as a permanent fact about yourself rather than a gap worth closing. The tools are better than they've ever been. The learning curve is shorter than it's ever been. The competitive cost of waiting is higher than it's ever been.

I spent 30 years watching the abstraction layer move up and the builder population expand every time it did. The PMs who figured out how to use the new floor as a launching pad, rather than a threat to their identity, were the ones who kept compounding.

That's still the move.

What are you screening for when you hire PMs today? I'm curious whether others are seeing this shift in the room yet.