The title is deliberately provocative. Building software is not solved. Reliability, accessibility, security, and maintainability still take real craft. But for many teams, getting to a first working version is becoming less of the bottleneck than deciding which version is worth making.

When the cost of a first attempt falls, the value of good judgment rises. A team can produce more options, more quickly. It still has to choose a problem, understand the people affected, and notice whether the change made anything better.

The bottleneck moved

A prototype can make an idea easier to discuss. AI-assisted tools can help draft code, explore an interface, or reduce the time spent on repetitive implementation. None of that tells a team whether the idea belongs in the product.

The hard questions come before and after the first commit:

  • Who is struggling, and what are they trying to do?
  • What do they do today when the product does not help?
  • Which constraint makes this problem worth solving now?
  • What is the smallest change that could teach us something?
  • What will we look at after release?

These are not reasons to slow down. They are how a team makes speed useful.

The work that remains

First, get close to the problem. A feature request is evidence, but it is not the whole problem. Ask what someone was trying to accomplish, what they tried, and what they did next. Read support notes, observe a workflow, or talk to the people who will use the change.

Second, decide what not to build. A strong product decision names the trade-off: which user or situation comes first, what the team is deliberately leaving out, and why the smallest version is enough to test the direction.

Third, close the loop. Choose a signal before shipping, then combine it with what users say. A metric alone can hide a bad experience; an anecdote alone can hide a broader pattern. If the signal is noisy or incomplete, say so. The goal is to learn, not to decorate the launch with a number.

The product engineer’s leverage

A product engineer connects these decisions to working software. That does not mean one person has to own every discipline or make every call. It means the engineer is involved early enough to shape the solution and stays close enough to learn from what ships.

With a PM, that can start with scoping a problem, joining a user conversation, writing a brief, and agreeing on a success signal. In a small team without a PM, the engineer may share more of the prioritisation and roadmap work. The responsibility is different; the habit is the same: make the reasoning visible and keep the loop connected.

If you want a concrete way to practice it, use the 90-day plan from software engineer to product engineer. For a broader map of product engineering and adjacent roles, see one map for all the new titles.

A question for the team

What would change if the team spent less time waiting for a handoff—and more time learning whether the change helped?

The answer is not “write less code.” It is to connect the code to a problem, a decision, and an outcome. Building still matters. Choosing well is what gives the building direction.