The product lifecycle is broken

Writing software now costs less than writing about it — and that changes everything.

📣 Want to build this muscle? I’m presenting a hands-on session on AI prototyping at Dan Olsen’s Lean Product Meetup next week in Mountain View. Dan’s meetup has been one of the best product communities in Silicon Valley for years — 11,000+ members — and he’s a fantastic host. You can attend in-person at Intuit HQ or join via Zoom. Grab a ticket here.

And if you want to go deeper, my AI Prototyping course with Reforge starts April 24th.

---

Many of the best practices we take for granted weren’t designed to help you build the best product. They were designed to avoid expensive mistakes.

The “minimum viable product” is the clearest example: no customer is looking for a product that just barely solves their need.

MVPs exist because building software is expensive, and we want to validate demand before investing further.

MVPs are no longer viable

That single constraint — the expense of building software — shaped every aspect of yesterday’s product lifecycle. We avoided building for as long as possible. And when we did build, we built as little as we could get away with.

We created an escalating ladder of artifacts — each requiring more effort but providing stronger signal:

We started with specs — relatively quick to write and easy to iterate.

After specs, we moved to visual designs. Wireframes come first — quick sketches to establish structure. Then detailed designs, sometimes pixel-perfect.

But even the best mockup can’t capture how modern software actually feels. Animations, generative AI output, native interactions — these only make sense when you experience them. A Figma mockup can show you a screen. It can’t show you whether an interaction feels right.

Still, we created these artifacts because we need conviction before we commit engineering resources. Visual designs are expensive to create and hard to iterate, but they were cheaper than building the wrong thing.

And when working software finally entered the picture, effort jumped dramatically — teams often skipped functional prototypes entirely because they’re nearly as hard to build as the MVP itself.

The traditional product lifecycle was not designed to help you build great products.
It was designed to manage the cost of building the wrong ones.

At each step, we got valuable signal that gave us the conviction to invest in the next step. If we didn’t get that conviction, we went back to square one — iterating cheaply until we figure out what’s missing.

This process wasn’t designed to help you build great products. It was designed to manage the cost of building the wrong ones.

From assembly line to jazz band

For decades, that was the right approach. When building software is expensive, you manage costs carefully. Even the most agile teams operated as assembly lines — handoffs from one team to another, conviction required at every stage to justify the next.

But what happens when the cost of building software drops dramatically?

Today, AI is changing the fundamental constraint of product management.

What once took weeks now takes hours. You can often create a working prototype in less time than it takes to write a detailed spec or sketch out a wireframe.

When working software becomes cheap to produce, the assembly line stops making sense. Why wait until the end of the process to see your idea come to life? Why hand off a spec when you can provide a prototype that better reflects the requirements?

Moving forward, the best product teams will operate like a jazz band. Instead of staged handoffs, team members riff off each other — each leveraging their unique strengths to get the right artifacts in front of customers. The flow isn’t one-directional. It loops back. It branches. Prototypes inform research. Research reshapes prototypes. A spec might be the first step, or it might be one of the last.

Working software is no longer just what we deliver at the end of the process. It’s integral to how we communicate, decide, and validate along the way.

The new operating model

In the old model, product development moved in a rigid sequence: PM hands off to design, design hands off to engineering, and each step introduces weeks of lag while teams wait for the next function to pick up the work.

In the new model, those handoffs collapse into a tighter loop — PM, design, and engineering riff together, using working prototypes to align early and iterate quickly. The result is less time spent translating intent across documents and meetings, and more time spent learning from real interactions and real customer conversations.

This isn’t incremental — it’s a fundamental shift in how we operate. In this new model:

1. Speed is no longer a competitive advantage — it’s table stakes. We can build faster, but so can our competitors. The market landscape and customer expectations are changing as quickly as we can build. Moving fast matters, but it’s not a moat.

2. Everyone is a builder — which makes prioritization harder. PMs, founders, salespeople, customer success teams — anyone with product input can now turn hunches into working software. That’s a flood of new possibilities, often from people closer to the customer. But more prototypes doesn’t mean better products. You need sharper validation to filter for what actually serves the customer.

3. The math on exploration has flipped. You can build five solutions instead of committing to one. Hunches that would never justify the resource investment can now get tested. What used to look like waste — building something you might throw away — is now the fastest path to the right answer.

This is why prototyping has become a must-learn skill. Not because it’s new and shiny — because it’s now foundational.

The best product builders are integrating working software into every phase of discovery and development.

They prototype to explore. They prototype to align. They prototype to validate. Fluency with prototyping is now as fundamental as the ability to write a clear spec or run a good customer interview.

Prototypes are decision-making tools

Prototyping is fun — and it’s easy to get pulled into crafting the perfect thing. It’s critical to remember that prototypes aren’t the deliverable; they’re a tool for making better and faster decisions.

This means the first question isn’t “What should we prototype?” Instead, start by asking: “What decision are we trying to make?”

Your answer determines what you build:

• Concept prototypes — Exploring which direction to pursue? Build rough variations to map the solution space.

• Design prototypes — Need to align stakeholders on what we’re building? Build something higher fidelity that gets everyone on the same page.

• Research prototypes — Need to validate whether customers will use it? Build something users can understand and get value from.

• Technical prototypes — Need to prove technical feasibility? Build something that tests how things work in the real world.

This is the jazz band in action. During any product cycle, you’ll reach for some combination of these prototypes — not in a fixed sequence, but as the questions demand. Each prototype answers critical path questions, helping the team build the conviction to launch.

The fast pace of prototyping also means we can throw out a lot more work. Dead ends that used to cost weeks now cost hours. This kind of exploratory iteration used to be the privileged domain of large companies with big research budgets. Anthropic reportedly cycles through 10 or more prototypes for a single feature, each iteration compressed to hours by AI coding tools. That kind of rapid experimentation is now accessible to anyone.

The prototype itself is never the point. The decision it enables is.

Prototypes are sketches, not finished paintings

An artist never starts by putting oils directly on a blank canvas. Oil painting is slow, deliberate, and expensive to change. So you start with a pencil sketch — fast, cheap, and easy to revise. The sketch captures the composition, the proportions, the intent. It tells you whether the painting is worth making. And then — this is the important part — the sketch gets painted over. It’s not the final product. It was never meant to be.

Your prototype is that sketch. It captures the flows, the interactions, the intent. It tells your team whether the product is worth building. But it was always meant to be replaced by the fully realized product — just as the pencil lines disappear under layers of oil paint.

Throwing away a prototype sounds inefficient. After all, it means building the similar things more than once. But the opposite is true. Trying to turn your prototype into production code weighs it down from the very start and undermines the and flexibility of prototyping. For the same reason, artists don't throw oil paints onto a blank canvas. Skipping the sketch ends up costing time, not saving it.

The data backs this up. When development consultancy Whitespectre audited an AI-built prototype — a Jira evaluation tool a PM had assembled in four hours using v0, Cursor, and ChatGPT — they found that only 30% of the code was salvageable for production. The rest was unusable code. That’s not a failure. That’s the process working exactly as intended. The prototype compressed weeks of alignment and discovery into a single afternoon.

The prototype’s job is to give the team a running start, not to cross the finish line.

The handoff is where you pass the conviction you’ve built — along with the decisions, context, and intent behind it — to the people who will bring it to life in production.

The culture required to make this work

AI prototyping isn’t just a matter of rolling out new tools. It’s a shift in how teams build.

Nobody has this fully figured out yet. The loudest LinkedIn takes — “we don’t need engineers anymore,” “only hire builders,” “I replaced my team with AI agents” — are mostly overreach.

AI prototyping is evolving how we work, not replacing who does the work.

The critical questions remain the same:

1. What do customers really want?

2. How do we best serve them?

3. How do we build a durable business around that value?

What has changed is the cost of exploring and communicating solutions. Teams that embrace this new way of working share a few traits:

• They prototype constantly — and with purpose. Skill comes from reps. The teams pulling ahead aren’t theorizing about AI tools; they’re using them every day. But volume alone isn’t the point. Every prototype answers a question. If you can’t articulate what you’re trying to learn, you’re not prototyping — you’re tinkering.

• They aren’t territorial. AI prototyping blurs traditional boundaries. PMs explore UX. Engineers define requirements. Designers validate technical assumptions. The best teams aren’t threatened by this — they welcome it. Assembly line handoffs become jazz band collaboration.

• They have permission to learn. This is the most important one. AI prototyping is a skill. Skills take practice. That means leadership gives teams autonomy to try things that might not work — and doesn’t expect immediate perfection. Teams without permission to fail don’t build the muscle.

Teams that embrace this shift build better products faster. Teams that don’t are operating at the same old speed while everyone around them accelerates.

Build software to build conviction

For decades, the expense of software shaped every aspect of how product teams operated. Artifacts, handoffs, gates, approvals — all designed to build conviction before spending.

That constraint is gone.

Working software is no longer just what you ship at the end. It’s how you communicate, make decisions, and validate ideas throughout the entire development process.

Remember where we started: the processes we’ve inherited weren’t designed to help you build great products. They were designed to manage the cost of building the wrong ones.

Now you can focus on what actually matters.

Prototyping is how you get there — not as a phase or a deliverable, but as a default mode for turning ambiguity into clarity. Fluency with prototyping is now as fundamental as writing a clear spec or running a good customer interview.

The opportunity isn’t just to work faster. It’s to finally build the way we always wanted to — with working software at the center of every decision.

---

Ready to get started? I’m presenting a hands-on session on AI prototyping and context engineering at Dan Olsen’s Lean Product Meetup next week — in-person at Intuit HQ in Mountain View or via Zoom. Dan’s community is one of the best in Silicon Valley for product builders, and this session will put the ideas from this post into practice. Grab a ticket here.

And if you want to go deeper, my AI Prototyping course on Reforge starts April 24th. You’ll learn how to turn prototyping into a practical skill you use every day — from software fundamentals to advanced techniques like data-driven prototyping and context engineering.