Escaping the Build Trap: How Effective Product Management Creates Real Value by Melisa Perri cover

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

Date read:
Check out Amazon for more details and reviews.

Shipping is a muscle that you develop by solving your problems. Your constraints force you to build faster and leaner. That gives you advantages over teams ruled by groupthink and VC money. Make your growth organic and monetize ASAP. Scale by automating whatever you can.

Part I: The Build Trap

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.

Peanut-buttering your strategy: you have so many strategic initiatives spread over very few people

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.

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

The Value Exchange System

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.

But value can be difficult to measure and to measure well from a customer or user perspective. Products and services are not inherently valuable. It’s what they do for the customer or user that has the value—solving a problem, for example, or fulfilling a desire or need. Doing this repeatedly and reliably is what guides a company to success.

Constraints on the Value Exchange System

Your customers and users don’t exist in a vacuum, and so their wants and needs change according to what’s around them. Likewise, your opportunities for how to address those wants and needs are constantly evolving. Directly controlling these surroundings is out of the hands of companies, so the only thing we can do is understand them better to know how to act.

Simultaneously, businesses face their own constraints. To realize the maximum value, organizations need to have the right individuals, the right processes, the right policies, the right strategy, and the right culture. Although many of the constraints and influences on the customer side are out of our control, businesses have full control over their own constraints and how they deal with them. When these constraints squeeze too tight, value is sacrificed on both sides of the system.

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.

Projects Versus Products Versus services

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.

Services, unlike products, use human labor to primarily deliver value to the user.

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. Projects are an essential part of product development, but the mentality of thinking only in projects will cause damage.

You need the discipline to move toward organizing for products over projects. 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.

The Product-Led organization

Product-led companies understand that the success of their products is the primary driver of growth and value for their company. They prioritize, organize, and strategize around product success. This is what gets them out of the build trap.

Sales-led companies let their contracts define their product strategy.

The easiest way to think of a visionary-led company is to consider Apple.

Technology-led company are driven by the latest and coolest technology. The problem is that they often suffer from a lack of a market-facing, value-led strategy.

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.

What We Know and What We Don’t

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.

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.

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.

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 research. You need to be open to these discoveries and follow through on pursuing them because they could change the shape of your company.

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

Part II: The Role of the Product Manager

The product manager deeply understands both the business and the customer to identify the right opportunities to produce value. They are responsible for synthesizing multiple pieces of data, including user analytics, customer feedback, market research, and stakeholder opinions, and then determining in which direction the team should move. They keep the team focused on the why—why are we building this product, and what outcome will it produce?

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.

A Great Product manager

An effective product manager must understand many sides of the company in order to do their job effectively. They need to understand the market and how the business works. They need to truly understand the vision and goal of the company. They also need deep empathy for the users for whom they are building products, to understand their needs.

The product manager works with the rest of the team to develop the idea and then jumps in, as requirements become validated, to make sure that the product being created achieves the goals of the customer, user, and business. They then work to solidify the product vision, crafting it and communicating it, and then championing it.

Product managers connect the dots. They take input from customer research, expert information, market research, business direction, experiment results, and data analysis. Then they sift through and analyze that information, using it to create a product vision that will help to further the company and to solve the customers’ needs.

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. That doesn’t mean they don’t need knowledge in either of these areas. They need to know just enough to talk with an engineer or a business person and to understand enough to make informed decisions.

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.

Start With Why:

  • 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?

The Product Manager Career Path

Tactical work for a product manager focuses on the shorter-term actions of building features and getting them out the door. It includes the daily activities of breaking down and scoping out work with the developers and designers, in addition to crunching the data to determine what to do next.

Strategic work is about positioning the product and the company to win in the market and achieve goals. It looks at the future state of the product and the company and what it will take to get there.

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.

Organizing Your Teams

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.

First you begin with the customer or user— whomever is consuming your product at the end of the day. What is the value that you are providing them? Then work backward. What are the touchpoints they have with your company on the way to receiving that value? Having identified these, how do you organize to optimize and streamline that journey for them? How do you optimize to provide more value, faster?

Part III: Strategy

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.

What Is Strategy?

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

Thinking of strategy as a plan is what gets us into the build trap. We keep adding new features to the list but have no way to evaluate whether they are the right features in the holistic context of our company.

In The Art of Action Bungay writes: Strategy is a deployable decision-making framework, enabling action to achieve desired outcomes, constrained by current capabilities, coherently aligned to the existing context.

Strategic Gaps

The Knowledge Gap is the difference between what management would like to know and what the company actually knows. Organizations try to fill this gap by providing and demanding more detailed information.

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 Alignment Gap is the difference between what people do and what management wants them to do, which is to achieve the business goals. Organizations try to fill this gap by providing more detailed instruction; whereas, instead, they should allow each level within the company to define how it will achieve the intent of the next level up.

The Effects Gap is the difference between what we expect our actions to achieve and what actually happens. When organizations do not see the results they want, they try to fill this gap by putting more controls in place. However, that is the worst thing you can do in this scenario. Giving individuals and teams the freedom to adjust their actions so that they are in line with their goals is what will truly allow them to achieve results.

Autonomy is what allows organizations to scale. The alternative is hiring hundreds or thousands of middle managers that lead by authority, telling people what to do.

Creating a Good Strategic framework

A good company strategy should be made up of two parts: the operational framework, or how to keep the day-to-day activities of a company moving; and the strategic framework, or how the company realizes the vision through product and service development in the market. Many companies confuse these two frameworks and treat them as one and the same. Although both are important, getting the strategic framework right is essential for developing great products and services.

Tying budgeting, strategy, and product development to this artificial yearly time cycle only creates lack of focus and follow-through. Instead, companies should be continuously evaluating where they are and where they need to take action, and then fund those decisions.

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.

Strategy creation is the process of figuring out which direction the company should act upon and of developing the framework in which people make decisions. Strategies are created at each level and then deployed across the organization.

With product development, you can harness this same approach, but we need to customize it to your situation i.e. the Product Kata:

  1. Understand the Direction: Company Vision & Strategic Intent & Product Initiative.
  2. Analyze the Current State: Current State of Intents & Current State of Initiative/Product.
  3. Set the Next Goal: Product Initiative & Option Goal.
  4. Choose Step of Product Process: Problem Exploration, Solution Exploration, Solution Optimization.

Company-Level Vision and Strategic Intents

The company vision is the linchpin in the strategy architecture. It sets the direction and provides meaning for everything that follows. Having a strong company vision gives you a framework around which to think about your products

A good mission explains why the company exists. A vision, on the other hand, explains where the company is going based on that purpose. I find that the best thing a company can do is to combine both the mission and the vision into one statement to provide the value proposition of the company—what the company does, why it does it, and how it wins doing that.

Strategic intents communicate the company’s current areas of focus that help realize the vision. Strategic intents usually take a while to reach, on the magnitude of one to several years.

Strategic intents should be at a high level and business focused. They are about entering new markets, creating new revenue streams, or doubling down in certain areas.

Product Vision and Portfolio

Product initiatives translate the business goals into the problems that we will solve with our product. The product initiatives answer how? How can I reach these business goals by optimizing my products or building new ones?

Options are your bets, as Spotify would call them. They represent the possible solutions that teams will explore to solve the product initiative.

The product vision communicates why you are building something and what the value proposition is for the customer.

The product vision emerges from experimentation around solving problems for users. After you validate that the solution is the right one, you can grow it into a scalable, maintainable product. But you need to be careful not to make the product vision too specific. It cannot describe every little feature but should include more of the main capabilities it enables for the user.

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 Chief Product Officer 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?

Part IV: Product Management process

The best solutions are linked to real problems that users want solved. Product managers use a process to identify which of those problems the team can solve to further the business and achieve the strategy. Product managers can rely on the Product Kata to help them develop the right experimental mindset to fall in love with the problem rather than the solution. They continue iterating until they reach the outcome.

The Product Kata

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.

The first task is to get to the product initiative. To do this, you need to understand the strategic intent, evaluate the current state of that strategic intent in relation to where your products can help, and determine what problems you can solve to further that strategic intent.

After we have set the goal, we begin walking through the Product Kata. We ask ourselves the following:

  1. What is the goal?
  2. Where are we now in relation to that goal?
  3. What is the biggest problem or obstacle standing in the way of me reaching that goal?
  4. How do I try to solve that problem?
  5. What do I expect to happen (hypothesis)?
  6. What actually happened, and what did we learn?

It’s important to understand each phase so that we are doing just enough to get us to the goal. 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.

Don’t spend your time overdesigning and creating unique, innovative solutions for things that are not core to your value proposition. If someone has already solved that problem with a best practice, learn from that, implement their solutions, gather data to determine if it’s successful in your situation, and then iterate. Reserve your time and energy for the things that will make or break your value proposition.

Understanding the Direction and Setting Success Metrics

Product metrics tell you how healthy your product is, and, ultimately, your business, given that a healthy product contributes to overall health of the business. They are the lifeblood of every product manager. Keeping a pulse on your product is crucial for knowing when you should act and where. This is how we set direction.

But it’s easy to become stuck measuring the wrong things. Frequently, teams turn to measuring what we call vanity metrics. This concept, introduced in Lean Startup, is about goals that look shiny and impressive because they always get bigger.

You can easily turn a vanity metric into an actionable metric by adding a time component to it. Do you have more users this month than last? What did you do differently? Think carefully about how to add context and meaning to your facts and figures. Consider the meaning behind the metrics and how they help inform your decisions and understanding.

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

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.

HEART metrics measure happiness, engagement, adoption, retention, and task success. These are usually used to talk about a specific product or feature.

With HEART, you add in other metrics to talk about how the user interacts with the product. Happiness is a measure of how satisfied the user is with the product. Engagement is a measure of how often users interact with the product. Task success measures how easy it is for a user to accomplish what they were meant to with the product.

Retention is a lagging indicator, which is impossible to act on immediately. It will be months before you have solid data to show that people stayed with you. That is why we also need to measure leading indicators like activation, happiness, and engagement. Leading indicators tell us whether we’re on our way to achieving those lagging indicators like retention.

To make sure you have enough data to act on, it’s important to implement tools that make it easy to measure these things. This is one of the first things every company should do—implement a metrics platform.

Problem Exploration

It’s essential that we all get and go talk to actual humans to get to the heart of their problem.

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 i

It’s easy to fall into the trap of solving problems before you find their root causes. We’re all prone to problem solve, even if we don’t know what the problem is. Our brains love thinking in terms of solutions. However, this can be risky for business. If you don’t have an underlying understanding of the problem, you can never deliberately create the right solution.

Solution Exploration

Companies often confuse the building to learn and building to earn. Experimentation is all about building to learn. It allows you to understand your customers better and to prove whether there is value in solving a problem. Experiments should not be designed to last for a long time. By nature, they are meant to prove whether a hypothesis is true or false, and, in software, we want to do this as quickly as possible. This means you’ll need to eventually scrap whatever you build and figure out how to make it sustainable and scalable, if it does succeed.

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.

The Product Kata is a great tool for grounding people in learning. It always asks the question, “What do you need to learn next?” This keeps the team on track and sets it up to create the right type of experiments.

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. Concierge experiments are particularly interesting for B2B companies because this is how many of these companies got started—by taking on the work for the customers and then later automating it. By taking on the work yourself, you can learn how to build the software correctly the first time. And it’s far faster and less expensive to iterate on a service than on a coded feature.

Wizard of Oz can also be combined with techniques such as A/B testing. In A/B testing, you split a portion of your traffic to a new solution idea to see whether it moves a metric compared to the current state of the site. You can use this outside of Wizard of Oz, as well, to test new designs or messages on your website. But you need to be careful about when you use A/B testing. You wouldn’t want to use A/B testing in two instances: if you were still very unsure about your solution direction or if you did not have enough traffic to those pages for the results to have statistical significance.

Concept testing is another solution experiment that focuses more on high-touch interaction with the customer. In this case, you try to demonstrate or show concepts to the user to gauge their feedback. These can vary in execution, from landing pages and low-fidelity wireframes to higher-fidelity prototypes or videos of how the service might play out. The idea here is to pitch the solution idea in the fastest, lightest way possible to convey the message. It’s important to note that this type of experiment tends to be more generative than evaluative. Just like problem research, generative solution experiments help you to gain more awareness around what a user desires in a solution.

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.

Prototypes are the most popular tool for testing. When you need to learn whether a specific user flow or feature solves a problem for the user and allows them to achieve their desired outcome, you can turn to prototypes. It is an excellent tool because prototypes don’t require any code, and there are many software products out there that can help you link screens together to make the flow feel real.

Prototypes don’t make sense when you need to validate the problem. In this case, you’re spinning your wheels creating shiny designs that look great but don’t help you to learn what you need to learn. That’s why you need to focus on exploring the problem before any solution activities.

Building and Optimizing Your Solution

After the direction is set for the product vision, it’s important to make sure everyone understands the context and work that needs to be done. 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. North Stars are great for providing context to a wide audience.

Story mapping helps teams break down their work and align around goals.

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.

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.

Part V: The Product-Led Organization

The product-led organization is characterized by a culture that understands and organizes around outcomes over outputs, including a company cadence that revolves around evaluating its strategy in accordance to meeting outcomes. In product-led organizations, people are rewarded for learning and achieving goals. Management encourages product teams to get close to their customers, and product management is seen as a critical function that furthers the business.

Outcome-Focused Communication

If there is one main reason I have seen companies fail to make a transition, it’s the lack of leadership buy-in to move to an outcome-oriented company. Leaders will say that they want to achieve results, but, at the end of the day, they still measure success by features shipped. Why? There’s so much satisfaction in seeing things move, at both a leadership and a team level. People want to feel like they are accomplishing things.

Visibility in organizations is absolutely key. The more leaders can understand where teams are, the more they will step back and let the teams execute.

We need a cadence of communicating strategy that matches our strategic framework. Remember our four levels of strategy: vision, strategic intent, product initiatives, and options.

Rewards and Incentives

Rewards and incentives are motivators for the employees of every company. The biggest issue I see with companies trying to transition to becoming product-led is what they don’t evaluate their current reward structures to make sure they incentivize the right behavior.

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. It also means that people are afraid to try anything new. This mentality stifles innovation.

Safety and Learning

Corporations love to talk about risk management. The irony is that experimentation is the ultimate risk-management strategy because, when you experiment early, you can prevent the failure of something you will have spent billions of dollars on later.

So many companies fail slowly. They release products and never measure whether those products do anything. They just let them sit there, collecting dust in a sea of endless features, never knowing whether they are producing value. This is the more dangerous and costly way to fail

Customer Centricity

This is what it means to be customer centric: knowing that the most important thing you can do to create great products is to deeply understand your customers. This is also the core of what it means to be product-led.