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. When companies stop producing real value for the users, they begin to lose market share, allowing them to be disrupted. Companies can get out of the build trap by setting themselves up to develop intentional and robust product management practices. At that point, product managers can find the opportunities to maximize business and customer value.

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.

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. Are you optimizing your organization to continually produce value? Are you set up to grow and sustain products as a company? This is what a product-led organization does.

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. Marquetly was a clear example of this when the leaders celebrated the 10 features the company shipped in a single month, but none of those features achieved their goals.

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.

The company also overpromised during the sales process, giving customers whatever it took to get the contract signed. The result was a ton of one-off features that satisfied the needs of only one client, rather than a strategic choice to build what would scale for many clients.

You have to get to know your customers and users, deeply understanding their needs, to determine which products and services will fulfill needs both from the customer side and the business side. This is how you develop the Value Exchange System, as illustrated in Figure 1-3. To gain this understanding, companies need to get their employees closer to their customers and users so that they can learn from them, which means having the right policies throughout the organization to enable this.

Technology is critical to a software company’s success, but it cannot drive the product strategy. The product strategy must lead. Companies that let their technology lead the way often find themselves spinning their wheels, producing lots of very cool things, with no buyers. Product strategy connects the business, market, and technology together so that they are all working in harmony. You need to be able to lead with a value proposition for your users, or you will not be able to make money.

When kicking off a project, it’s best to begin by identifying what you know to be true about the situation—your known knowns. These are facts that you gather from data or critical requirements from customers. Now not all perceived requirements are necessary, but some of them are. These could be mandated by government regulations, or they could be basic needs that are required to do the job. You need to separate these items out as facts and to label those that you are unsure about as our known unknowns. Known unknowns are clarified enough that you know which question to ask. They are assumptions that you want to test, data points that you can investigate, or problems that you can identify and explore. You use discovery methods and experimentation to clarify these, turn them into facts, and build to satisfy those facts. Unknown knowns are those moments when you say, “I feel like this is the right thing to do.” This is intuition from years of experience. Although we should all listen to our intuition, you should also be cautious because this is often where bias thrives. It’s imperative to check and experiment to see whether your intuition is right. The unknown unknowns are the things that you don’t know you don’t know. You don’t know enough to ask the right questions or identify the knowledge gaps. These are the moments of surprise that need to be discovered. They happen when you are out talking to customers or you are analyzing seemingly unrelated data. They pop up during re...

The product death cycle is a specific form of the build trap. You are implementing ideas without validating them. It’s not the customer’s job to come up with their own solutions. That is your job. You need to deeply understand their problems and then determine the best solutions for them.

Answering why is very different than answering when. It requires a strategic mindset that understands the customer, business, market, and organization. This is a critical skill set for a great product manager.

One of the biggest misconceptions about the role of a product manager is that they own the entire product and therefore can tell everyone what to build. Act this way, and you will only alienate the rest of your team. Product managers really own the “why” of what they are building. They know the goal at hand and understand which direction the team should be building toward, depending on company strategy. They communicate this direction to the rest of the team.

A product manager must be tech literate, not tech fluent. That means they can discuss enough and understand enough about the technology to talk to developers and to make trade-off decisions. They know the right questions to ask engineers to understand the complexity of certain features or improvements. A product manager doesn’t need to be able to code unless the product is highly technical and it’s essential they understand the technology deeply to make decisions. The same goes for the market. Although it’s valuable for a product manager to know the market well, this is something they can learn. This is all about balancing the skill sets of your team. If you have highly-skilled market analysts, a great product manager knows how to talk to them, learn from them, and harness their skills.

Product ownership is just a piece of product management. A good product manager is taught how to prioritize work against clear, outcome-oriented goals, to define and discover real customer and business value, and to determine what processes are needed to reduce the uncertainty about the product’s success in the market. Without this background in product management, someone can effectively go through the motions of the product owner role in Scrum, but they can never be successful in making sure that they are building the right thing. In other words, product owner is a role you play on a Scrum team. Product manager is a career.

They were actively working on a technical component that was already in a steady state, where it was optimized and functional. This did not need to be worked on to achieve the company goals, and yet here she was creating work for her team because she had been told it was what she owned and could work on. A similar issue happens when teams are organized around specific features. A lot of teams do this to get coverage—ownership over every part of the product. Although this is good if you are literally starting from scratch and do not have a product organization set up, but, over time, it promotes a very output-oriented mindset. Instead of working toward a goal and saying no to anything that doesn’t get us there, we tend to look for ways to develop more things related to our little slice of the product. If we take a step back and align the work of these teams to the overall vision of the product and strategy (which we talk about in the next section), we find that much of that work really shouldn’t have been prioritized. When features are stable, we should monitor them but then move on to the more important work needed to support our strategy.

A value stream is all of the activities needed to deliver value to the customer. That includes the processes, from discovering the problem, setting the goals, and conceiving of the idea, to delivering the actual product or service. Every organization should strive to optimize this flow in order to get value out the door faster to customers. To do that, it makes sense to organize your teams around the value stream.

Consider an insurance company. The products for an insurance company are what they sell to customers: car insurance, home insurance, life insurance, and so on. I buy car insurance because it provides me with peace of mind in case I get into an accident—that’s value. Having an iPhone app that allows you to manage your car insurance, for example, is only a piece of that product’s value stream. That app can help get me more information on my insurance policy or find options if I get in an accident. This functionality is valuable to me, but the app on its own is not enough value. I still need the car insurance product. You can still have a product manager owning that iPhone app’s experience, but you must make sure that they are part of the larger division that holds the true value—the car insurance division. This structure makes it possible to set strategy at the division level, with the product manager able to execute on product initiatives that tie to their product. Keeping the strategy and the value execution together is key. This approach allows you to really evaluate the work happening on your teams and to make sure it’s essential to achieving your strategy.

For example, you want to grow the teacher platform such that they can upload their videos and create courses. Right now, you have four different product managers working on it, but no one is responsible for the overall vision. There is no driving consensus on what that platform will be. Karen has a strong vision for the teacher experience, but she can’t manage both the student experience and that at the same time. I would find another VP of product to take over the student experience.”

Hastings realized that if he launched a hardware device, he could not partner with anyone else. He would be in the business of hardware, not software or entertainment. That wasn’t part of the Netflix core vision. So, he made the hard call and decided to stop a project, even when it was so close to being done, because it did not align with the overall strategy. Instead, Netflix spun off Project Griffin as a separate company, which you know today as Roku. Then it turned its sights to finding a partner with a device for which they could build an app. They approached Microsoft, and, six months later, Netflix was enabled on more than one million Xbox devices, accomplishing the goal of gaining more streaming customers.

It’s easy to become distracted, as Hastings explained in an interview with The New York Times:4 After we eventually won the Blockbuster battle, I looked back and realized all those things distracted us. They didn’t help, and they marginally hurt. The reason we won is because we improved our everyday service of shipping and delivering. That experience grounded us. Executing better on the core mission is the way to win. Luckily, the company realized this sooner rather than later, and, by turning back to its strategic framework and core mission to make people happy, it was able to get out of the build trap and remain out. This has made Netflix one of the most successful software companies to date.

A deluge of information isn’t always that helpful for upper management. You need to focus on communicating and asking for just enough information to make a decision. 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.

Leaders will still go through the ranks demanding more detailed information. Often, this is perceived as a lack of trust, and often it is, but there’s usually something more there. In every organization where I’ve seen leaders operate this way, the story is not complete. Typically, there’s a lack of alignment, and the goals of the team do not line up to an overall vision and strategy of the company. This Alignment Gap is what truly causes the demand for more and more information.

Product teams need the freedom to explore solutions and to adjust their actions according to the data they receive. As long as they are aligned with the overall strategic intents and vision for the company, management should feel comfortable granting the necessary autonomy to capable teams.

Instead of sending down mandates, organizations should, instead, turn to aligning every level of the company around the why and should give the next layer down the opportunity to figure out the how and report back. When done this way, product management is successful. When leadership is not aligned at the top, the issues trickle all the way down to the teams.

We’re hiring incredibly smart people and paying them hundreds of thousands of dollars to make the decisions on how to grow companies by making complex software that customers love. When you have that sort of talent, you need to give them the room to make decisions so that you can get the full benefit of their knowledge and skill.

Think of the major pieces of work you do that are actually bets. Henrik Kniberg, a former consultant at Spotify, explains that this is how Spotify thinks.1 The company operates using something called DIBBs, which stands for Data, Insights, Beliefs, and Bets. The first three things, data, insight, and beliefs, inform a piece of work called a bet. The concept of thinking of initiatives as bets is powerful because it sets up a different type of expectation. Spotify maintains innovation by not establishing mandates about what to build from a higher-up perspective. Managers give employees the leeway to participate in hackathons and to implement their ideas. They set up an environment in which it’s safe to try new things and fail. Upper management is willing to embrace uncertainty about what customers want, and, by doing so, they create a work environment that embraces experimentation and innovation and that can course-correct quickly, when necessary.

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.

The chief product officer (CPO) is responsible for setting the direction and overseeing the product portfolio. Having a philosophy for how your products or services help your company reach that vision in the near term or long term is key. To get there, the CPO answers these questions for their team: How do all of our products work as a system to provide value to our customers? What unique value does each of the product lines offer that makes this a compelling system? What overall values and guidelines should we consider when deciding on new product solutions? What should we stop doing or building because it does not serve this vision?

It’s not that you don’t have time to innovate; it’s that you are not making time to innovate. To find that space, you’re going to need to say no to some things. We’re all bogged down by work, and there are always a million things you could be doing that will pay off tomorrow. If you want to be innovative, you actually need to dedicate teams to this and make space in your portfolio to make sure that all of this happens.

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?

A good example of this is a checkout page on an e-commerce website. If you don’t want to get into the business of being a checkout service for other e-commerce companies, don’t spend all your time here. There’s lots of experimentation that has already happened around this particular solution, and you can harness that. I should know. I researched this heavily when I worked at an e-commerce company. If you can, learn from those who have optimized already, implement their best practices, and tweak from there. When that’s not an option, you have a chance to explore adjacent areas or to chart your own path.

Pirate Metrics were created by Dave McClure, founder of 500 Startups, to talk about the life cycle of users through your product. Think of it as a funnel (Figure 16-1): users finding your product is acquisition; users having a great first experience is activation; keeping users returning to your product is called retention; users recommending others because they love your product is referral; and, finally, users paying for your product because they see value in it is revenue. Put it all together and you get AARRR—Pirate Metrics. Get it?

The difference between activation and acquisition is usually the most difficult to understand on this framework. Acquisition is that users land on your site and sign up. This is what they were measuring at Marquetly. Activation is when someone takes the first step with your product toward having a great experience. For Marquetly, that would be taking the assessment so that they understand which courses to take. Activating people well at the beginning leads to retention down the line.

Although Pirate Metrics became very popular, some people saw the flaw that it did not talk about user satisfaction. Kerry Rodden, a Googler, created the HEART metrics to account for this.

HEART metrics measure happiness, engagement, adoption, retention, and task success. These are usually used to talk about a specific product or feature. Here, adoption is similar to activation in Pirate Metrics because you are talking about someone using the product for the first time. Retention is the same as in Pirate Metrics.

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 problem you want to solve. It involves going to the source of the customer’s problem and understanding the context around it. This is what Marquetly did. The team went to the customers, conducted observations, and then asked questions. “What is the biggest problem standing in the way of you finishing your course? What’s the pain?” When conducting problem-based research, you are trying to identify the pain point and the root cause of the problem. When you understand the context around a customer’s problem, you can form a better solution to solve it. Without that, you are just guessing.

My friend Josh Wexler says, “Nobody wants to hear that their baby is ugly.” The way around this is to not get too attached. Kill the bad ideas before they take up too much time and energy from the teams and before you get hooked on them. Instead, fall in love with the problem you are solving.

Learning some information is better than none. In a consumer industry, you can usually reach out to friends of friends who use the product or have the right background. In a B2B environment, you can work with the sales or account managers to have them be your research spies—asking the questions you might need to know during their sales calls or follow-up meetings. It’s not always possible, but in many places, when you think outside the box, you can come up with something that helps. In the situation with Marquetly, when it couldn’t get in touch with the users who were dropping off before signing up, it turned to Qualaroo.

Since The Lean Startup was published, companies have been adopting experimentation techniques, yet many of them have done so for the wrong reasons. They all are trying to build the ideal Minimum Viable Product (MVP), an experimentation concept introduced in the book. I asked my Twitter followers how they defined an MVP at their company. A bunch of people replied, but one follower summed it up well: “I was told by two separate clients that whatever is built in the first release is an MVP.” 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.

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.

In many early-stage companies, concept testing is the way they get early sales or capital. This is how Dropbox got its first round of investment.1 When starting out, Dropbox had the hunch that the biggest issue it could solve for users was seamless synchronization of their documents across computers and the internet. The issue was definitely rampant, but the company had a difficult time pitching the solution to investors. When it explained how Dropbox worked, the investors dismissed it, citing a crowded market of similar tools. No matter how hard they tried to explain the solution, the investors just couldn’t picture it. 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.

Get creative! Just remember that your biggest objective in this phase is to learn—​not to earn.

Learning reduces risk. The goal of solution exploration is to get faster feedback. If we take too long to get feedback, we not only waste money but we also waste time. The opportunity cost of building the wrong thing is too high. Every industry and product has unknowns—getting creative about how you answer these unknowns is key.

Story mapping and North Star documents are two ways to help teams find alignment around the vision. A 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.

In his book, The Principles of Product Development Flow, Don Reinertsen talks about the importance of Cost of Delay in prioritizing work. He calls it “the one thing” that should be quantified. Cost of Delay is a numeric value that describes the impact of time on the outcomes you hope to achieve. It combines urgency and value so that you can measure impact and prioritize what you should be doing first. When you think of building and releasing that first version of the product, you need to consider the trade-offs between the amount of value you can capture with the scope of the release and the time it takes to get it out the door. It’s an optimization problem. You want to reduce scope enough so that you can capture the maximum value in the right time.

In this situation, you would discuss each feature or feature component in terms of urgency and value. If it is high urgency, that means that every moment you do not ship that feature to customers, you are losing out on opportunity to hit your goal—​for example, if you are actively losing customers or revenue each week because you are not fulfilling a need. High value is about solving the strongest problems or desires for the customer.

We are done developing or iterating on a feature only when it has reached its goals. Often, teams ship a first version of the feature and then move on to the next, without measuring the outcomes for the user. As 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. Instead, teams should be working like the team at Marquetly, by setting the success criteria before launch, while measuring and iterating until they reach it. Version 1 should be looked at as a hypothesis, just like any other work. And, if we launch the feature and it is not hitting our goals, we need to be comfortable rolling it back and trying something else.

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.