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.

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.

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

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.

Strategy is a deployable decision-making framework, enabling action to achieve desired outcomes, constrained by current capabilities, coherently aligned to the existing context.

Strategies are interconnecting stories told throughout the organization that explain the objective and outcomes, tailored to a specific time frame. We call this act of communicating and aligning those narratives strategy deployment.

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? We do answer questions one through four to figure out how to plan our next move as a team. Then we reflect on that work in questions five and six and determine whether to go back to the beginning for the next round.

Pirate Metrics were created by Dave McClure, founder of 500 Startups,

Kerry Rodden, a Googler, created the HEART metrics to account for this.

Rodden’s article, “How to Choose the Right UX Metrics for Your Product.”

Giff Constable wrote an entire book, called Talking to Humans

User research, in this case, is not to be mistaken for usability testing, which involves showing a prototype or website and directing people to complete actions.

There, you are learning whether they can use and navigate the solution easily, not whether the solution actually solves a problem. This type of research is called evaluative

Problem-based user research is generative research, meaning that its purpose is to find the...

Concierge, Wizard of Oz, and concept testing are three examples of solution experiments, each of which I explain shortly.

Story mapping and North Star documents are two ways to help teams find alignment around the vision.

North Star document explains the product in a way that can be visualized by the entire team and company. This includes the problem it is solving, the proposed solution, the solution factors that matter for success, and the outcomes the product will result in.

Story mapping helps teams break down their work and align around goals. As Patton says, “Its purpose is to help the team communicate about their work and what needs to get done to deliver value.”

The Principles of Product Development Flow, Don Reinertsen talks about the importance of Cost of Delay in prioritizing work.

Ozlem Yuce and Joshua J. Arnold are the experts in Cost of Delay, and they have created a qualitative way to assess it, as illustrated in Figure 19-1. Figure 19-1. Qualitative cost of delay, by Joshua Arnold and Ozlem Yuce (reprinted by permission of Joshua Arnold and Ozlem Yuce) In

Black Swan Farming and read about how to utilize the concept in your company.

Jeff Gothelf, the author of Sense & Respond, once said, “Version 2 is the biggest lie in software development.” This mentality always leads to the build trap.

One great resource for determining how to set a roadmap is C. Todd Lombardo and Bruce McCarthy’s book, Product Roadmaps Relaunched

I recommend aligning your company around certain terminology to determine stages of development so everyone understands which activities are happening. We use these four phases:

Experiment This phase is to understand the problem and to determine whether it’s worth solving. Teams in this phase are conducting problem exploration and solution exploration activities. No production code is being created. Alpha This phase is to determine whether the solution is desirable to the customers. This is a minimum feature set or a robust solution experiment, but built in production code and live for a small set of users. These users understand that they are getting early access to a feature that might change or be killed, if it is not solving their problems. Beta This phase is to determine whether the solution is scalable, from a technical standpoint. Although not always needed, this is a good phase to reduce risk. This release is available to more customers than the Alpha phase, but is still only a smaller subset of the entire population, since we are still testing. At this point, we’ve proven that the solution is desirable to customers, so it is unlikely that this feature will be killed unless it is not technically stable. Generally Available (GA) This phase means that the solution is widely available to all of our clients. Sales teams can talk openly about GA products and can sell as much as possible to the target market.