If Building is Cheap, Where Does the Advantage Come From?

It was the best of times. It was the worst of times.

Founders and CEOs keep circling the same question. If building is cheap, where does the advantage come from?

A small team can now prototype in a day what used to take a quarter. A competitor can copy a feature in a weekend. The things that once set a product company apart, namely engineering headcount, development speed, and a long list of features, are getting easier for everyone to reach. That should worry you. It should also sharpen your thinking.

Charles Dickens opened A Tale of Two Cities with a line about contradiction. It was the best of times. It was the worst of times. He was writing about London and Paris in the age of revolution. He could just as easily have been writing about product development in 2026.

AI has changed product development more in three years than most tools changed it in thirty. Anyone who says it has changed nothing is not paying attention. Those who say it has solved everything are selling something. Both things are true at once. The technology is remarkable. The practices growing up around it are a mix of the smartest and the most reckless I have seen in over twenty-five years of product leadership.

This article looks at both sides: the good and the bad of the technology, and the good and bad habits teams are building around it. Then it returns to the question. When anyone can build, what is left that only you can uniquely do?

The best of times: the technology

Start with what is genuinely great. A product manager with an idea used to need an engineer, a designer, and two weeks to get something in front of a customer. Now she can have a working prototype by lunch. Not a static mockup. A clickable, data-driven experience that a customer can react to. The cost of a first look has collapsed.

Research synthesis has changed too. A team can feed forty interview transcripts into a model and get themes, contradictions, and verbatim quotes in minutes. Work that took a researcher a week now takes an afternoon. That does not remove the need for the researcher. It removes the drudgery around doing research by offloading mundane tasks to AI.

Engineering has felt it most. Code assistants write boilerplate, generate tests, explain unfamiliar code bases, and translate between languages and frameworks. Migrations, refactors, and documentation that sat in the backlog for years are suddenly getting done. Quality work benefits as well, from test generation to log analysis and accessibility checks.

Analytics has improved. Product leaders can ask questions of their data in plain language instead of waiting in a queue for an analyst. Anomaly detection, churn prediction, and usage clustering are now within reach of teams that could never have afforded a data science group.

Natural language interfaces, agents, and adaptive experiences give product teams a bigger palette than ever, and the ability to create new product categories simply not possible before.

The best of times: the practices

The technology is only half the story. The other half is the potential changes to how teams work.

Testing ideas is cheap now. That changes the economics of discovery. Teams that used to debate an idea for a month can build three versions and put them in front of customers in a week. Good teams use that to learn faster. They test more assumptions, kill more bad ideas early, and arrive at conviction with evidence instead of opinion.

The prototype has become the new conversation piece. Instead of a forty-page requirements document that nobody reads, teams show a working example and ask, "Is this the problem?" The PRD is not dead, but it is being rewritten. It is shorter, sharper, and focused on intent, constraints, and outcomes rather than a list of features.

Roles are blending in healthy ways. Designers are shipping code. Engineers are shaping flows and copy. Product managers are running their own analysis. The strongest product trios I see use AI to understand each other's craft, not to supplant one another.

Product operations benefit quietly. Release notes, status updates, stakeholder summaries, and customer documentation stay current because the associated cost has dropped to nearly zero. Organizations that were always a little out of sync now share a more accurate, up-to-date picture. Alignment is an underrated payoff.

Small teams punch above their weight. A startup with five people can now do what once took twenty. For a Series A company, that is a real competitive shift.

The worst of times: the technology

Now the other side. AI is confident and wrong more often than its fluency suggests. Hallucinated facts, invented citations, and plausible but broken logic show up in real work. The danger is not that the output looks bad. It is that it looks good.

Generated code has its own cost. It compiles, it passes the demo, and it quietly accumulates. Duplicated logic, inconsistent patterns, thin test coverage, and security holes pile up faster than any team can review them. Tech debt used to accrue at the speed of typing. Now it builds at the speed of prompting. Someone will pay that bill, and it will not be the person who wrote the prompt.

Non-determinism is a real product problem. Traditional software does the same thing every time. AI features do not. The same input can yield different output on different days. A vendor’s model update can change your product's behavior overnight without a single line of your code changing. Quality assurance, support, and customer trust all get harder.

The economics are different too. Every AI feature carries a variable cost per use. A feature that delights customers can quietly destroy gross margin. Teams that ignore unit economics discover the problem too late, after they have scaled it.

And features are becoming a weaker moat. If a competitor can replicate your feature in a weekend, the feature was never your advantage. Durable advantage has to come from somewhere else, such as deep customer understanding, trust, proprietary data, or distribution.

The worst of times: the practices

The growth of bad practices worries me more than the bad technology aspects. Technology gets better. But habits harden.

The first bad practice is mistaking speed for direction. When building gets cheap, the temptation is to build everything. Teams ship more features per quarter than ever, yet customers feel less value. This is a feature factory with a turbocharger. The bottleneck in product was never typing. It was knowing what is worth building. AI made the easy part easier and left the hard part exactly where it was.

The second bad practice is skipping discovery. I have watched teams use AI to generate personas, simulate customer interviews, and write user stories, then call the work validated. It isn’t. A synthetic customer will never say things that surprise you, because it is built from historical data compiled from what has already been said. Real discovery means sitting across from a real person and listening to their real problem. Nothing replaces that.

The third bad practice is outsourcing judgment. When a model produces a confident recommendation, it is tempting to accept it. AI-written prioritization frameworks, roadmap drafts, and strategy memos all sound reasonable. They also sound like everyone else's. A team that hands its thinking to a model ends up with a strategy that echoes the internet’s average content, with no differentiation and no creativity.

The fourth bad practice is the absence of governance. Shadow AI is everywhere. Employees paste customer data, source code, and confidential plans into tools without approval. Product teams ship AI features without clear policies on data use, bias, transparency, or failure modes. The companies that get this right will earn trust. The ones that do not will learn about it from a customer, a regulator, or a headline.

The fifth bad practice is the review gap. AI produces work faster than humans can check it. Review queues swell. Reviewers skim. Approval becomes a rubber stamp. Production speed has outrun verification speed, and quality is the casualty.

The sixth bad practice is quieter. Skills are eroding. A junior product manager who never writes a first draft never learns what makes a draft good. A junior engineer who never debugs never learns how systems fail. If AI does all the reps, who builds the next generation of strong senior leaders? Judgment is built through struggle. Remove the struggle, and you remove the growth.

Finally, there is AI theater. Roadmaps stuffed with "AI-powered" features that solve no real problem. Boards asking for an AI strategy before anyone has named the customer problem. Teams adding a chatbot because a competitor did. This is the old mistake of solution-first thinking in a new costume.

My go-to: the two teams comparison

I see two kinds of teams using the same tools.

The first team uses AI to move faster in whatever direction it was already going. It generates more output, more features, more documents, more prototypes. It measures activity. It celebrates velocity. Six months later, it has a bigger product and the same problems.

The second team uses AI to learn faster. It tests more assumptions, talks to more customers, and reviews more evidence. It measures outcomes. It uses the time it saves to think harder about the problem. Six months later, it has a smaller, sharper product that customers actually value.

The same tools, budget, and talent. The difference is not the technology. The difference is what the team does with the time it gets back.

Augment, not replace

AI's best use in product development is to augment humans, not replace them.

Think about where a product leader's time actually goes. A surprising share disappears into the tedious and the mundane. Writing up meeting notes. Formatting tickets. Grooming the backlog. Drafting release notes. Pulling data for a slide. Summarizing a competitor's latest announcement. Turning a whiteboard photo into a document. Reconciling five versions of the same spreadsheet. None of it is unimportant. But none of these are high-leverage value creation activities.

This is where AI shines. It is patient. It does not get bored. It can produce the first draft, first pass, and first cut of boring things in seconds. Giving that work to the machine frees a great deal of human time.

The question is what you do with that time. That is the whole game. Use it to exercise better judgment. Judgment is choosing which problem to solve and which to ignore. It is knowing when the data is misleading, when a customer is telling you what they think you want to hear, and when the market has shifted under your feet. It is deciding which tradeoffs to accept, which risks to take, and what the product will stand for. It is taste. It is ethics. It is accountability.

Consider a discovery week. The tedious parts are scheduling, transcribing, tagging, and clustering. Let the machine do them. The human parts are the conversation itself, the follow-up question nobody scripted, the moment you notice a customer hesitate, what they didn’t say, or nonverbal cues. Automate the first list. Protect the second.

A model can inform any of those decisions. It cannot own them. When a product fails a customer, no one will accept "the AI recommended it" as an answer. The human who made the call is the human who answers for it. That is not a flaw in the system. It is the design.

So the practical guidance is simple. Automate the tedious. Review the output. Keep humans on the decisions that carry consequence. Put the saved hours into customer conversations, hard tradeoffs, and cross-functional alignment, the places where human judgment compounds. Treat AI as a very capable assistant, never as the decision maker.

So where does the advantage come from?

Let’s return to the question. If building is cheap, where does the advantage come from?

Not from the activity of building. Every team now has access to the same models, code assistants, and prototyping tools. Speed is available to everyone, which means speed alone separates no one.

The advantage comes from three places. The first is knowing what is worth building. When a team can build anything, the scarce skill is choosing what to build and what to leave alone. The second is understanding the customer more deeply than anyone else. That takes actual conversations with real people and the pattern recognition that comes from years of doing it. No model can hand you that, because much of it has never been written down. The third is the judgment to make good decisions under uncertainty, and the accountability to own the result.

Notice what those three have in common. All of them are human. All of them are what you get back when AI takes the tedious and the mundane off your team's plate. That is the link between the question and the answer. AI does not replace the source of your advantage. It gives your people more time to use it, and that is a true multiplier.

Dickens's line works because both halves are true at once. That is where product development stands today. The tools are extraordinary. The risks are real. Whether this turns out to be the best of times or the worst depends on how teams spend the time AI gives back. Spend it on more output, and you will look like everyone else. Spend it on better judgment, and you will be hard to copy.