AI Built the Ferrari. We Still Needed a Skateboard.

A hat tip to Eric Ries. I read The Lean Startup early in my career, and it became one of the most influential books in how I think about software. It also helped me sound smarter than I am in meetings for years.

What stuck with me was the discipline of building enough to learn, paying attention to what happened, and letting that change what we did next. Over time, I've watched teams keep the vocabulary while losing that discipline. We still say “MVP” and “feedback loop,” but we don't always mean much by them.

We call the first release an MVP without naming the assumption it needs to test. We ask for feedback, collect a list of feature requests, and return to the roadmap we already had.

AI makes this worth revisiting. We can ask for a small tool and quickly find ourselves reviewing a dashboard, an onboarding flow, and settings for features nobody requested. It looks like we got a Ferrari for the price of a skateboard. Now we have to work out which parts belong in the product and whether any of it helps the person we built it for.

We kept saying MVP

Martin Fowler has a name for what happens when a useful term spreads and its definition weakens: semantic diffusion. His article includes MVP being used to describe a $12 million first release as an example of the meaning turning into its opposite.

That describes something I've watched happen over the years. “Minimum” becomes whatever we can negotiate out of the backlog. “Viable” becomes whatever we can get through a demo. The learning part gets harder to find.

Ries's Lean Startup methodology puts the experiment at the center. It describes the MVP as a way to begin learning quickly, with actionable measurements that inform whether to continue or change course.

A release date doesn't tell us whether that happened. Neither does a busy feedback channel. We need to be able to point to an observation and explain what we decided because of it.

AI has made it so easy to build too much! We can mistake a finished-looking product for evidence that we’ve understood the problem. Every feature adds more to understand, test, and maintain, making it harder to tell what’s helping and what’s just noise. AI makes implementation cheap enough that those costs are easy to postpone, even as they grow.

The skateboard had a job

Henrik Kniberg's skateboard-to-car illustration is useful when we remember the problem underneath it: someone needs to get from A to B. Each usable version lets us learn more about that need.

Kniberg asks:

“What is the cheapest and fastest way we can start learning?”

He even suggests that a bus ticket might answer the question sooner. We might learn that the customer never needed us to build a car.

With AI, we can skip ahead to something that looks finished before we've had that conversation. The problem isn't that the generated interface looks good. It's that we can mistake its completeness for evidence that we've understood the problem.

The Ferrari in this metaphor is an appearance, not a performance claim. A polished screen tells us very little about authorization, failure recovery, or what happens when two people use it at once. It also tells us nothing about whether anyone will come back tomorrow.

More software gives us more to understand

I don't think building has become free. We still pay to understand, review, integrate, and operate what we create. AI can make the implementation step cheap enough that those other costs are easy to postpone.

Consider a hypothetical tool for routing customer-support messages. We want to find out whether categorizing incoming messages helps the team respond sooner. An agent can also build suggested replies, automated follow-ups, and a manager dashboard. Each feature sounds reasonable on its own.

But if the first trial includes all of them, what are we measuring? Did routing help, or did the team simply spend more time watching the new tool? Were the replies useful, or did someone rewrite them? Which part would users miss if we removed it?

A smaller trial is easier to interpret. Start with suggested routes that a person reviews. Record corrections and how much time review takes. Pay particular attention to urgent messages sent to the wrong queue. We can decide whether the routing earns a place in the workflow before adding automatic replies.

The Most Viable Version

I've been thinking about this as the Most Viable Version: the version we can stand behind within the time and resources we've chosen to spend.

That's my framing, not an established method. It asks us to take the capacity AI gives us and use some of it to understand and verify a deliberately limited product. AI makes it easier to build more. We still have to decide how much belongs in the first version.

Fowler makes a fair objection to new terminology. He favors recovering the meaning of the terms we already have:

“So my preference is to keep re-articulating the current terminology, pointing to those who understand the true meaning.”

Calling something a Most Viable Version won't fix a team that avoids learning. I use the phrase as a reminder to ask what makes this particular version worth putting in someone's hands. Ries's learning loop still applies.

This also fits how I use Shape Up's idea of appetite. Decide how much the outcome is worth spending, then shape work that fits. An agent's ability to add another feature doesn't increase the time we have to review it or the user's need for it.

Put the controls around version zero

When I say we should “harness the heck out of V0,” I mean giving the first version clear limits and useful checks. For an agent, that includes the code controlling its tools, context, and stopping behavior. For the surrounding product, it includes permissions, tests, and enough visibility to understand failures.

The controls should fit the experiment. A disposable mockup using synthetic data doesn't need the operating setup of a service handling customer records. Once real people depend on it, though, “it's only an MVP” is a poor explanation for losing their work or exposing their data.

For our support-routing trial, we can limit the first version to suggesting a destination. It can't send a reply or close a ticket. If classification fails, the message stays in the existing queue. We retain enough information to compare the suggestion with the reviewer's decision.

That gives us a narrow product we can evaluate. Adding autonomy later becomes a decision supported by results from the trial.

Close the loop before expanding the product

Before we build, we should write down what we expect to change and what evidence would make us reconsider. For routing, the expectation might be less time spent sorting messages without more missed urgent requests. We'd agree on acceptable results before seeing the numbers.

Then we'd watch people use it. If the categories don't match how the team works, we change them. If checking suggestions takes longer than sorting manually, we investigate or stop. A request for a prettier dashboard can wait while we answer those questions.

This is the approach I described in the software-factory post: frame the problem, shape a bounded attempt, and use what we learn to decide what deserves more investment.

I still owe Ries for giving me a way to think about that early in my career. When the first version arrives faster, we have a chance to get it in front of someone sooner. I'd rather use that time to find out whether the skateboard helps them get anywhere before we approve the car.

Takeaway

With AI, we can build something that looks finished before we've understood the problem. That completeness can feel like evidence we've built the right thing, even when we haven't tested our assumptions with the people who will use it.

Building still isn't free. We pay to understand, review, integrate, and operate what we create. Cheaper implementation makes those costs easier to postpone, but they still have to be paid.

We can use the time AI saves us to put a smaller version in people's hands, learn what helps, and decide what deserves to grow.