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

by Melissa Perri

I soon realized that it was not just the product managers that were stuck in the build trap, but the entire organization. Solving the processes for the team was not enough. It was about setting up the entire company to support good product management.

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.

When the teams did not have anything to ship by the third month, the leadership team became incensed. “They are not doing their jobs!” said the CEO. “We need to ship more features. Why are they not prioritizing better?” All fingers pointed back to bad product management. But that wasn’t the actual problem.

“Leadership told me to do this. I have to ship this, or I won’t get my bonus.” They were handicapped by poor planning and poor strategy.

They skipped the user research that they had been so steadily doing; it took time away from them writing up user stories for the development team. They all began focusing on getting as many features as possible out the door.

“A lot of it is due to having too many priorities. Everything is number one on your project list.

You tie people’s bonuses to shipping software, not to solving problems. They think they have to ship or they won’t get paid,” I said.

You have to become product-led. That involves shifting the entire mentality of the organization from delivering to achieving outcomes. You will have to change your structure, your strategy, and not only the way you work but also the policies and rewards governing it.”

Microsoft, although not in danger of failing immediately, was on the path to disruption. It had been using the same strategic recipe over and over again, counting on Windows to carry its business, until CEO Satya Nadella came in.

The build trap isn’t just about shipping software. It’s about realizing you have to change the way you’ve always done things. It’s about confusing output-centric measures of progress with real measures of value. To get out of the build trap, you need to look at the entire company, not just at the development team.

Companies end up in the build trap when they misunderstand value. Instead of associating value with the outcomes they want to create for their businesses and customers, they measure value by the number of things they produce.

Value, from a business perspective, is pretty straightforward. 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.

I once worked with a company that made a data platform for enterprise companies. It had a total of 30 features, with about 40 more on the backlog, when I came in. When I measured the customer use of those existing features, we discovered people used only 2% of them consistently. And yet, development was underway to add more, instead of trying to reevaluate what they already had.

Outputs are easily quantified things that we produce—number of products or features, number of releases, or velocity of development teams. Outcomes are the things that result when we finally deliver those features and the customer problems are solved. True value is realized in these outcomes, both for the business and for the user or customer.

To be strategic and to have people operate strategically, we need to stop judging teams based on the quantity of features shipped. We should instead define and measure value and then celebrate them for delivering on outcomes for our business and users.

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.

A project is a discrete scope of work that has a particular aim. It usually has a deadline, milestones, and specific outputs that will be delivered. When projects are complete, the aim is reached, and you move on to the next one.

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.

Sales-led companies let their contracts define their product strategy. Remember my example of the data platform that had 30 features that no one used? That was a sales-led company.

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.

“Start listening to your team. Involve them. Listen to your customers and focus on their problems instead of your own solutions. Fall in love with those problems. Also, go seek out data to prove and validate your ideas. Turn to concrete evidence, rather than opinions.”

The product death cycle is a specific form of the build trap. You are implementing ideas without validating them.

Pushing back is essential to building a successful product. That’s part of the job.

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.

Product management is about looking at the entire system—the requirements, the feature components, the value propositions, the user experience, the underlying business model, the pricing and the integrations—and figuring out how it can produce revenue for the company.

One of the biggest mistakes companies make in hiring a product manager is trying to find either a technical or market expert. Product managers are not experts in either of these domains; they are experts in product management.

The product manager carefully balances the line between all disciplines to be able to strategize and decide what is best for the product. A great product manager listens intently to the inputs given from all their team members, but, at the end of the day, they make the difficult choices about what will be best for the business and the user.

how did she decide which pain points to solve? Well, Meghan had already worked with her VP of product to identify the business goal that aligned with the vision of her department: to increase the amount of first-time applications that are submitted.

Her goal was to improve that percentage. So, as she evaluated the customer needs and the problem points in their mortgage service offering, Meghan asked herself, “Will this help us increase the likelihood that these people will finish their application with us?”

Meghan brought her team members, the developers and UX designer, to user research sessions periodically so that everyone could clearly understand the problems. Soon they found a pattern: many of the potential clients were asked to come to the office to verify documents, given that this could not be done online.

Now that she had identified the problem, Meghan called the team together in a working session to generate ideas for a solution. They were careful not to jump to conclusions immediately, and they came up with several ways to solve the problem, while deciding to run a few short experiments to see which solution was the best.

“The biggest thing I’ve learned in product management is to always focus on the problem. If you anchor yourself with the why, you will be more likely to build the right thing,”

Why are we making everything digital in the mortgage space? Why even do this project? What’s the desired result that we hope to achieve here? What does success look like? What happens if we make it all digital and nobody applies for mortgages? How are we mitigating that risk?

Too often, product managers dive into creating solutions without thinking through the associated risks. Each of the aforementioned questions represents a risk for Meghan that could potentially kill her project.

They are handed features and solutions from stakeholders or managers. Sometimes, these features are determined and committed during annual budgeting season.

When done this way, you invite the risk of failure, due to bias, in the execution of those solutions. All solution ideas are subject to bias, organizational or personal. The only way to fight this bias is to learn from users and to experiment.

In many cases when organizations hand down solutions, they skip setting suc...

The biggest issue I hear from leaders, when I go in to help their organizations become product-led, is that their product managers won’t step up and “own the product.” But, this is a double-edged sword. In many cases, the product manager can do more to lead the product. They can question solutions and push back on things handed down. But the work required to gather data and prove the solution takes time. This is where people usually become confused between what Agile calls a product owner and a product manager.

Although Scrum has a lot of information on the processes and rituals of what to do as a product owner, it leaves lots of questions unanswered and these questions are important for creating successful products: How do we determine value? How do we measure the success of our products in the market? How do we make sure we are building the right thing? How do we price and package our product? How do we bring our product to market? What makes sense to build versus buy? How can we integrate with third-party software to enter new markets?

Product management and Scrum can work well together, but product management is not dependent on Scrum.

Most organizations do not give their people the necessary time to do product vision and research work. They would rather hold them responsible for a steady stream of outputs and measure success based on stacking backlogs and writing stories.

Too often, companies don’t know what product managers are supposed to do or why they’re important. I’m routinely told that people don’t even think their company needs product managers.

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. The amount of external versus internal work will shift, depending on the maturity and success of your product. But, you should never be doing all this work at once.

I teach my clients that product managers in senior roles (VPs, product leads, or middle managers) concentrate on defining the vision and strategy for the teams based on market research, an understanding of company goals and strategy, and by looking at the current state of success of their products. The product managers without Scrum teams or with smaller teams (a UX designer and one developer, for example) help validate and contribute to that strategy for future products. After we validate the direction, we create larger Scrum teams around these people and build out solutions.

It’s important to have this flexibility in team size, as well, depending on the stage of your product. If you give a product manager a large Scrum team’s backlog to maintain while you are in discovery mode, they will keep that backlog filled. But they will also be torn between keeping wor...

Tactical work for a product manager focuses on the shorter-term actions of building features and getting them out the door.

Strategic work is about positioning the product and the company to win in the market and achieve goals.

Operational work is about tying the strategy back to the tactical work. Here is where product managers create a roadmap that connects the current state of the product to the future state and that aligns the teams around the work.