In the AI Era, Building Software Is Easy. Deciding What to Build Is the Hard Part.

A product manager describes a prototype to an engineer on a Monday morning. By Monday afternoon, an AI coding assistant has produced a working version, complete with a database schema, a basic UI, and enough scaffolding to demo to a stakeholder. Ten years ago that same prototype might have taken two weeks. Five years ago, maybe three days. Today, it can take an afternoon. Nothing about that is hypothetical anymore; it is simply what modern tooling does.

That compression is real, and it is large. GitHub has reported that developers using Copilot complete certain coding tasks markedly faster than those without it, and McKinsey’s research on generative AI’s economic impact has estimated substantial productivity gains concentrated in software development and related knowledge work. Whatever the precise multiplier turns out to be in any given organization, the direction is not in question. Producing software, prototypes, and content has gotten cheap.

Here is the problem: making production cheap does not make product judgment better. It just means a team can now build the wrong thing at a speed that used to be reserved for building the right thing. The question that used to gate most initiatives, “can we build it?”, has quietly stopped being the hard question. The hard question is the one that comes before it, and AI tooling does nothing to answer it: should we build it, for whom, and why? That question, not the coding assistant, is what a real AI product strategy has to start with.

The Bottleneck Has Moved

For most of the last two decades, engineering capacity was the limiting factor in product development. Roadmaps existed because there were more good ideas than there were people and hours to build them. Prioritization frameworks like RICE (popularized by Intercom’s Sean McBride) and ICE (associated with Sean Ellis) exist largely because capacity was scarce and someone had to decide what got the next sprint.

AI has not eliminated the need for prioritization. It has changed what is being prioritized. When a working prototype can be generated in hours instead of weeks, the constraint is no longer “do we have the engineering capacity to try this?” It is “do we understand the customer well enough to know this is worth trying?” Marty Cagan and the team at SVPG have spent years describing the difference between “feature teams,” which take requirements and ship them, and empowered “product teams,” which are given problems to solve. AI-assisted coding makes feature teams faster at doing exactly the thing Cagan warns against: shipping output on faith. Melissa Perri named this pattern the “build trap” in her book of the same name, the habit of measuring success by what shipped rather than by what changed for the customer. AI does not cause the build trap. It just lets a team fall into it at a much higher rate of speed.

Feature velocity is not the same as customer progress. Velocity without direction creates waste faster.

This is the core reversal at the center of outcome-first product thinking: output is what a team creates, a feature, an app, a report, an AI assistant. Outcome is what becomes better for the customer because that output existed, time saved, a problem resolved, confidence increased, risk reduced. AI tooling is extraordinarily good at the first half of that sentence and has no opinion whatsoever about the second half. Deciding the outcome still has to happen in a human’s head, informed by evidence about a specific customer segment and a specific problem, before the first prompt to a coding assistant is ever typed.

More Output Is Not Automatically Better Output

It is tempting to assume that if production is cheaper, quality will simply follow along for the ride, more attempts, more iteration, more polish. The evidence so far does not support that assumption cleanly.

GitClear’s 2025 research on code quality, which tracked a large body of commits from 2020 through 2024 as AI coding assistants became widely adopted, found rising code churn and a growing amount of duplicated code over that period. Code churn, code that gets rewritten or discarded shortly after being written, is a reasonable proxy for work that was not well understood before it was produced. Duplication tends to show up when it is faster to generate a new block of code than to understand and extend an existing one. Neither pattern is what you would expect if AI assistance were, on its own, making software better. It looks more like AI assistance is making it easier to generate work that has not been thought through, and to generate a lot of it.

This should not be surprising, because it mirrors a pattern that predates generative AI by years. Pendo’s 2019 Feature Adoption Report, based on an analysis of roughly 615 software subscriptions, found that around 80 percent of features in the products it studied were rarely or never used. That number comes from one vendor’s dataset and should be read as a notable finding rather than a universal law, but it lines up with what many product leaders already suspected: teams have long been capable of shipping more than customers actually need or want. AI does not fix that gap. It widens the pipe that feeds it.

There is a related, sobering data point from the other end of the product lifecycle. CB Insights has repeatedly analyzed startup post-mortems and found that “no market need” is the most cited reason founders give for failure, showing up in roughly 42 percent of the cases they reviewed. Faster production does not change what customers need. It only changes how quickly a team can build something nobody needed.

What Becomes Scarce When Production Is Abundant

If code, prototypes, and even drafts of customer-facing content can be produced quickly and cheaply, then the constraints that actually govern whether a product succeeds move somewhere else. None of them are things an AI model can generate on request.

Attention

Customers have a fixed amount of attention, and every new feature, notification, or workflow competes for a slice of it. A team can now ship five variations of a feature in the time it used to take to ship one, but the customer’s willingness to notice, evaluate, and adopt any of them has not grown at all. Attention was scarce before AI and remains exactly as scarce now.

Trust

Trust is earned slowly and lost quickly, and it does not compress the way build time does. A digital health tool that ships a flawed recommendation, even once, can undo months of credibility with clinicians or patients. Producing more, faster, means more opportunities to either build trust or damage it, and the second outcome is much easier to produce by accident.

Focus

Organizations have a limited capacity to hold a small number of priorities at once. Cheap production tempts teams to run more experiments and launch more variants simultaneously, which sounds efficient but often just fragments attention internally the same way it fragments attention externally. A roadmap with thirty AI-assisted initiatives running in parallel is not thirty times more strategic than a roadmap with three; it is often just three real priorities diluted by twenty-seven distractions.

Organizational capacity to absorb change

Every new output that reaches a customer or an internal user requires some amount of change on their end: a new habit, a new screen, a new workflow, retraining, or simply the mental effort of noticing something is different. That absorption capacity is human and does not scale with compute. A support team, a clinical workflow, or a customer base can only absorb so much change in a given quarter regardless of how many features engineering was able to produce.

These four constraints, attention, trust, focus, and capacity to absorb change, do not show up in a sprint velocity chart. They are exactly the constraints that outcome-first product thinking is built to manage, because they are constraints on the customer’s side of the relationship, not the engineering side.

From Feature Factory to Outcome Discipline

None of this is an argument against using AI to build. It is an argument for being more deliberate about what gets built, precisely because building has gotten easier. A sound AI product strategy is not a roadmap of AI-powered features; it is a discipline for spending judgment upstream, before code gets written, rather than after.

That starts with naming the actual customer and the actual problem before opening a prompt window: who is the core customer, what is the priority need or pain, and what specific outcome would tell you the problem is actually solved. It continues with writing down assumptions honestly rather than treating a confident sentence in a product brief as settled fact. An assumption written in a product document does not become a fact just because an AI-generated prototype was built on top of it.

It also means resisting the urge to let “we can build this in a day” replace “we should build this.” A Minimum Viable Output, the smallest focused output that can meaningfully test or advance a priority outcome, is a discipline of restraint, not a technical shortcut. That discipline shares real lineage with Eric Ries’s Lean Startup and Steve Blank’s Customer Development work on building small to learn fast, and AI tooling is a genuinely useful accelerant for producing that small output. What AI cannot do is decide how small “minimum” should be, or which outcome is worth testing in the first place. That is still a judgment call, made by people who understand the customer, not by the model generating the code.

For teams building AI-powered features specifically, this judgment extends to a set of questions that have nothing to do with model accuracy benchmarks: what happens when the model is wrong, who is affected, can the user detect the error, is human review required, and can the user opt out. NIST’s AI Risk Management Framework, organized around govern, map, measure, and manage, offers a neutral, widely referenced structure for working through exactly these questions, and its emphasis on keeping a human in the loop is a useful discipline regardless of which framework a team formally adopts.

Key Takeaway

AI has genuinely compressed the distance between an idea and a working prototype, and that compression is not going to reverse. What it has not done, and cannot do, is tell a team which idea deserves that speed. The scarce resource in an AI-abundant environment is not code, it is judgment: judgment about which customer, which problem, and which outcome are worth the organization’s attention, trust, and capacity to change. An AI product strategy that starts with the outcome, not the output, is how a team spends that new speed on progress instead of waste. Teams that treat outcome definition as the real gate, and AI-assisted building as what happens after that gate, will move faster in the direction that matters. Teams that skip the gate will simply produce waste faster than they ever could before.