Book highlights: Escaping the Build Trap: How Effective Product Management Creates Real Value

It doesn’t matter how good you are at making software, if you are building the wrong thing. Melissa Perri’s Escaping the Build Trap is an excellent book about fostering culture focused on customer’s problems and producing value. A way too common pitfall is focusing on building features, based on vague, unverified ideas of what customers need or want. (This is the build trap, a.k.a. feature factory trap.) But, as the books says, we should love the problem, not the solution. And we need to assume that we don’t know perfectly what the customers need. I would add, that we can surely build tons of useful features - but the hard question is, which time & effort investments are the most valuable ones, and where the cost of writing and maintaining the code and the consequential increase in complexity are not worth it. Remember, every line of code is a liability.

I have already been pretty much of this mindset (after all, I have read and appreciated The Lean Startup years ago), but still I learned useful things, and remembered others. Some highlights follow. They are rather personal, for a more objective and thorough overview, I highly recommend Julia Park’s 11 Key Learnings from this book.

One thing that inspired me a lot was Ms Perri’s mention of a company that had a rather small team and was thus forced to maintain a laser-sharp focus on what delivered most value to the customer. IMO big team = many features = lot of complexity and little clarity. Small team = great focus on value, less ballast. This also reminds me of the inspiring story of John Boyd’s design of the excellent F16 figher jet, which focused on a single quality, namely manuveurability. He wasn’t able to resist all the goldplating attempts of all the generals and contractors, but still managed to build the best fighter jet of all times. Compare it to F35, which is a jack of all trades, but master of none, many years and billions over budget. So it would seem that clear and strict product focus must come first, though I am sure that small team size helps with that. Anyway, I digress.

Don’t love the solution, love the problem. Deeply understand your customers and their problems. Never assume you know what the problem or solution is. Experiment, learn, and measure how well the feature/product delivers values. Outcomes (effect on key business metrics) over output (i.e. features).

Strategy isn’t a plan but a framework for taking decisions aligned with the org’s vision.

Metrics - the “pirate metrics” AARRR (acquisition, activation [when the user actually starts using the product], retention, revenue, recommendation to others <> Net Promoter Score) and HEART (happy users, engagement, acquisition, retention, task success).

Hierarchy: Vision → Strategic intent → Project initiatives → Options [i.e. something that might bring us where we want to get, but needs to be proven first]

Toyota Product Kata: where do we want to be, where are we, what is the biggest obstacle, what can we do to learn, what do we expect to happen after we run the “experiment”, what did we learn? Repeat.

Make sure company budgeting rules do not prevent product discovery - instead of a yearly budget, assign money in stages in shorter cycles, allotting them based on the potential value vs. uncertainty - small amounts to initial experiments, more to later stages, most to projects that have already proven that their deliver value.

A good way to prioritize is Cost of Delay, i.e. by considering Urgency (every moment of delay means we are further from hitting our goals) vs. Value (solves the strongest customer problem/desire).

The 6 question for self-assessment of whether an org is product led: