Skip to main content
Product/ ·6 min read

Put Craft Back Into the Center

Product Craft /Product Strategy /AI /Leadership

There is something wrong with the way we ship software. Not the speed. The speed is fine. The problem is what we leave behind.

Every product I have worked on has a graveyard of half-finished features. An onboarding flow that was “good enough for launch” three years ago and never got revisited. A notification system that technically works but frustrates users in twelve subtle ways nobody prioritized fixing. A dashboard that answered the wrong question because the team pivoted before validating the right one.

This is not a bug in any specific team. It is the logical outcome of how the industry has operated for fifteen years. Ship fast, validate early, move to the next thing. The MVP became a philosophy, then a habit, then an excuse.

And now something is changing. Not because the industry had a moment of reflection. Because AI is rewriting the math underneath the whole approach.


The MVP bargain

The original idea behind the Minimum Viable Product was sound. Build the smallest thing that tests your riskiest assumption. Learn from real users. Iterate based on evidence.

You know what happened. “Minimum viable” became the default quality bar — not for the experiment, but for the product. Teams shipped MVPs as learning vehicles. The numbers looked decent enough. Leadership moved them to the next priority. No one went back to finish them.

This was rational. Validation was expensive. Building a fully realized feature took months. Why spend three months polishing something the market might reject? Better to test with the rough version and invest only when you have proof. The trade-off between scope and quality was real.

But it had a cost that compounded quietly.

The MVP cycle: features enter as experiments and rarely return for polish


The cost nobody tracked

Product debt is the term, but it undersells the problem. Technical debt has a clear mechanism: shortcuts in code that slow future development. Product debt is subtler. It is the accumulated weight of features that work but do not work well.

For more than half of companies, technical debt alone accounts for over a quarter of their entire IT budget. Features that should take a week take three because they have to work around the rough edges of previous features that were never finished.

But the financial cost is not the worst part. The real cost is trust.

Users do not articulate product debt. They feel it. Every interaction with an unpolished feature erodes confidence. Not dramatically. One papercut at a time. The notification that arrives too late. The setting that does not quite do what the label says. The workflow that requires four clicks when it should require one.

Over time, these papercuts become the product’s identity. Not in the pitch deck. In the user’s muscle memory. They learn that this product is “fine.” Functional but not a pleasure. They stay until something better comes along. They do not recommend it.

Product debt compounding: small quality gaps accumulate into user trust erosion


What actually changed

Two things happened at roughly the same time. Both are consequences of AI, but they affect different parts of the product development cycle.

Building got cheaper — including what you build to validate. AI-assisted development compresses the implementation cycle. Stanford research shows AI generates code 30-40% faster, and that number keeps climbing as agents improve. Prototyping tools can generate interactive mockups from descriptions. You can put a realistic version of a feature in front of users before writing a line of production code. The thing that used to take weeks — building the artifact you test with — now takes hours.

But here is the distinction that matters: building the test vehicle got cheap. Validation itself did not. Sitting with customers, observing their behavior, understanding what they actually need — that is still human work. It still takes time. AI does not compress that. What AI does is compress everything around it. When you are not spending all your time building, you can spend more of it with the people you are building for. A product leader I work with put it this way: with a good team he used to spend 50% of his time with customers. Now he can spend 70% or more. That is not faster validation. That is deeper validation.

This matters because the original MVP bargain was built on constrained capacity. “We cannot afford to build the full thing before we know it works, so we build the minimum thing.” When building is fast and you have more time for customer proximity, that bargain loses its force. You can validate more thoroughly, earlier, with more confidence. By the time you commit to building, you have real conviction that the feature deserves real investment.

Put those two things together and the math changes. You are not choosing between “build ten rough things and see what sticks” and “build two polished things and hope.” You can build test vehicles cheaply, spend real time with customers to develop conviction around the best ideas, and then invest in building them well.

The old trade-off between breadth and depth collapses. Not because you have infinite resources. Because the cost structure shifted underneath it.

The old trade-off vs. the new economics


Speed is the new baseline

Here is the thing about faster shipping. Everyone gets faster at the same time. When your competitors also use AI coding agents, your speed advantage disappears. Shipping quickly is no longer a differentiator. It is a prerequisite.

Hubert Palan, the CEO of Productboard, said it plainly: “The reason most products suck is not because we are not able to ship fast. Agents are helping us ship faster than ever before. It is because we are not shipping the right things.”

ISHIR, a product consultancy, put it more bluntly: “Users are no longer comparing your product to similar tools. They are comparing it to the best experience AI can deliver.” And: “Iteration speed is no longer impressive. It is expected.”

If speed is table stakes, what differentiates? The quality of what you ship. The craft.

This is not a vague aesthetic argument. Stripe upgraded the typography, layout, and imagery of a single email and saw a 20% increase in product conversion. Their checkout experience, obsessed over for fourteen years, increases business revenue by 11.9% on average. You might think that only works for consumer-facing products with a design-famous brand. But Linear built a $1.25 billion business on craft in the B2B project management space — one of the most commoditized markets in software. They spent $35,000 on marketing in their entire lifetime. The product did the rest. Craft measured in dollars.


The companies already operating this way

A few teams figured this out early. They are not waiting for AI to push them. They already chose craft as strategy. But AI is accelerating the returns.

Linear runs what they call “polishing seasons.” The entire team pauses feature development to refine existing functionality. Their CEO, Karri Saarinen, calls it “taste-driven development.” Quality is Linear’s first principle. Every other decision flows from that. The product is the marketing because the product is crafted.

Stripe operationalized craft through a practice Katie Dill calls “walking the store.” Multidisciplinary teams use the product end-to-end like a customer. They run friction logs. They track fifteen essential user journeys quarterly and review them in product quality QBRs. Dill makes a useful distinction: “Craft is about the how. The thinking, work, and mastery that goes into creating something. Quality is often the output of that process.”

Brian Chesky restructured Airbnb around this principle. He scrapped A/B testing. He stayed in the details of product decisions rather than delegating them through layers of product management. His reasoning: “Metrics are not a strategy. A strategy is not growing.” He launched curated, opinionated experiences instead of testing his way to mediocrity. “There has to be a sense of craft. Obsessing over every single detail.”

These are not small indie teams with the luxury of perfectionism. These are companies operating at scale, choosing craft deliberately, and winning because of it.


What this means for how we build

The shift is not “move slowly and be precious.” It is the opposite. Move fast where speed helps. Compress validation. Compress boilerplate. Let AI handle the plumbing, the scaffolding, the repetitive implementation work. And then spend the time you saved on the parts that matter. The interaction details. The edge cases. The moments where a user goes from “this works” to “this is good.”

Soren Kaplan wrote in Inc. that with AI, you can “build and ship the real thing faster, with full functions, and have it look beautiful and be fully scalable” in less time than it used to take a traditional team to create wireframes. That is not an argument for moving slowly. It is an argument for raising the bar on what you ship.

The craft argument and the speed argument are not opposites. They are the same argument. AI gives you speed. The question is what you do with it. Use it to ship more half-finished features, faster? Or use it to ship fewer things, finished?

I have been experiencing this in my own work. Last month I built a client prototype — an interface with real data, working interactions, responsive layout. The kind of thing that used to take a week of focused implementation. It took a day. Not because the AI wrote perfect code. Because it handled the scaffolding, the boilerplate, the repetitive layout work. What I got back was not speed. It was capacity. I spent the rest of that week on the details I would normally have cut: refining the micro-interactions, testing edge cases with real data, polishing the transitions until they felt intentional rather than functional.

That capacity is new. I used to choose between “ship it rough on time” and “finish it properly and slip the deadline.” Now I do both. And it changes how I think about what quality means in practice.


The principle underneath

AI removes the excuse for unfinished products. Not the reason. The excuse.

The reason products shipped unfinished was always a combination of incentives, priorities, and organizational habits. AI does not fix those. But it eliminates the most common justification: “We do not have time to do this properly.”

When validation is cheap and building is fast, “we do not have time” stops being credible. You have the time. The question is whether you choose to spend it on craft or on volume.

That choice is what Part 2 is about.


In Part 2, I dig into why faster tools do not automatically produce better products, the organizational conditions that make craft possible, and what it actually looks like to choose quality over volume when the pressure is always to ship more.


Sources and further reading:

  • Soren Kaplan, “AI Means You Don’t Need a Minimum Viable Product,” Inc. (Nov 2025)
  • Hubert Palan, “Product Craft When AI Changes the Stakes,” Productboard Blog
  • Karri Saarinen, “10 Rules for Crafting Products That Stand Out,” Figma Blog
  • Katie Dill, “How Stripe Crafts Quality Products,” Creator Economy
  • Brian Chesky, Config keynote, Figma Blog
  • “Taste Is the New Bottleneck,” Designative (Feb 2026)
  • Aakash Gupta, “The Complete Guide to Product Craft in the AI Era,” Product Growth
  • Linear polishing seasons, Michael Goitein / Substack
Ole Harland

Ole Harland

Product designer in Hamburg with 15+ years designing complex platforms. Currently exploring AI as a design and build tool.