The rise of product engineering
In December 2025, Large Language Models crossed a significant threshold. They became good enough to carry the median software engineering task to acceptable quality. According to METR, in Feb-Apr 2026 developers have reported a median productivity increase of 2x. With some outliers reporting between 10x and 20x. A paradigm shift that has been acknowledged by Andrej Karpathy too.
Three observations follow as the industry adapts to this new reality:
- The unit of work has grown: Software developers used to execute tasks within a specific tech stack, turning product specifications into code. Today, they are increasingly asked to take more ownership, either horizontally like covering more technical ground such as system design and architecture, or vertically like owning product features end-to-end. “Write this function, fix this bug” is being absorbed by the model. The unit of work moved one level up the stack: deciding what the feature is, why it exists, how it fits, and how the system architecture around it should be designed.
- The cost of coordination starts to exceed the cost of building: When building was expensive, the cost of coordination was collateral. With building compressed, coordination becomes the expensive bottleneck. See Andrew Ng slide on Stanford CS230 | Lecture 9: Career Advice in AI. In our view, Cost of Coordination = the time spent on meetings + the time lag between decision and execution + the cost of loss opportunity witnessed during this time.
- As a result, team topologies are reorganizing: Smaller teams with broader scope produce more coherent output at a faster pace compared to larger groups with narrow scope.
The persona emerging from this shift is the product engineer: someone who can hold a product question and a technical question in the same head, that can orchestrate agents under both lenses, and that can learn and adapt quickly to the continous shifts in customer demand and technology landscape.
Product
The ability to think on behalf of the customer and translate their needs into product heuristics and specifications.
Think like a Product Manager
Engineering
The ability to translate ambiguous product specifications into high-quality technical architectures and rich specifications, harnessing the speed of coding agents without sacrificing output quality.
Think like an Architect and CTO
This rearrangement is creating new problems the industry is still figuring out.
How do you hire product engineers? How do you train such roles? How do you measure success? What steps should you take to reorganize your teams? How do you partition and distribute ownership and execution now that the unit of work is larger?
Most importantly, what tools and agentic workflows do you need to empower product engineering at scale? How do you coordinate intent efficiently while minimizing the cost of coordination? How do you maintain trust and accountability in a world where the output of product engineers is increasingly agentic?
Quality drifts when multiple agents ship in parallel without a shared sense of intent. Scope creeps because building is cheap. Quality assurance and functional testing require a completely new approach to cover the increased output without losing customer trust. Cat Wu (Head of Product, Claude Code) names this directly in her Lenny’s podcast interview: “What gets sacrificed when you ship so fast”.
We observed that the tools already existing in the industry have been built to serve workflows of the past and require significant transformation to serve workflows of the future, the agentic workflows. They have been excellent at helping teams coordinate small units of work. They are largely becoming obsolete as coordination has moved a few layers up and accelerated significantly in speed and volume of information.
Coordination has moved from "how" to build to "why" and "what" to build.
Productmind is our hypothesis on how to close that gap. We believe the product engineer needs a centralized product mind: a system that can learn from customers, remember why a feature exists, who asked for it, what shape it should take, and how it connects to everything around it.
Context that should be maintained and packaged to ground coding agents and increase their output and consistency at scale, while allowing Product Engineers to keep full control and accountability. Speed at 10x is also drift at 10x, unless quality and intent are held with the same care.
We have a long list of assumptions we are committed to validate. We will keep publishing what we learn, what holds, what we got wrong, and what surprised us.
If our thoughts resonate with how your own work is changing, we would like to hear from you.
Book a demo and join the beta!
