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

by Melissa Perri

The build trap is when organizations become stuck measuring their success by outputs rather than outcomes. It’s when they focus more on shipping and developing features rather than on the actual value those things produce.

It’s something that can fuel your business: money, data, knowledge capital, or promotion. Every feature you build and any initiative you take as a company should result in some outcome that is tied back to that business value.

When companies do not understand their customers’ or users’ problems well, they cannot possibly define value for them. Instead of doing the work to learn this information about customers, they create a proxy that is easy to measure. “Value” becomes the quantity of features that are delivered, and, as a result, the number of features shipped becomes the primary metric of success.

Products, as I said before, are vehicles of value. They deliver value repeatedly to customers and users, without requiring the company to build something new every time.

Companies that optimize their products to achieve value are called product-led organizations. These organizations are characterized by product-driven growth, scaling their organization through software products, and optimizing them until they reach the desired outcomes.

Product-led companies optimize for their business outcomes, align their product strategy to these goals, and then prioritize the most effective projects that will help develop those products into sustainable drivers of growth.

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.

One of the worst traits a product manager can have is the lone wolf mentality—​the idea that they are the only one responsible for the success of their product.

Not having the right level of direction lands us in the build trap. Teams are given instructions that are either too prescriptive or too broad. Executives will get too far into the weeds, managing by authority and not allowing autonomy. Or teams could, as Bloom mentioned, be given so much freedom they are unable to act. That is why strategy deployment is key, from a product development perspective.

As discussed earlier, and as seen in Figure 15-1, The Product Kata is the process by which we uncover the right solutions to build. It’s a systematic way that teaches product managers to approach building products from a problem-solving standpoint. The Product Kata helps product people form incredibly impactful habits. Doing it over and over again, exactly like a martial arts kata, ingrains the process in your brain. After practicing for a while, this pattern of thought becomes second nature.

After we have set the goal, we begin walking through the Product Kata. We ask ourselves the following: What is the goal? Where are we now in relation to that goal? What is the biggest problem or obstacle standing in the way of me reaching that goal? How do I try to solve that problem? What do I expect to happen (hypothesis)? What actually happened, and what did we learn?

In addition to vanity metrics, I often see product teams measuring output-oriented metrics, such as the number of features shipped, story points complete, or user stories worked on. Although these are good productivity metrics, they are not product metrics. They cannot tie the results of product development back to the business. So we need a set of metrics that can help us do that. There are many product frameworks available to help you think through the appropriate product goals. My two favorites are Pirate Metrics and HEART metrics.

The experiment that Marquetly ran with its teachers is called a concierge experiment. Concierge experiments deliver the end result to your client manually, but they do not look like the final solution at all. Your customers will understand that you’re doing it manually and that it’s not automated. It’s one of my favorite experiment types because it doesn’t involve coding and it’s quick to get started. Because you get to work with your customers closely, there is a ton of feedback flowing through and there are tight learning loops.

Zappos actually started with this Wizard of Oz method. Back in the day, founder Nick Swinmurn wanted to see whether people would really buy shoes online. He put a simple website up on WordPress. Visitors could view and then buy the shoes online. But, on the backend, it was just Nick, singlehandedly running around, buying shoes from Sears and shipping them out from UPS himself, as each order came in. There was no infrastructure, no inventory of shoes, no person manning the phones. It was simply a page where the founder waited for orders. As soon as the orders came in, he went and fulfilled them. Through this approach, he validated that there was demand for buying shoes online without building out the entire site. That’s the Wizard of Oz method.

So, the company turned to a solution experiment. The team put together a rough video, demonstrating what Dropbox could do. It had not built a demo or a prototype but instead used video editing to demonstrate what it would look and feel like to the investors. It felt like a real product demo, even though it wasn’t a finished product. When the investors saw it, they went wild. To them, it was magic. Dropbox was able to secure its funding and to validate that it was on the right path.

Without the review meetings, Chris had been antsy because he could not see deeper into what was being done in a way that was meaningful to him. Most executives are just like Chris, so it’s important to have a cadence of communication that shows progress at every level of the organization, tailored to each specific audience.