Fifteen months ago, I wrote a piece for Revolv Signal called "When AI Speeds Up Engineering." The argument was simple: when AI lowers the cost of building, it exposes the parts of product development that were never really about code. After fifteen months building Revolv, I believe that even more strongly now.
AI is changing software. That part is obvious. The more important shift is what it is doing to the people, workflows, and decisions around software. Product, engineering, and design are still distinct disciplines. But the old boundaries are under pressure. The old sequence is, too.
For years, most teams worked in a familiar pattern. Product defined requirements. Design translated them into interfaces. Engineering implemented the system. The structure made sense because writing production software was expensive, coordination was slow, and mistakes were costly. That logic is weakening fast.
Coding agents can now turn an idea into working software in hours. Sometimes minutes. A rough prototype used to require real organizational effort. Now one capable builder can get surprisingly far with a prompt, a component library, and decent judgment. That changes the economics of the work. And when the economics change, the org chart is never far behind.
The Bottleneck Has Moved
The hardest part of building Revolv was rarely getting code on the screen. The harder questions showed up earlier and lasted longer. Should this feature exist? Does it solve a real problem or just create activity? How does it fit with the rest of the product? What happens when this decision compounds across ten other decisions?
AI makes first drafts cheap. It does not make judgment cheap. That is the shift.
Software teams spent years optimizing around implementation. Today, implementation is getting cheaper while review, coherence, and product judgment are getting more expensive. Teams can generate more options than they can responsibly absorb. Prototypes multiply faster than decisions do.
At first, this feels like speed. Then it starts to feel like load.
PRDs Are Not Dead. Their Job Has Changed.
There is a fashionable line right now that PRDs (Product Requirements Documents) are dead. That is directionally true, but incomplete.
The old PRD as the center of gravity is fading. A static document no longer needs to sit upstream of every meaningful product decision. Working prototypes now carry more weight because they make the conversation concrete. They show tradeoffs faster. They expose bad assumptions earlier.
But intent still has to travel. Review still needs context. Teams still need to know what is deliberate, what is provisional, and what problem the feature is meant to solve. That means some version of a requirements document still matters. It just no longer has the same form or status.
In practice, the new artifact may be shorter. Sharper. More executable. It may include prompts, system maps, prototype links, user flows, and a few lines of precise reasoning rather than pages of procedural detail. Long live product requirements. Just in a different form.
The Most Valuable People Are Expanding Their Range
One thing became clear while building Revolv: the people with the most leverage are the ones who can move across product, design, and technical execution without waiting for a meeting to translate the problem for them.
That does not mean specialization disappears. It means the burden of proof for specialization gets higher.
Generalists are becoming more valuable because coordination is now more expensive, relative to execution, than many teams realize. A builder who understands user behavior, has taste in interface decisions, and can work effectively with coding agents can compress days of back and forth into a single cycle of thinking and making.
This is one reason the balance of power is shifting. The winners will not be the people who cling hardest to role boundaries. They will be the ones who can hold more of the system in their head.
Product Sense Is Becoming the Scarce Resource
In the old model, weak ideas often died from friction. They took too long to spec, too long to design, and too long to build. That protection is gone.
Now weak ideas can arrive fully formed. They can look credible. They can even work. Once they exist, they create momentum. Someone says it is already built. Someone else says maybe we should just ship it. A mediocre feature that once would have died quietly now consumes review cycles, design energy, and roadmap attention.
That makes product sense the scarcest resource on a modern product team. Not because product managers suddenly matter more than everyone else. They do not. It matters because every function now needs stronger judgment about what deserves to exist. Engineers need it. Designers need it. Founders need it. PMs need a lot more of it than before because the cost of bad judgment is no longer delayed by the cost of implementation. I wrote about this gap between adoption and actual impact in "AI Is Everywhere in Business. Its Impact Isn't." The pattern is the same: organizations move faster than their judgment systems can absorb.
Cheap execution raises the price of sloppy thinking.
Two Archetypes Are Emerging
Across modern product teams, two archetypes are starting to stand out.
The first is the builder. This person can move from idea to prototype quickly. They are comfortable using coding agents. They can reason across user need, workflow, interface, and implementation constraints. They do not need to master every layer, but they do need enough fluency to create momentum.
The second is the reviewer. This person sees the second-order effects. They understand architecture, product coherence, usability, scaling, and operational risk. They protect the system from local decisions that look smart in isolation and create problems in aggregate.
Most strong teams will need both. But the ratio is changing. AI expands the surface area of what can be built, which means the value of great review rises right alongside the value of fast building.
Where the Leverage Concentrates
If I step back from the last fifteen months, three roles look especially central in this next phase. Product thinkers, because someone still has to decide what is worth building and why. Data and intelligence engineers, because AI products are only as strong as the infrastructure, retrieval, orchestration, and data quality underneath them. Creatives and designers, because intelligence without interface is useless. Trust, usability, and adoption live in the experience.
These are the three power players because modern software is becoming a three-body problem. Judgment. Intelligence infrastructure. Human experience. And sitting above all three is one capability that matters more with every passing quarter: systems thinking.
Systems Thinking Is the Advantage
This was true before AI. It is just much easier to see now. I explored this idea in depth in "Stop Chasing Greatness. Start Building the System." The argument holds: greatness is a system outcome, not an individual act.
In engineering, systems thinking means understanding how services, data, dependencies, reliability, and scale fit together. In product, it means understanding how decisions accumulate, how features interact, and where complexity should live. In design, it means understanding how interface choices shape behavior, trust, and comprehension over time.
When execution was expensive, organizations could confuse effort for rigor. You could spend weeks building something and mistake the process for quality. That cover is disappearing.
AI is stripping the insulation away. It is making it painfully obvious which teams are coherent, which ones are fragmented, and which leaders can actually see the whole board.
What Building Revolv Made Clear
Building Revolv over the last fifteen months has reinforced something I suspected when I wrote "When AI Speeds Up Engineering." The real story is larger than engineering.
AI is compressing the distance between idea and software. That sounds like an engineering story. It is really an organizational one. As execution speeds up, companies are forced to confront the parts of product development they used to hide inside process: unclear thinking, weak prioritization, fragmented context, and shallow review. That is where the real pressure is now.
This is also why I believe the future belongs to teams that can think across functions instead of defending them. The competitive edge will come from better judgment, tighter feedback loops, stronger architecture, and clearer product sense. Code still matters. Deep craft still matters. But the advantage is moving up the stack.
AI did not remove the hard part. It exposed it.
And for product teams, that may be the most important shift of all.
