Quotes & Notes on “Escaping the Build Trap” by Melissa Perri

The build trap is when organizations become stuck measuring their success by outputs rather than outcomes.

I guess this relates to a point made in Accelerate about measurement models. It’s preferable to use a capabilities model of measurement to continuously know if your product is where you want it to be, rather than a maturity model that tells you if your product has reached a certain state.

Product management is the domain of recognizing and investigating the known unknowns and of reducing the universe around unknown unknowns. 

Observability is also about unknown unknowns and deep down it all goes back to testing. But hey, I might be biased here.

Agile does indeed promote a better way of collaboration and a faster method of building software, but it largely ignores how to do effective product management. Agile assumed that someone was doing that front-of-funnel part, generating and validating ideas, and instead optimized the production of software. 

That is my experience so far, both as part of a development team and as product owner. While I was in the development team, I wondered why there was no feature after feature roadmap with clear acceptance criteria to work on. As a product owner, I was struggling to create such transparency on a regular basis, as there was not enough time for user research to come up with any meaningful hypothesis. 

The real role of the product manager in the organization is to work with a team to create the right product that balances meeting business needs with solving user problems. 

To organize teams effectively, you need to balance the coverage and scope of teams with the goals you are trying to achieve… A value stream is all of the activities needed to deliver value to the customer. That includes the process, from discovering the problem, setting the goals and conceiving of the idea, to delivering the actual product or service. Every organization should strive to optimize this flow in order to get value out of the door faster to customers. To do that it makes sense to organize your teams around the value stream.

I should finally start reading my copy of Team Topologies…

You can easily turn a vanity metric into an actionable metric by adding a time component to it. Do you have more users this month than last? What did you do differently? Think carefully about how to add context and meaning to your facts and figures. 

I find this a useful tip that can be applied to all kind of metrics and not only to product ones. Do we have less flaky tests this month than the last? If yes, what did we change to achieve this?

Product managers are often spoken about as the “voice of the customer”, yet too many of us are not getting out and talking to customers as much as we should.

Gasp! I thought testers are the “voice of the customer”. Thinking back, how often did I actually talk to our users?

Kill the bad ideas before they take up too much time and energy from the teams and before you get hooked on them. Instead, fall in love with the problem you are solving.

This reminds me of the Pets vs Cattle analogy for servers. Sometimes we love a feature that we have implemented so much, that it is hard to let it go, even if it is not used by anyone. Software capabilities are there to serve our users and not to showcase our work. 

When we use an MVP only to get a feature out quicker, we’re usually cutting corners on a great experience in the process. Thus, we sacrifice the amount we can learn from it. The most important piece of the MVP is the learning, which is why my definition has always been “the minimum amount of effort to learn”. This keeps us anchored on outcomes rather than outputs. 

I plan to keep this quote in mind for the next time that someone wants to get something out of the door as “good enough”. If we consciously know what we are leaving out, it is easier to have a contingency plan for the next steps we need to take.

We are done developing or iterating on a feature only when it has reached its goals. Often, teams ship a first version of the feature and then move on to the next, without measuring the outcomes for the user.

I think that it is even worse than that. When we don’t measure the outcome for the users then we don’t prioritize the user feedback on the shipped feature highly enough. Because in our heads, we are done and the user request is just an improvement but for the user it might be a deal-breaker.  

If you look at some of the best companies out there today -Amazon, Netflix, and Google, for example- they are not reactively building whatever customer request comes their way. They are not following Agile processes blindly to build whatever features they can, as fast as they can. Instead, they are developing products with the intent to deliver value to their customers.

---

Check Quotes & Notes for a full list of the books I have taken notes on.

I have taken all precautions to cite everything clearly, but if you are an author of this book and you feel that there is too much content of your book exposed or any other violation, please contact me so that we can correct that.