Cover image for When building gets cheap
Alexander Hipp

When building gets cheap

As building becomes faster and easier, the real challenge moves upstream. The hard part is no longer implementation, but judgment.

For most of my career, building was the constraint.

Discussions about scope were the norm because engineering time was limited. We debated priorities because every feature had a real cost attached to it. Also iOS, Android and web had their own dedicated engineers. Shipping something meant committing resources, attention, and future complexity. You didn’t build lightly.

That reality is about to change.

With AI tools, better abstractions, and agents that can generate actual working code, building is getting dramatically cheaper and faster. Prototypes and work that used to take weeks now takes hours. Sometimes minutes. Engineers can explore multiple directions in a single afternoon without needing a full planning cycle first.

That’s absolutely exciting. It unlocks creativity and speed in a way we’ve never seen before.

But it also shifts the center of gravity.

When building gets cheap, judgment becomes expensive.

The bottleneck shifts

If almost anything can be built at the same time, the hard question is no longer “can we build it?”

It’s “should we build it?” (Actually, in product organizations that has been the case before, but different topic)

It sounds obvious, but it changes everything.

The biggest risk is no longer moving too slowly. The biggest risk is moving extremely fast in the wrong direction. You can now scale the wrong idea 20x faster than before. You can ship ten features that technically work and still make the product worse.

I see teams celebrating velocity while quietly drifting away from the outcome that actually matters. More releases. More output. But not more impact.

Shipping is not strategy. Output is not progress.

When building gets cheap, measuring success by features shipped becomes almost meaningless. What starts to matter instead is clarity, coherence, and taste. What you decide to pursue. What you deliberately ignore. What survives after serious scrutiny.

In other words, judgment is the new bottleneck.

Roadmap becomes a portfolio

When execution speeds up, fixed long-term roadmaps as we still see them a lot these days start to feel more wrong then ever before.

If you can test an idea this week, why commit to a detailed monthly plan based on assumptions that may be outdated in a week?

The roadmap circus finally becomes less about locking in a sequence of features and more about managing a portfolio of bets. Some small and incremental. Some medium-sized with clear upside. A few bigger bets that could redefine the direction if they work.

You run several in parallel. You learn quickly. You rebalance often. (Completely new challenges here on running so many experiments in parallel, also different topic, but one to watch out for.)

This shift is subtle in some companies but extreme in others and it changes how all teams need to plan and operate. Planning becomes more dynamic. Less ceremonial. More continuous. Finally!

Too many changes for humans

Today, AI helps to synthesize research, cluster feedback, generate prototypes, and simulate edge cases at a pace that feels almost unfair. Discovery cycles therefore shrink dramatically.

But customers do not suddenly think 20x faster. Sales teams do not suddenly adapt 20x faster. Support teams do not suddenly absorb change 20x faster.

Humans still need time.

If you push too many changes too quickly, you create confusion instead of value. You increase cognitive load. You erode trust. In some B2B contexts, customers may even prefer fewer releases, not more.

So restraint becomes a real skill.

Just because something can be built and deployed instantly does not mean it should be exposed instantly. Continuous deployment makes sense at a technical level. Continuous release needs to be handled more carefully.

Feature flags, gradual rollouts, controlled exposure. These become super critical tools.

Move fast internally. Move deliberately externally.

The PM role shifts

If engineers can spin up a first version in a few minutes, then writing perfectly detailed tickets is no longer required.

The role shifts.

Less translator of requirements.
More editor of direction.

The value is not in specifying every detail upfront. The value is in defining the problem clearly, sharing the relevant context, articulating what good looks like, and setting boundaries.

Then you let the team explore.

If what comes back is not good enough, you say so. You refine. You try again. When rebuilding takes minutes instead of weeks, the cost of iteration drops dramatically. That allows the quality bar to rise.

But there is one important tension here.

If all the customer empathy, research insights, and strategic context live only in the PM’s head, the PM becomes the bottleneck. Even if engineers can build 20x faster, the overall system might only move slightly faster because everyone is waiting for clarity.

So context has to be externalized.

Strategy, decisions, insights, raw research. Written down. Structured. Accessible. So engineers can move with autonomy instead of constantly asking for permission. The goal is not to control every move. It is to seed direction and then step aside.

In that sense, the PM becomes more of a custodian of product quality than the author of features.

Choosing what not to build

When building gets cheap, adding becomes incredibly easy.

Removing does not.

But the real work increasingly becomes saying no. Not because something is technically impossible, but because it does not align. Because it distracts from the core outcome. Because it adds complexity that will compound in the wrong direction.

It becomes easier than ever to justify “just one more feature.” It becomes harder than ever to protect simplicity.

The job shifts from pushing for more output to protecting focus and coherence over time.

In a world where almost anything can be built, the product is no longer constrained by engineering capacity.

It is constrained by judgment.

That’s uncomfortable, because judgment is harder to measure than velocity. It is harder to optimize than throughput. It requires taste, pattern recognition, and the courage to say no.

But it is also where the leverage now lives.

When building gets cheap, thinking well becomes the competitive advantage.

Article by Alexander Hipp (Product builder and advisor)
Read more about AI, Product Management