AI Made It Cheap to Ship the Wrong Thing. Now What?

AI made building fast and cheap. That sounds like a win. But here is the catch: the part that was always hard, figuring out what to build, did not get any easier. So now you can ship the wrong thing faster than ever.

Marty Cagan and his crew at SVPG have been hammering this point, and it lines up with what people are seeing on the ground. Let me catch you up on what actually shifted and what to do about it Monday.

The bottleneck moved, and your team may not have noticed

For years the slow part was building. Engineers were the constraint. Cagan argues that the cost of delivery has dropped so dramatically that building is no longer the thing holding you back. The new bottleneck is finding a solution worth building at all.

He splits the work in two, using Jeff Patton's old phrase. You build to learn, which is discovery. And you build to earn, which is delivery, the real commercial product people pay for. Both are building. The purpose is different.

The trap is treating speed as the goal. Cagan calls the old feature factory a "turbo-charged" version of itself now, "capable of producing more bad products, faster, than ever before." Faster output does not mean better outcomes. It just means you find out you were wrong sooner, after you already shipped.

Prototypes are the new spec

Here is the practical change. With tools like Cursor and Claude Code, a product manager can spin up 10 to 20 prototypes a week without waiting on design or engineering. Cagan notes this was true before generative AI with Figma, but now you can build live-data prototypes cheaply, and test several approaches in parallel instead of one at a time.

That changes how you hand work off. The prototype becomes the spec. In the SVPG FAQ, Cagan calls this "prototype as spec," with a short doc filling in the cases a prototype can't show, like scale needs. The doc supplements discovery. It does not replace it.

Watch for the slide back. If your PM writes a PRD instead of testing a prototype, you are back in the project model with a fancier toolset.

A prototype is not a product

This is where teams get burned. Building to learn and building to earn are not the same bar. Delivery means scale, security, reliability, privacy, fault tolerance, the long boring list that makes a product something a customer can run their business on. AI does not hand you that for free.

The builder in the trenches at A List Apart makes the same case from the money side. In financial products, he writes, the goal is "bedrock," the core element that truly matters to users, the boring servicing journeys people use every day. He warns against the "feature salad" that happens when an app becomes "a reflection of the internal politics of the business rather than an experience designed around the customer."

And do not throw experiments at paying customers. Cagan's rule is to "test ideas responsibly," because loyal customers "start feeling abused" when they realize they are guinea pigs for constant erratic change.

Internal tools and commercial products play by different rules

Not every product faces the same fight. Cagan draws a sharp line: internal products are hard, commercial products are harder. With an internal tool, the user can't pick a competitor. The company pays them to use it. Solving the problem is enough.

A commercial product has to win. It is not enough to solve the problem. You have to solve it so much better than the alternatives that a customer switches. And with AI, Cagan says, those competitors "are emerging faster than ever."

So before you copy a discovery playbook, ask which game you are in. The internal team can lower the usability bar and lean on training. The commercial team cannot. That changes how much discovery you actually need.

What good looks like at scale

Google is the proof point. In their breakdown of the product model at Google, Cagan and Elias Lieberich note nine products with over a billion monthly users, and none of them invented a new category. Search, maps, email, browsers all existed. Google won by solving known problems better.

Two moves stand out for your team. First, leaders pick the hard problems, then "broadcast" them and let teams choose to tackle them, sometimes with multiple teams on the same problem. Second, evidence beats hierarchy. "Options are weighed against the evidence, not job titles."

One more: the strong tech lead. At Google, many PMs "haven't touched a ticket in years" because a tech lead owns delivery and joins discovery. That frees the PM to do the part AI can't, the judgment about what is worth building.

The deep cut

The skill that matters now is not running the prototyping tool. Cagan is blunt: getting good with the tools is "the easy part." The hard part is product sense, the judgment to read what a prototype is telling you and decide what to do next. AI hands everyone the same tools. It does not hand everyone the same taste.

So the people on your team who saw their job as facilitating, managing the backlog, or being "the glue" are exposed. Cagan says plainly they are "increasingly at risk." Your move is to stop measuring PMs by output and meetings, and start measuring whether they can shape a solution that wins. Spend your next review on that, not on velocity.

Three questions for your team

1. When we hand work to engineers, is the prototype the spec, or are we writing PRDs in place of real discovery? One means we learned, the other means we guessed.
2. For each product we own, are we playing the internal game or the commercial game, and are we spending discovery effort to match? Overbuilding an internal tool and underbuilding a commercial one are both expensive mistakes.
3. Who on our team can actually evaluate what a prototype tells us, and who is mostly facilitating? Name them, and decide where you are investing in product sense this quarter.