The Build Trap
How busy, competent teams end up shipping constantly and moving nothing.
Here is a team that looks healthy. Velocity is steady. Standups are crisp. The backlog is groomed three sprints out. Design is ahead of engineering. Every two weeks something goes live and the changelog post gets a few reactions in Slack. Retention has not moved in fourteen months. Nobody is doing anything wrong, and that is what makes this hard to see from the inside.
Melissa Perri named this the build trap: Measuring progress by how much software ships rather than what it changes.: an organisation that measures its progress by the amount of software it produces rather than by the value that software creates. The trap is not laziness. It is a system that rewards throughput, and competent people responding rationally to it.
How the trap gets built
How the trap is built
- 1Someone senior asks what the team will deliver next quarter, and reasonably wants a list.
- 2The list becomes a commitment, because that is what lists in slide decks become.
- 3Delivering the list becomes the definition of a good quarter.
- 4Discovery gets squeezed, because any week spent learning is a week not spent delivering the list.
- 5Nothing on the list gets measured after launch, because the team is already committed to the next list.
- 6Twelve months later, nobody can point to a single item and say what it changed, and the only defensible answer to 'how are we doing' is 'we shipped a lot'.
Step five is the one that locks the trap shut. Without post launch measurement, the feedback loop never closes, so nothing ever gets removed from the way you work. A team in the build trap has no mechanism for learning it is in the build trap.
Worked example
Northgate, an internal ops admin panel
The Northgate team supported an operations floor of about ninety people. Every quarter, ops leads submitted requests and the team built the top ten by vote count. Two years in, the panel had 41 screens. An engineer got curious and added basic page view logging. Nine screens had not been opened in ninety days. Three of them had been someone's number one request eighteen months earlier. The requests had been sincere. The need had been real at the time, or the person had left, or the workaround they already had turned out to be faster. Nobody had ever checked, because the team's scorecard was requests closed.
The Northgate team was not bad at their jobs. They were excellent at the job they had been given. The job was wrong.
Signals you are in the trap
- Your roadmap is a list of features with dates and no stated purpose.
- You can name what shipped last quarter but not what it changed.
- Requests are tracked and prioritised, but never revisited after delivery.
- Discovery is a phase that happens if there is slack, which there never is.
- The question 'should we build this at all' feels like it would be unwelcome.
Signals you are out of it
- Every roadmap item has an outcome attached that could be judged a failure.
- Some items were cancelled mid build because the evidence went the other way.
- There is a standing habit of checking what shipped three months ago.
- Talking to customers is on the calendar, not on the wishlist.
- Engineers propose smaller alternatives and that is treated as a win.
Getting out is less dramatic than it sounds. You do not need a reorg or an executive mandate. You need to close the loop on one thing, publicly, and let the discomfort do the work.
The smallest escape
- Pick one shipped feature
- Choose something that went live two or three months ago and had a confident story behind it. Recent enough that people remember, old enough that usage has settled.
- Find out what it did
- Adoption, frequency, and whether the behaviour it was meant to replace actually stopped. Two days of work, usually less. Do not dress it up.
- Share it without spin
- Including if the answer is that almost nobody uses it. The point is to make the question normal, and you can only do that by surviving the first honest answer.
- Ask one question afterwards
- What would we have needed to know before we built it? That question, asked out loud a few times, is what pulls discovery back onto the calendar.
Expect resistance, and expect it to be reasonable. Someone will point out that customers are waiting, that sales promised a date, that stopping to measure costs a sprint. All true. The answer is not to argue about philosophy. It is to have one concrete case where checking saved real money, and to refer to it calmly whenever the question comes up again.
One more thing worth saying plainly. Some of the build trap is a leadership problem you cannot fix from a PM seat. If your organisation genuinely evaluates you on shipped count, you can practise good thinking inside your own team and build a case, but do not pretend the pressure is imaginary. Know which fight you are in.
Quick check
Which habit most directly keeps a team stuck in the build trap over time?
The takeaway
The build trap is a measurement problem: when throughput is the scorecard, good teams optimise for shipping and lose the ability to notice it is not working.
Try this tomorrow
Pick one feature your team shipped two to three months ago. Spend an afternoon finding out how many people use it and whether the old behaviour it replaced actually stopped. Post the answer to your team channel with no spin, even if it is bad.
Answer the check above, then bank the day.
Where this comes from
- Escaping the Build Trap, Melissa Perri
- Inspired, second edition, Marty Cagan
- The Lean Startup, Eric Ries
Product Thinking is one of six tracks. These lessons summarise and build on the work above, they do not reproduce it. Buy the books, they are better.