Karri Saarinen, the founder and designer behind Linear, published a piece recently that I keep returning to. His core argument is that the cost of building a feature is falling rapidly, driven by AI tooling, faster prototyping, and more capable engineering infrastructure. But the cost of carrying a feature, maintaining it, supporting it, integrating it, letting it shape the product surface over time, stays constant or even increases.
That asymmetry is the one I want design leaders to sit with, because it reshapes what our role actually is in a product organization.
For most of the last decade, the bottleneck in product development was execution speed. How fast can we ship? How many story points can we clear? How quickly can we get from concept to production? Design’s value was often measured in terms of how well it reduced friction in that pipeline: clear specs, clean handoffs, fewer rounds of revision. And that work matters. But when AI compresses the execution timeline even further, the pipeline speeds up and the carrying costs compound faster. Every feature you ship is a feature you now maintain. Every surface you add is a surface your support team has to understand. Every new capability is a new thing that can break, that needs documentation, that complicates onboarding.
Our role has always been to advocate for coherence over accumulation. In an environment where building is nearly free, that becomes the most important question in the room.
This is where design leadership becomes most valuable, and most misunderstood. We are the ones who are supposed to ask whether this thing deserves to exist, whether it earns its complexity, whether it makes the product simpler or just more capable. That question has always been important. In an environment where building is nearly free, it becomes the most important question in the room.
What this looks like in practice
At my company, we are in the middle of a quarter where leadership has explicitly asked every team to create leverage, to get more output from the same resources, to ship proof points rather than experiments. The instinct in that environment is to build more, faster. And some of that is right. But the design org’s job in that sprint is to be the counterweight that asks: of the ten things we could build this quarter, which three will still matter in eighteen months? Which ones reduce complexity rather than adding it? Which ones make the next quarter’s work easier instead of harder?
That is not a slowing-down argument. It is a compounding argument. The teams that ship the right three things this quarter and maintain them well will outperform the teams that ship ten things and spend the next two quarters cleaning up the surface area.
Saarinen’s framing gives design leaders sharper language for a conversation we have been having intuitively. When someone proposes a feature, the question is no longer just “can we build it?” or “should we build it?” The question is: what does it cost to carry this, and is that cost worth the outcome it produces? If you can answer that honestly, you are doing the work that matters most.