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.

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.

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.

I say to product managers, “Raise your hand if you went back and iterated on the last thing you shipped.” Normally, 15–20% of the people raise their hands. My next question is, “How do you know that what you shipped was successful?” The answers here usually revolve around meeting a deadline and finishing with bug-free code. This is a prime example of a company that is optimized for outputs, instead of outcomes. 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.

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.

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.

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.

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.

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.

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

Under a Waterfall process, the first step for a product manager is to talk to the people in the business — usually called internal stakeholders — and ask them for their input and requests.

Agile assumed that someone was doing that front-of-funnel part, generating and validating ideas, and instead optimized the production of software. Yet, that piece has been lost along the way, as companies believe that Agile is all you need to do successful software development. So, many product managers in Agile organizations still operate with this Waterfall mindset.

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 managers really own the “why” of what they are building.

When you look at the role of the product owner in most Scrum literature, the three responsibilities of the position include the following: Define the product backlog and create actionable user stories for the development teams. Groom and prioritize the work in the backlog.

Accept the completed user stories to make sure the work fulfills the criteria.

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?

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.

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.

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?

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

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.

There are many examples of strategy deployment across organizations. OKRs is a type of strategy deployment used by Google. Hoshin Kanri is a strategy deployment method used by Toyota. Even the military uses strategy deployment with mission command. All of these are based on the same premise — setting the direction for each level of an organization so they can act.

In most product organizations, there should be four major levels in strategy deployment (see Figure 12-1): Vision Strategic intent Product initiatives Options

During the Plan Do Check Act (PDCA) cycles — in step 4, teams go through and systematically identify obstacles standing in the way of reaching the target condition, their next goal, plan out how to tackle it, and then experiment in order to see whether the plan worked. They then reflect on the progress (check) and act accordingly in the next round.

Now you might be thinking, “What is the difference between a company mission and vision?” A good mission explains why the company exists. A vision, on the other hand, explains where the company is going based on that purpose.

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?

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?

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?

There are many product frameworks available to help you think through the appropriate product goals. My two favorites are Pirate Metrics and HEART metrics.

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.

HEART metrics measure happiness, engagement, adoption, retention, and task success.

This is one of the first things every company should do — implement a metrics platform. Amplitude, Pendo.io, Mixpanel, Intercom, and Google Analytics are all data platforms. Some, like Intercom and Pendo.io, also implement good customer feedback loops, because they provide tools to reach out to customers and ask questions.

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.

The Product Kata for Marquetly’s team

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.

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

Prioritization, as I mentioned earlier, is a top issue for most product managers. There are many frameworks out there that will help you prioritize, like benefits mapping, Kano models, and others, but my favorite is Cost of Delay.

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.

You might be thinking, “But how do I calculate the revenue for each of my products?” 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.

Quarterly business reviews Product initiative reviews Release reviews

During quarterly business review meetings, the senior leadership team, made up of the executives and the highest level of the organization, should be discussing progress toward the strategic intents and outcomes of a financial nature.

This is the place for product managers to talk about the results of preliminary experimentation, research, or first releases, as they relate to overall goals. New product initiatives can be introduced in this meeting for feedback and buy-in, along with funding from the product development leadership group.

Release reviews provide the opportunity for teams to show off the hard work they have done and to talk about success metrics. These should happen monthly, before features go out, to showcase what is in the pipeline to be released.

Usually, our roadmaps consist of a few key parts: The theme Hypothesis Goals and success metrics Stage of development Any important milestones

Create automated and streamlined ways to collect data on progress toward goals and outcomes across teams. Report on goals, outcomes, roadmaps, progress, capacity, and costs across the product organization, translating these activities into financial implications for the company executives. Set up and maintain a product analytics platform to report on product engagement metrics across the organization. Standardize product processes that go across teams, such as strategy cadences, experimentation tracking and feedback, documentation on product features, collecting data, setting goals, creating and maintaining roadmaps, and sales enablement. Organize and run critical product meetings for strategy creation, strategy deployment, and releases. Conduct any coaching or training for the product teams.