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.

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. Anyone can run with solutions based on known knowns. Those facts are readily available. But it takes a certain skill to be able to sift through the massive amounts of information and to identify the right questions to ask and when to ask them.

Think of all of the different roles in a company, from sales and marketing to tech and design. So many of these functions don’t cross over much between the tech side and business side. Product managers are the ones who fit right in the middle and translate needs into a product that will satisfy the customer while sustaining and growing the business.

Product managers are not the mini-CEOs of a product, yet 90% of the job postings I have seen for product managers describe them as being the mini-CEO. CEOs have sole authority over many things. They can fire people. They can change up teams. They can change directions. Product managers, on the other hand, can’t change many of the things a CEO can in an organization.

They don’t believe that they can push back on these solutions and dive deeper into problems. But that’s not true. Customers want their problems solved. Leaders want to hit goals. Pushing back is essential to building a successful product.

Product managers are responsible for the why? Why are we building this? How does it deliver value to our customers? How does it help meet the goals of the business?

With a good strategy framework in place and ruthless prioritization around a few key goals, one person can effectively talk to customers, understand their problems, and help to define the solutions with the team.

If companies want excellent product managers, they need to begin growing them.

To organize teams effectively, you need to balance the coverage and scope of teams with the goals you are trying to achieve.

When organizations lack a coherent product strategy that is ruthlessly prioritized around a few key goals, they end up spreading themselves thin.

A good strategy is not a plan; it’s a framework that helps you make decisions. Product strategy connects the vision and economic outcomes of the company back to product portfolio, individual product initiatives, and solution options for the teams. Strategy creation is the process of determining the direction of the company and developing the framework in which people make decisions. Strategies are created at each level and then deployed across the organization.

Good strategy isn’t a detailed plan. It’s a framework that helps you make decisions.

Instead of seeking more detailed information, upper management should be limiting its direction to defining and communicating the strategic intent, or the goals of the business. The strategic intents combine to communicate where the company is heading and what it desires to achieve when it gets there. The strategic intent points the team toward the outcomes the businesses wants to achieve.

One of the biggest mistakes I’ve seen in product management is teams rushing in to apply a tool or practice at the wrong stage. Many times, they are experimenting unnecessarily when the problem is not yet known or when there is already a good idea about the solution.

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. Why? Because it involves talking to (gasp) people. It takes a lot of effort to line up the interviews, and sometimes that can seem more daunting than staying inside and jumping right into A/B testing or sifting through data.

The method I suggest for reaching a broader audience for feedback is called the Wizard of Oz. The idea behind the Wizard of Oz is that, unlike the concierge experiment, it looks and feels like a real, finished product. Customers don’t know that, on the backend, it’s all manual.

Although concierge, Wizard of Oz, and concept testing are all good techniques, sometimes you don’t need to experiment so heavily around multiple concepts. It is important to remember that these tools are used for higher amounts of uncertainty and, thus, larger risk in your solution ideas.

If a good experiment helps you learn, you can always find a way within your constraints. Making known the unknown reduces risk, and that goes for large, bureaucratic companies like banks, as well as for industries with long product development timelines, like aviation. There is no excuse for not learning.

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 ...

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 se...

Tying livelihoods to the fact that you shipped product at all, instead of learning or solving problems for customers, is what gets people into the build trap.

You should be rewarding people for moving the business forward—achieving outcomes, learning about your users, and finding the right business opportunities. At the end of the day, the rest is just vanity metrics.

Product-led companies invest in and budget for work based on their portfolio distribution and the stage of their work. This means allocating the appropriate funds across product lines for things that are known knowns and ready to be built, and it means setting aside money to invest in discovering new opportunities that will propel your business model forward. They then allocate more and more funds to grow the opportunities as they become validated.

This is the core of what it means to be customer-centric—​to put yourself into your customers’ shoes and ask, “What would make my customers happy and move our business forward?” In the beginning of this book, we talked about product management being a value exchange. Being customer-centric allows you to figure out what products and services will fulfill that value on the customer side.

Who came up with the last feature or product idea you built? If I ask a product manager this question, I hope to see a look of confusion on his or her face. “What do you mean who came up with it? Well, our team did. Right? That’s how it normally works.” This kind of response is a sign of a healthy product management organization, in which management sets the goals and the team is given room to figure out how to reach them.

What was the last product you decided to kill? Another sign of an unhealthy product management culture is the inability to kill a product or idea that will not help a company reach its goals. If you hear, “We never really kill anything,” it often means that there’s a pretty big problem.

When’s the last time you talked with your customers? What I dread hearing is, “Oh, well, management doesn’t really let us talk to customers. They’re worried about us annoying them too much.”

What is your goal? This is the first question I ask any product manager during an interview process.1 If the product manager cannot articulate a clear goal, it’s a sign of poor product management at the organizational level.

What are you currently working on? A truly successful product manager talks more passionately about the problems the product development team is solving than the solutions they are shipping.

What are your product managers like? As product managers, we want to work in an organization where the role is respected and well regarded. I’ve seen many organizations where the product management function was not well-respected. There were two causes: product managers were either seen as too strong, or they were seen as too weak.