Escaping the Build Trap: the book that teaches FDEs to measure their work by client outcomes, not feature counts

An engineering team can ship every feature on schedule and still fail. Melissa Perri has a name for this: the “build trap”, in which companies live and die by output and keep pushing features out to hit deadlines.

Her book, Escaping the Build Trap: How Effective Product Management Creates Real Value, was published by O’Reilly in 2018. The cover says product management. For anyone aiming at an FDE role, though, it reads more like a guide to not becoming a feature shop that builds to a client’s order.

When you work on site and build close to users, speed is the most visible thing you produce. That is exactly why the trap is hard to spot: the more you ship, the easier it is to feel the project is going well.

The problem is the metric, not the effort

The book’s definition is short: the build trap is when an organisation is stuck measuring success by output rather than outcome. getAbstract’s summary puts the same idea another way: companies often value what they ship over the value customers actually receive.

Output is what the team produces: features, APIs, screens. Outcome is what changes for the customer because of them. Perri does not say output is bad. At ProductCon 2022 she called output a means to an end. According to Dragonboat’s notes, the trap appears only when there is no clear goal and the team just goes “build, build, build”.

Picture yourself as an FDE rolling out an invoice processing system for a logistics company. After six weeks, the report shows nine features delivered and not a single missed deadline. Yet accountants still spend about 40 minutes on each invoice, just as they did before you arrived. Judged by output, the project is a success. Judged by outcome, nothing has changed.

Now reset the goal in week one: cut the time to process one invoice from 40 minutes to 15. Quite possibly only three of those nine features were needed, and the six weeks would have been better spent sitting next to the accountants to see where they get stuck.

Strategy is a filter, not a plan

The second idea that matters for FDEs is how the book defines strategy. For Perri, strategy is a decision-making framework that can be put to use immediately, helping a team act to reach the outcome it wants. It is not a plan that lists tasks.

At a client’s company, the difference is practical. Back to the invoice example: midweek, the head of finance asks for a button that exports reports to PDF. If all you have is a plan, you ask whether the request is in scope.

If you have a decision framework, you ask whether it helps bring that 40-minute figure down. If it does not, you have a clear reason to push it back, and one the client can understand.

That is why the lesson suits FDEs even better than office-based product managers. FDEs hear requests directly every day, and every yes adds another output. Without a filter, the backlog becomes the wish list of whoever speaks loudest in the meeting.

Misapplied, outcomes become a trap too

The easiest mistake after finishing the book is to turn outcomes into a shield for refusing every request. That PDF button may be what the head of finance needs to present figures to their boss, which means it serves a real problem you have not yet heard about. Before saying “not yet”, ask what they need it for.

The next mistake is picking an outcome that cannot be measured, such as “a happier client”. The 40-minute figure is useful precisely because it can be measured before and after. A goal you cannot measure cannot filter anything.

The last mistake is setting the outcome yourself and keeping it in your head. If the client has not agreed to the 15-minute target, your filter is just a personal opinion, and every refusal turns into an argument. Agree the number with the client in the first week.

The book’s page on Perri’s website describes the destination as building a customer-centric culture that focuses on outcomes over outputs. An FDE cannot change the culture of an entire client company. But you can bring that way of thinking into every meeting, every ticket and every weekly report.

Who should read it, and how

The book suits developers with two to eight years of experience who are used to taking tickets and closing them, and who now want a role where they decide what to work on. Read it before your first deployment, because the trap is easiest to fall into in the first few weeks, when you are trying to prove you can deliver.

Do not read it in one sitting and put it away. After the section defining the build trap, open the backlog of your current project and write a measurable outcome next to each item. When you reach the section on strategy, try writing a one-sentence goal for your current client that is specific enough to use as a filter.

When you read FDE job descriptions, notice whether they talk about impact on clients or just list technologies to know. On your CV, replace “built 12 endpoints” with a line that has a before-and-after number on the user’s side. A line like that shows the reader you already think in outcomes, which is exactly what this book teaches.

At a client’s company, nobody remembers how many features you shipped. They remember what became faster, cheaper or less painful after you arrived.