Product/ ·5 min read
Craft Is a Leadership Decision, Not a Resource Problem
Product Craft /Product Strategy /AI /Leadership
This is Part 2. Part 1 covers how AI changed the economics of product development and why the excuse for half-finished products no longer holds. This piece is about why the shift will not happen automatically.
Part 1 ended with a claim: AI removes the excuse for unfinished products. That is true. But it does not mean products will get better.
There is a pattern in economics called the Jevons Paradox. When coal engines became more efficient, coal consumption did not go down. It went up. Efficiency made coal cheaper, so people used more of it. The savings were absorbed by volume, not quality.
The same dynamic is already playing out with AI-assisted development. Teams that shipped five features per quarter with rough edges are now shipping fifteen features per quarter with rough edges. The tool got better. The output got bigger. The quality stayed the same.
If you have worked in product for any length of time, this is not surprising. Tooling has never been the bottleneck for quality. Organizational incentives have.
The pressure paradox
Here is how it typically plays out. A team adopts AI coding agents. Velocity goes up. Two things happen almost immediately.
First, the team notices they are shipping faster. This feels good. There is a genuine moment where people think: we could use this extra capacity to polish what we have. To go back and finish the onboarding flow. To fix the notification system. To make the dashboard actually useful.
Second, leadership notices the team is shipping faster. And leadership’s instinct is not “great, now polish.” It is “great, now take on more scope.”
The surplus gets absorbed. Not by craft. By ambition. By roadmap expansion. By “since we are ahead of schedule, let us also do X.” The treadmill speeds up. The quality bar stays exactly where it was.
This is not a failure of leadership character. It is a structural incentive problem. Most companies measure output, not outcome. Shipped features, not finished features. Velocity, not craft.
Why craft does not happen by default
There are at least three structural forces working against it.
Incentive alignment. In most product organizations, shipping a new feature is more visible and more rewarded than finishing an existing one. A new feature gets a launch, a demo, a mention in the all-hands. Polishing the notification system gets nothing. It is invisible work. The incentive structure treats “new” as progress and “better” as maintenance.
Planning horizons. Quarterly planning cycles favor breadth. If you have twelve weeks, the temptation is to fill them with new commitments. Going back to finish something from two quarters ago does not feel like progress. It feels like admitting you should have done it right the first time. That admission is organizationally uncomfortable.
Measurement gaps. Most teams do not measure product quality in a way that creates accountability. They measure throughput, adoption rates, and maybe satisfaction scores. But satisfaction scores are lagging indicators. By the time they drop, the product debt has been accumulating for quarters. There is no equivalent of code linting for product craft. No CI check that fails when the onboarding experience is mediocre.
These are not new problems. They predate AI by decades. But AI makes them more consequential. When the production capacity is unlimited, the question of what to produce with it matters more than ever.
This is the default outcome
If you have been in this industry long enough, you have seen this pattern before. Every productivity gain gets absorbed by scope expansion. Agile was supposed to create space for quality through shorter feedback loops. Instead it became a velocity optimization machine. CI/CD was supposed to let teams ship with more confidence. Instead it let teams ship more things with the same confidence. The tools get better. The output gets bigger. The quality stays flat.
Marty Cagan has spent years arguing that the bottleneck in product development is discovery, not delivery. Most teams ship the wrong things, not too few things. If AI accelerates delivery, it does not fix the discovery problem. John Cutler’s “feature factory” critique gets worse, not better, when the factory runs faster.
So here is the uncomfortable truth: for most teams, AI will make products worse. Not because the tools are bad. Because faster tools amplify existing incentives, and existing incentives reward volume.
The Jevons Paradox describes a default. Not an inevitability. But you have to be honest about how strong the default is before you can talk about overriding it.
The companies I described in Part 1 (Linear, Stripe, Airbnb) all share one thing: they made an explicit organizational decision to prioritize craft. It was not accidental. It was not a side effect of having talented people. It was a structural choice embedded in how they plan, measure, and reward work.
Linear’s “polishing seasons” are not optional. They are scheduled. The entire company stops building new features and refines existing ones. This is a leadership decision that costs real roadmap capacity. Saarinen made the choice because he believes quality compounds. The ever-widening gap between a polished product and a rough one becomes harder for competitors to close over time.
Stripe measures quality through friction logs and product quality QBRs. This is not a cultural aspiration. It is an operational process. When you track fifteen user journeys quarterly and review them in a structured meeting, quality becomes accountable. It has a mechanism. It has an owner. It has a cadence.
Chesky restructured Airbnb’s entire product organization to enable craft. He removed layers between himself and the product details. He replaced A/B tests with opinionated decisions. That is not a process improvement. It is a governance change.
Each of these is a leadership decision. Not a tooling upgrade.
The mechanism: conviction enables craft
There is a specific causal chain between AI and craft that is worth spelling out. It is not “AI makes us faster, therefore we make better things.” That is the version the Jevons Paradox breaks.
The actual mechanism is:
AI compresses building, which frees time for customers. You prototype faster. You synthesize research faster. You put realistic versions in front of users before writing production code. But the real gain is not that validation gets faster. It is that you can spend more time on the part of validation that actually produces conviction: proximity to the people you are building for. When building takes less time, customer time expands. You go from spending half your week at a desk constructing test artifacts to spending most of it with users, observing, listening, understanding.
More customer time produces stronger conviction. When you have spent real time with users — not just run a survey or checked analytics — you are not guessing. You know. Not with certainty. But with the kind of confidence that comes from understanding the problem deeply, not just measuring its symptoms.
Conviction unlocks the willingness to invest in craft. This is the key step. Nobody polishes something they are not sure will survive. The reason features ship rough is often not time pressure. It is uncertainty. Why spend two extra weeks perfecting an interaction if you are not sure the feature will be kept? Better to ship it rough, check the numbers, and decide later.
There is a related problem: even when conviction exists, it often does not survive team transitions. The team that built v1 moves on. The team that inherits the feature does not have the original rationale, the user research, the design intent. They cannot finish it properly because they do not know what “finished” was supposed to look like. Context loss kills craft as effectively as lack of conviction. When product decisions, design rationale, and constraints live in a persistent layer that both humans and agents can read, continuity survives the transition. You can finish what you remember starting.
When AI collapses the validation cycle and preserves the context that produced conviction, teams arrive at craft faster. Permission to say: this feature is going to matter. Let us build it properly.
What choosing craft looks like in practice
It is less about grand strategic declarations and more about specific operational choices.
Polishing seasons. Dedicating scheduled time to refining existing features rather than building new ones. Linear does this. It requires leadership willing to leave roadmap items on the table in favor of quality improvements to things already shipped. This is harder than it sounds, because every quarter has more ideas than capacity.
Quality rituals. Regular, structured review of the user experience. Friction logs, journey reviews, product quality QBRs. Not user research in the generative sense. Evaluative practices that ask: is this good? Not “does this work,” but “is this good?” The distinction matters. Something can work and still be mediocre.
Finishing before starting. A simple rule: do not start the next thing until the last thing is done. Not “shipped.” Done. Polished, documented, edge cases handled, feedback addressed. This is the hardest operational change because it directly conflicts with the urge to move to the next exciting problem.
Saying no more often. When AI gives you the capacity to build everything on the roadmap, the discipline shifts from “what can we afford to build” to “what is worth building well.” The answer is always fewer things than you think. Aakash Gupta frames this as “subtraction over addition.” Craft is as much about what you leave out as what you put in.
Measuring craft. You need metrics or at least practices that make quality visible. Stripe’s fifteen tracked user journeys. Linear’s polishing season outputs. Something concrete that says: the product got better this quarter, not just bigger.
The honest version of the argument
AI does not put craft back into the center. AI puts craft back on the table.
For fifteen years, “we do not have time” was a legitimate response to anyone advocating for more polish, more attention to detail, more finishing. The trade-offs were real. Resources were genuinely constrained. Choosing craft meant choosing less scope, and scope often won because the business demanded it.
AI collapses that constraint. Validation is fast. Building is fast. The time exists.
But time is necessary and not sufficient. Craft also requires taste. The ability to look at something functional and say “this is not good enough yet.” That judgment does not come from AI. It comes from experience, exposure, and caring. Guillermo Rauch at Vercel talks about “exposure hours,” deliberately spending time with great products to calibrate your sense of quality. That is a human practice.
Craft also requires courage. Choosing fewer features, better finished. Telling leadership that this quarter’s output is three things instead of eight, but those three things are genuinely good. That is a conversation most product teams avoid.
And craft requires organizational support. Incentives that reward quality. Rituals that make quality visible. Leaders who stay in the details. Without these, the Jevons Paradox wins every time. The surplus gets absorbed by volume. The products get bigger but not better.
Here is what happens to the teams that do not make this choice. They ship fifteen features a quarter instead of five. Each one is roughly as unfinished as before. But now a competitor ships three features a quarter, and each one is genuinely good. Users switch. Not because of a feature gap. Because of a quality gap. Because one product feels like someone cared and the other feels like a factory. The irony is brutal: the team that shipped more ends up with less.
The strongest version of this argument is not “AI will make products better.” It is: AI makes it possible to make products better, and it will punish the teams that do not.
The excuse is gone. The surplus exists. Where it flows is the only decision that matters.
Sources and further reading:
- Marty Cagan, “Inspired” and SVPG on discovery vs. delivery, svpg.com
- John Cutler on the feature factory problem, cutlefish.substack.com
- Guillermo Rauch on “exposure hours” and taste, Lenny’s Newsletter
- Dan Luu on tooling vs. organizational incentives, danluu.com
- Salvatore Tirabassi, “Move Fast and Build Things,” Substack
- “Why AI Is Exposing Design’s Craft Crisis,” UX Collective
- CTO Magazine on tech debt costs, ctomagazine.com
- Katie Dill on MVQP and Stripe’s quality practices, Lenny’s Newsletter
