Escaping The Build Trap: How Effective Product Management Creates Real Value By Melissa Perri
Last week, in the InVision Architecture Office Hours meeting, Shawn Hartsell recommended the book, Escaping the Build Trap: How Effective Product Management Creates Real Value by Melissa Perri. I'm not a Product Manager; but, the way Shawn talked about the book - touting "outcomes" over "output" - it tickled my curiosity. So, over the weekend, I picked it up and gave it a read. And, I must say that I loved it. One the one hand, it gave me a lot more insight into what Product Managers do and how they operate within a company; and, on the other hand, it gave me a lot more insight into how company culture plays into effective product development. And, unfortunately, how a toxic company culture can stifle innovation and adaptation. It's a quick read - definitely one that I would recommend to any technology team that builds a product or a service for customers.
Escaping the Build Trap talks about product management as a role and as a career track in the abstract (sighting real company details). But, it also follows the path of a ?fictional? company called "Marquetly" as it develops a new educational platform. In this respect, the book felt very reminiscent of The Phoenix Project by Gene Kim - which I also loved! I find the two-prong approach of mixing anecdotal story-telling along with business insights really helps to drive the points home in a way that connects with the reader's past experiences.
The company was running in too many directions. At one point, there were 20 major projects in progress. When I say major, I really mean major. A new mobile app was being developed, along with a new back-end system for the teachers to monitor their classes. These were large undertakings, meant for multiple teams, but only one product manager - and a junior one at that - and one development team were assigned to each.
.... Then the calls began pouring in. The site was breaking because the features they rushed to launch were not well tested. Teachers were frustrated because there was so much new functionality that got in the way of them trying to accomplish their most important tasks: creating courses and responding to student comments. Many of the teachers decided to take their courses down, and the account managers were left scrambling to bring them back.
A few weeks later, we checked in on the adoption of the features on the student side. Nothing. No one was using them. All that work, all those features, and Marquetly was still in the same place. Its revenue growth was declining, and the company was feeling the heat.
.... The build trap is a terrifying place for companies because it distracts them. Everyone is so focused on shipping more software that they lose sight of what is important: producing value for customers, hitting business goals, and innovating against competitors. (Part I)
I really love this style of writing because it gives me something that I can visualize - a movie that I can play in my head of what's going on at "Marquetly" and how people are feeling and responding to the unfolding events. It lends a palpable perspective to the concept of product management and helps me find a place for it in my evolving mental model.
When it comes to an organizational chart, I'll be honest - I don't have much of any sense of what people actually do. I'm an engineer - I know what engineers do. But, if you asked me to describe anyone else's role, I'm mostly at a loss. When I think about people at a company, it's usually in terms of whether or not that person enables me or prevents me from doing my job. As such, I found it really helpful to get a better sense of what Product Managers do, and why - good ones - are so critical.
They optimize the Value Exchange System. (Chapter 5)
.... Product managers connect the dots. They take input from customer research, expert information, market research, business direction, experiment results, and data analysis. Then they sift through and analyze that information, using it to create a product vision that will help to further the company and to solve the customers' needs.
To do that, a product manager must be humble enough in their approach to learn and take into account that they don't know all of the answers. They need to know that there are assumptions that they must tackle along the way, approaching them with a scientific mindset to validate them and to reduce risk. Ultimately, the goal for the product manager is that - reducing risk by focusing on learning. Most important, they need to know that not all good ideas are their own. (Chapter 7)
.... The product manager works with a development team and UX designers to ideate and build the right solutions for the customers. They are the ones on the ground floor, talking to users, synthesizing the data, making the decisions from a feature perspective. Product managers are usually responsible for a feature or a set of features that are part of a larger packaged product.
It's a difficult role. The product manager needs to be strategic enough to help craft the vision of the features and how they fit into the overall product but tactical enough to ensure a smooth execution of the solution. They tend to skew more operational than strategic at this level because the responsibilities are around the shorter-term impact and delivery of features on the roadmap. (Chapter 8)
I want to give a huge shout-out to Jonas Bučinskas, my former Product Manager at InVision. My team affectionately called him "the Ban Hammer" due to the way he aggressively prioritized feature development. Working with him was an absolute pleasure; and, after reading this book, I have a new level of respect for the work he was doing behind the scenes. And, for the mine-field of company politics that he almost certainly had to navigate.
Because - as it should be no surprise to anyone - a product manager, and their team(s), can only be successful if they are in a context that allows them to succeed!
These are the marks of a product-led company. Process and frameworks get you only so far on your way to success. Culture, policies, and structure are the things that really set a company apart to thrive in product management. (Chapter 19)
.... the quickest ways to kill the spirit of a great employee is to put them in an environment where they can't succeed. That's when most people leave. Even good product managers become tired of waking up and going to war every day. They spend too much time trying to change the policies so that they can succeed at their job rather than building the best product they can. (Afterward)
Giving people the power and the autonomy to act in the best interest of the company and the customer is so important! Communicate goals and priorities from the top-down; and then, allow the people "on the ground", closest to the customers, to translate those goals into action.
At Marquetly, the product managers were very frustrated by their lack of autonomy. One experienced product manager told me, "I keep having leaders tell me to own the vision of my product, but I'm not allowed. My manager keeps handing me solutions. Every time I try to suggest something different, I'm shut down. When we went Agile, we were told that our Scrum teams were supposed to be autonomous. This is definitely not autonomy." (Chapter 11)
One theme that kept coming up in the book was the importance of experimentation. This hit me so hard in the feels! I talk about experimentation all the time at work. And, how I think we should be trying a lot more random stuff to "see what sticks".
If I've learned anything from 15-years of blogging, it's that I have no idea which articles will actually get any traction. Sometimes, I'll pour my heart-and-soul into an article and it's nothing but crickets. Then, some other time, I'll write a small nothing post, and it blows up like wild-fire. You don't know what you don't know - you just have to keep trying, keep experimenting, and seeing what works.
ASIDE: I write primarily for myself, slowly compiling a tome of information that I can reference back to. I don't want you to think that I'm chasing them sweet, sweet page-views. But, I do find it fascinating which articles strike a chord and which don't.
In this regard, I absolutely loved that Perri redefines what it means to be an "MVP" (Minimum Viable Product); and, repositions it as a learning opportunity in that the most important part of the MVP is the information that we gather from it rather than the feature that we deliver with it.
This type of thinking is exactly what lands us in the build trap. 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.
Due to the misconception of this term, I have stopped using MVP altogether. Instead, I talk more about solution experimentation. These experiments are designed to help companies learn faster. Here we are experimenting to learn, not building to earn. We are not creating stable, robust, and scalable products. Often, we don't know what the best solution would even be when we begin experimenting. That is the point in doing this work. (Chapter 18)
I want to underscore that last statement so freakin' hard! So many times, I see people need to demonstrate the value of an experiment before they even have the permission to perform the experiment. But, that misses the point entirely. Right now - this moment in time - is when we know the very least information. In order to prove value, we have to build, measure, and evaluate. It needs to be a cyclical workflow; and, it needs to happen in a company culture that doesn't punish failure!
As you might sense, Escaping The Build Trap by Melissa Perri has me a bit riled up. Because, it demonstrates how important product management, experimentation, and a focus on "outcomes" really is. And, how so many companies get it wrong. If you develop a product or service, I definitely recommend giving this book a read. It offers an easy-to-consume perspective on how effective product development can work.
Reader Comments