The cost of building has collapsed. Engineers ship faster. Non-engineers are building and shipping. What used to take a month can take a day. All of this is real, and most of it is a genuine improvement.
But something is getting lost in the speed, and it is not the code.
It is the question: should we build this?
The friction was doing useful work
When building was expensive, the cost slowed you down. You had to justify it. You had to think clearly about what you were building and why before you started. That friction was annoying - and it was also doing something useful.
The slower pace created space for the question. Is this the right thing? Does this solve the right problem? What does the customer actually need - not just what they are asking for?
That space is collapsing. Building is now cheap enough that you can do it before you have decided if you should. The impulse and the output can arrive in the same afternoon.
The client request trap
If your client-facing teams can build, they will be on calls where clients will ask for things. And the client-facing team can say yes. Not “I’ll feed that back,” not “let me check with the team” - just yes. Because they can build it - quickly.
That feels like incredible service. Client asks for something, vendor builds it. Fast, responsive, client-focused. What’s not to like?
The problem is this skips a critical part of the process.
The PM’s instinct is to ask why. Not to be difficult - but because the client’s ask and the client’s need are often different things. “We need a new button” is a request. “Our team keeps losing time because we have no visibility on this metric” is the need.
If you go directly to adding the button, you might solve the request without touching the need. The client is happy - you did what they asked. But their underlying problem is still there. So they come back. Can we try this instead? You build that too. And so it continues.
Each time something gets added, nothing is being removed. Nobody is stopping to ask whether the thing built two cycles ago is still worth keeping. The product accumulates mess - features that half-solved a problem that was never properly understood in the first place.
This is product debt, and it is one of the biggest risks of building without asking why. It’s a slow accumulation of things that made sense in the moment and left the product harder to understand, maintain, and evolve.
Client-facing teams with building capability do not naturally resist this cycle - because each individual request feels like good service. The rush of directly satisfying a customer is real and very easy to chase. But if everyone is building what clients ask for, at speed - who is the product actually for?
Like this post so far? Product Notes is a free weekly newsletter for product people. Subscribe to get it in your inbox.
What the review cycle won’t fix
The optimistic assumption is that this gets caught in review. Pull requests, sign-off processes, engineering oversight - someone will pump the brakes before anything goes live.
By the time a PR exists, the client is likely expecting the change to go out. Any pushback at this stage is a broken promise - and the people who made the commitment will push hard against rejection.
Also, the engineers reviewing the code might be happy with the code itself. Code reviews focus on code quality, not on whether we should be building this. Those are different questions, and the second one needs answering much earlier than a PR. Getting there at the end is too late.
This is not a gatekeeping argument
Nobody needs a PM to approve every feature before a line of code is written. That is not the point.
The point is that the capability to build needs to travel with the discipline to ask why. When those two things get separated - when one group can build and another group is supposed to ask the hard questions - the hard questions stop getting asked. The people who can build will build. The pressure to keep clients happy will make sure of it.
The best version of this is teams who have both: the building capability and the product sense to hold the question before they start. The worst version is teams who can build anything, with no mechanism for asking whether they should.
If your organisation is investing in making more people able to build, it is worth asking a parallel question: are you investing equally in their product judgement?
What you can do to help
Here are two things you can do to help.
Get in before the build starts. If client-facing teams can now build, the PM conversation needs to happen before they commit to anything - not when a PR arrives. By that point, the client is expecting a change. Get into those client conversations earlier, or create a lightweight check-in before any commitment is made.
Make “why” a prerequisite, not a retrospective. Before anyone says yes to a client request, they should be able to answer two questions: what underlying problem does this solve, and what would success actually look like? This isn’t a gate - it’s a habit. One that takes thirty seconds to work into any conversation.
Product Notes is free and lands every week. Subscribe to get it in your inbox.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.