Should This Spec Even Exist?
Product Strategy in the Age of Reasoning Machines
In Clarity Is the New Bottleneck, I built a 3D physics simulation with no experience in the underlying tech and discovered the hard part wasn't getting to working code. The hard part was defining what "working" meant. In What DevOps Already Knew, I argued that you should make sure the bottleneck stays where Gene Kim said it belongs: the speed of ideas, not trapped behind infrastructure and process.
Both of those posts were circling the same idea. DevOps moved the delivery bottleneck up the stack. AI is now doing doing the same thing to product work. When implementation is cheap and the delivery system is well structured, the real constraint becomes knowing what to build.
But much of the current conversation about creating with AI is looking for that clarity in the wrong place.
The "Product Engineer" Moment
Over the past few months a phrase keeps resurfacing in engineering circles: product engineer.
The argument goes something like this: AI tools generate working code so quickly that implementation is no longer the bottleneck. If writing software gets easier, engineers need to think more about product and design. Engineers who can move fluidly between those concerns become “product engineers.” Jampa Uchoa's essay on one-pizza engineering captures the trend well.
The observation behind this idea isn’t wrong. A single person with AI tools can now prototype and ship systems that used to take a team and months of coordination. When that happens, a traditional product handoff starts to look like friction. If a product manager is still translating ideas into specifications for engineering to implement, they’re now the slowest part of the pipeline.
From that perspective, the conclusion seems obvious: engineers should absorb that translation layer themselves and run the interface between product thinking and implementation directly.
The Product Work Engineers See
When engineers talk about “thinking like a product manager,” they usually mean the work closest to engineering: writing specs, clarifying requirements, translating customer feedback into tasks, deciding between technical approaches, scoping features.
I see this firsthand. I am interviewing heavily right now, and this is exactly what people ask about. How do I decide what goes into a PRD? How do I turn customer feedback into engineering work? That I am still getting those questions makes sense. The shift in the software development lifecycle is still very new. But what has changed is how little of that work now requires human effort.
Once a problem is framed clearly enough, with a clear goal, real constraints, and meaningful success criteria, tools like Superpowers cut the time to a valid specification, plan, and task breakdown to hours or even minutes. The translation step that once required hours of writing, meetings, and iteration is now happening within the tool.
What goes into the spec isn’t why you hire a product manager. Not anymore. The reason you hire a product manager is to answer a much more important question:
Should this spec even exist?
The Work Before the Spec
Someone has to decide which problems deserve to be on the roadmap at all.
That means understanding which customer problems need solving right now. It means knowing how those problems connect to the broader direction of the product and the business. It means saying no to the twelve things that are technically feasible and interesting but strategically irrelevant.
By the time a problem reaches a spec document, upstream decision-making has already shaped what the team is allowed to even consider.
Engineers rarely see this work. From where they sit, the problem appears to have arrived fully formed. In reality, someone fought for it, traded it against five other priorities, and connected it to a business outcome that justified the investment.
A Framework for Where Decisions Live
Melissa Perri's Escaping the Build Trap describes product strategy as a stack of connected decisions, each answering a different question about direction, customers, and execution. Each layer ensures that what teams build connects to the outcomes the business actually needs.
(If the shape of this diagram looks familiar, it should. DevOps taught us that bottlenecks move upward in systems as we remove constraints. The same thing is now happening in product work.)
Claude Code and similar tools dramatically accelerate the bottom of this stack. Generating product options is suddenly trivial. Prototypes appear overnight. Experiments that once required planning cycles now happen casually between other work. From an engineer's perspective, that change is obvious. The part of the product process they interact with most often, the translation layer between idea and implementation, gets easier every month.
But the layers above that stack are what actually determine success.
Which problems matter? Which customers matter? How does this connect to where the business needs to go? The real leverage of product work sits higher up. And because the cost of building is dropping just as fast for your competitors, the importance of choosing the right problems only increases.
The shift engineers are reacting to is real. But the version of product thinking they're adopting lives mostly at the bottom of the stack, the part AI is eating the fastest. The real leverage of product work sits higher up.
What Comes Next
Over the next few posts, I’m going to unpack this stack, starting with the layers AI has changed the most: product initiatives and product options.
Clarity Is the New Bottleneck is a story about what happens when you can build anything and the hard part is defining what “done” means. What DevOps Already Knew is about making sure infrastructure doesn't re-bottleneck you before you reach the strategic layer. From here, we move upward to the decisions that determine whether all this new building power creates value or just lines of code.
As engineers start looking up the stack, product managers will have to make the strategy behind those decisions legible.