Escaping the Build Trap - Melissa Perri

Note: While reading a book whenever I come across something interesting, I highlight it on my Kindle. Later I turn those highlights into a blogpost. It is not a complete summary of the book. These are my notes which I intend to go back to later. Let’s start!

• 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

• A product-led organization involves four key components:
  • Creating a product manager role with the right responsibilities and structure
  • Enabling those product managers with a strategy that promotes good decision making
  • Understanding the process of determining what product to build, through experimentation and optimization
  • Supporting everyone with the right organizational policies, culture, and rewards to allow product management to thrive

• Tell me, what is the most important thing you can achieve today?” I asked him. “Revenue growth,” he answered easily. “We need it to get back to thirty percent year over year at least.” “When I asked others in the company, they did not give me that answer,” I told him. He looked a bit shocked. “Your CTO said the most important thing was the mobile strategy. When I asked why, he cited a board member. When I asked Karen what the most important thing was, she said acquiring more teachers on the teacher platform. When I asked the sales leader, he said getting more enterprise clients. No one is tying it back to your goal—the revenue. You are not aligned.” I continued. “A lot of it is due to having too many priorities. Everything is number one on your project list. You are peanut-buttering your strategy—meaning that you have so many strategic initiatives spread over very few people. You can’t give one team a large objective and expect them to hit major goals in a month. Those things take time and manpower. You have to build up to them.”

• When we lose sight of what is important, when we forget what value means, the products we produce—and sometimes our companies themselves—fail

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

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

• 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. For example, many companies follow such a rigid development process and cadence that there is no opportunity to experiment. Whenever I start a new training or workshop, 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. Yet most companies I encounter are stuck in output mode, and their entire organization is optimized to increase the output. Their processes are driven by deadlines and by checking off as many features on a list as possible. Teams are rewarded and incentivized to build more. Policies exist for the purpose of pushing teams to write more code or ship more features, and efforts (like talking to customers) are seen as waste

• 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. Then we should build products that help to achieve this

• A product is something that needs to be nurtured and grown to maturity. This takes a long time. When you ship features to enhance a product, you are contributing to this overall success. This feature enhancement is a project, but your work may not be done when you are finished. You need to keep iterating by scoping out new projects to reach the overall outcome and be successful. This is why the concept of product management—and that of having product managers—is so important for companies. 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

• 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. To become product-led, you need to take a look at the roles, the strategy, the process, and the organization itself

• Product development is full of uncertainty. It’s important to separate out the facts from the things that we need to learn. To do this, we explore the knowns and unknowns of our situation. 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 unre-lated 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. 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

• The Role of the Product Manager: Product management is a career, not just a role you play on a team. 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 chief product officer is the cornerstone of the product team in companies, helping to tie together the business outcomes to the roadmap and to represent its impact to the board. Companies need to create a standardized product management career path to attract the right talent and to provide them with growth opportunities in order to remain competitive in today’s market

• Listening to everyone’s opinions is important, but it doesn’t mean a product manager should implement every suggestion. Swinging too far in that direction brings us to the other most common archetype of the product manager: the waiter

• The waiter is a product manager who, at heart, is an order taker. They go to their stakeholders, customers, or managers, ask for what they want, and turn those wants into a list of items to be developed. There is no goal. There is no vision. There is no decision making involved. This was the archetype of 90% of the product owner teams at Marquetly. The most common question I get from product managers in this position is, “How do I prioritize?” Because they have no goal in which to provide context for trade-offs, it becomes a popularity contest for whomever is making the request

• More often than not, the most important person gets their features prioritized. This happens frequently in very large companies. The product managers go out, with all the right intentions, to talk to their customers and learn what they want. But, instead of discovering problems, waiters ask, “What do you want?” The customer asks for a specific solution, and these product managers implement them. This is where you end up in the product death cycle

• Waiters are reactive thinkers, not strategic thinkers. There’s usually an amount of learned helplessness that contributes to that. 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. That’s part of the job. It’s very possible to find the waiter archetype paired with another one, like project management. Because they are not focused on the why, they tend to focus a lot on the when. Project managers who are put into product management roles often become waiters waving a calendar

• Product managers are not project managers, although a little project management is needed to execute on the role correctly. Project managers are responsible for the when. When will a project finish? Is everyone on track? Will we hit our deadline? 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? The latter questions are more difficult to answer than the former, and, too often, product managers who don’t understand their roles well resort to doing that type of work. Many companies still think that the project manager and product manager are one and the same. Agile methodologies distribute the responsibilities of the project manager across the team. These cross-functional teams have all the key players dedicated to ship a feature, so less coordination is needed across departments. Thus, project management is not needed as much as it once was when all of these people were in different areas of the business, splitting their time on different projects

• So, many of the project managers that once existed in these companies have now been made product managers or product owners. But they often lack the experience needed to be a great product manager. 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

• 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. 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. But, at the end of the day, it’s the team, collectively, that really owns the product—the what

• Figuring out what to build takes a strategic and experimental approach. The product manager should be at the helm of these experiments, while continuing to identify and reveal every known unknown. At the beginning of product development, the known unknowns are usually around problem exploration and customer behavior, such as, “We’re not sure what problem we are solving for the customer.” As these unknowns begin to become clearer, the uncertainty then shifts to what will solve that customer problem. 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. To do that, a product manager must be humble enough in their approach to learn and take into account that they don’t know all of the answers. They need to know that there are assumptions that they must tackle along the way, approaching them with a scientific mindset to validate them and to reduce risk. Ultimately, the goal for the product manager is that—reducing risk by focusing on learning. Most important, they need to know that not all good ideas are their own

• 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. It’s about understanding the entire picture of the organization and figuring out how the product—not just the experience—fits into it

• What makes a great PM. She begins by asking 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?

• 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

• If you take your Scrum team away, and Scrum as a process, you are still a product manager. Product management and Scrum can work well together, but product management is not dependent on Scrum. This role should exist with any framework or process, and companies need to understand that in order to set their people up for success

• The product owners I speak with spend 40 hours a week writing tons of user stories. At that point, you need to ask, are those user stories even valuable? What are they prioritizing them against? How do they know that they will solve a problem? If you have one person spending that much time writing user stories, every week, you are most certainly in the build trap

• 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

• 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

• Often 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, 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. But, you might be asking: don’t you want teams to own all features so that you have a way to make sure someone is looking after them? Yes and no. To organize teams effectively, you need to balance the coverage and scope of teams with the goals you are trying to achieve

• When companies are small, you can organize effectively around goals you are trying to reach. Consider how TransferWise does it. This London-based company does electronic transfers. You can send money to different countries in other currencies with very low fees, compared to what the banks charge. TransferWise has a relatively small number of product teams at around. The way they organize their teams—around strategic goals—allows them to stay small and still get an immense amount of work done. One team is focused on retention, another on implementing new currencies, and another on acquiring new users. Each of the teams has ownership of their goal and is judged for success based on their outcomes. They are also allowed to work across all products to do whatever is needed to reach those goals. It takes a huge amount of coordination across the product teams, so everyone is responsible for collaborating intensely with one another. Even though the coordination might seem like a handful, having fewer teams makes them ruthlessly prioritize around the most important initiatives. There’s no useless work. This structure also creates a nice redundancy throughout the company, so that important information about a single product is not stuck in the head of one person. If someone leaves, they don’t need to worry about all that ingrained knowledge going with them. If one team is busy with work, another team doesn’t need to wait for them to fix a bug because they own that piece of the product and no one else knows how to fix it

• TransferWise is an extreme example, but it works well for them. As companies scale, and especially as they begin to maintain more than one product, this approach might not be a viable option. We have to add in another component to organizing teams, but we still want to keep the product strategy and the goal-oriented nature. In addition to these things, we also look at the value streams of the organization

• 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. How do you organize this way? 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?

• Many companies are confused by the word product. You say product and people think of an app, a feature, or an interface. If you think back to our diagram on the value exchange, products are vehicles for value. So, if your app, interface, or feature is not inherently adding value on its own, it’s just a piece of the entire product. That doesn’t mean no one needs to manage it. It just means you have to look beyond just that piece to understand how to manage for value delivery and creation. 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. As your company scales to include more products, you will need more levels of management to effectively oversee the various areas. However, you don’t want to overdo it. Having the right number of levels also has a large impact on your strategy. By minimizing the number of layers and by giving product managers more scope over their product areas, you can effectively create a product organization with a structure that supports the product 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

• Good strategy isn’t a detailed plan. It’s a framework that helps you make decisions. Too often, people think of their product strategy as a document made up of a stakeholder’s wish list of features and detailed information on how those wishes should be accomplished. And they’re peppered with a ton of buzzwords like platform or innovation

• Communicating the end state of a product is not inherently wrong. You should be striving toward a vision. However, it becomes dangerous when we commit to these visions and lofty feature sets without validation. When I ask people what their strategy is and they begin reciting their to-do’s, I always ask this follow-up question: “How do you know that this is the right thing to build?” Most of the time, I cannot get a straight answer to that question, or I hear, “I have no idea, but my boss told me to build it”

• The dictionary defines strategy as “a plan of action or policy designed to achieve a major or overall aim.” This definition seems to be the common interpreta-tion of good strategy across businesses. Many companies spend months in “strategic planning” for the following year, creating comprehensive and detailed outlines of the tasks they will accomplish, the cost of those actions, and the revenue they will generate. This often is tied to the budgeting process, and teams must present business cases and timelines in order to secure funding for these projects

• 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. 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 strategy should transcend the iterations of features, focusing more on the higher-level goals and vision. A good strategy should sustain an organization for years. If you are changing strategy yearly or monthly, without good reason from data or the market, you are treating your strategy as a plan rather than as a framework

• 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 strategic intent points the team toward the outcomes the businesses wants to achieve. In the case with Marquetly, there were too many unknowns at the time to make a detailed plan. It still did not understand why users were falling off at certain steps of the sign-up flow. This was the core problem it needed to understand before coming up with the right solution. The company needed room to experiment and to understand why before it could suggest how to solve the problem. Consider a product manager telling you the following: “I’m building this because it’s going to help increase acquisitions, and new customer-acquisition is our big goal to drive the revenue prioritized at the corporate level. I know my product can bring people in. We know there’s a problem here, but we’re not sure what it is yet. Our next step is to discover that problem, tackle it with a solution, and then try to optimize the solution so we can increase acquisition.” That’s someone telling the story. A product manager who told you this should inspire confidence. Unfortunately, the opposite is usually true. 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

• 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

• At one company, I walked around asking all of the product managers on the hundred or so teams why they were working on their current project. I then asked their leaders the same question. I got two different answers from these two different levels. They could not connect the activities of the teams back to the outcomes of the companies because leadership had passed down feature requests rather than expected outcomes and goals. As soon as those feature requests were committed, it was nearly impossible to change them because the company expected them to be delivered

• Although I’ve witnessed this at many companies, there is one example that always haunts me. I was training product managers at a very large and established company (let’s call it Company B), when I was told that it could not do any validation work around its products because the solutions the teams were building were already committed to the leadership of the company. Why? Well, Company B had hired a huge consulting firm to explore and dictate its product roadmap for the next five years. The consultants poured over market research and competitive analyses and came up with a roadmap, which then trickled down to the teams. These teams, meanwhile, had been talking to customers and knew that these solutions the consultants had come up with were not what customers wanted. Yet their performance reviews were based on delivering those products. They wanted to do right by the customer, but they couldn’t, for fear of losing their jobs. And so they built the wrong thing—knowingly. At the end of the year, Company B missed all of its goals, and the teams were penalized, even though they delivered on their roadmaps. When these teams realized that customers did not want the consultant-proposed solution, they should have had the freedom to explore alternative options. That is how a product-led organization would operate. This is what keeps us out of the build trap. Instead, their adherence to predetermined meetings and formalities trapped them into staying quiet. 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. The lack of meaning and focus spreads, and, at the end of the year, the company will look at their target goals and ask, “What happened?” Lack of leadership alignment is by far the biggest issue I see standing in the way of successful product management

• 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

• All of these misguided, knee-jerk reactions start to pile up. Instead of aligning a team with a framework of goals and direction and then stepping back to give that team the room to explore how to reach the goals, management usually swings a complete 180 degrees. It asks for more information. It expects teams to commit to what management wants to do over the next year. It prescribes fully thought-out solutions, and then product teams are restricted to only those param-eters instead of being able to focus on learning and adjusting their decisions as they go

• 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

• This strategic framework aligns the company’s strategy and vision with the products that are developed by the teams. Having a strong company vision and product visions that align to the strategic framework helps companies avoid swirl in planning and execution. Those companies that are busy creating new visions and strategies every year often are thinking too much in the short term and aren’t planning enough for the future

• 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 deployment levels: The first two are at the company level, whereas the last two are specific to the products or services of the company. Strategy deployment and strategy creation, though, are two different things. A significant amount of work goes into defining what each of these should be, coordinating them across product lines and teams and then communicating them upward and downward for buy in

• 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. Strategy is about how you take the organization from where you currently are and reach the vision. For strategy to be created, you must first understand the vision, or where you want to go. Then we can identify problems or obstacles standing in our way of getting there and experiment around tackling them. We repeatedly do this until we reach the vision. If you are in the C-Suite, getting this right should be your top priority—or you’ll be setting up your hundreds or thousands of employees for failure

• To understand the direction, you are looking at either the vision, strategic intent, or product initiative, depending on which level you are starting on. The current state is related to where you stand in relation to your vision. It also reflects the current state of the outcomes, including the current measurement of those outcomes. Option goals are our next level of goals from the team. These are the outcomes you need to achieve in order to make progress toward your initiative or intent. Then you conduct your product process to experiment around systematically tackling problems to reach your goal

• 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

• “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. 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. Here are a few examples of compelling vision statements:
  • To offer designer eyewear at a revolutionary price, while leading the way for socially conscious businesses —WARBY PARKER
  • At Bank of America, we are guided by a common purpose to help make financial lives better by connecting clients and communities to the resources they need to be successful —BANK OF AMERICA
  • Becoming the best global entertainment distribution service, licensing entertainment content around the world, creating markets that are accessible to film makers, and helping content creators around the world to find a global audience —NETFLIX

• All of these vision statements provide focus for the company. They are short, memorable, and clearly articulated. They also don’t include fluffy terminology. Many companies create a vision statement that is something like, “To be the market leader in online photo storage.” Although that’s a good thing to strive for, it leaves the rest of the company asking how and why. It’s too broad. I don’t want to get overprescriptive on the how here, but you do need to focus your company around where you want to concentrate. Take Netflix. Although it said it wanted to be the best global entertainment distribution service, it provided focus on how the company planned to do that— by licensing content around the world, creating markets that are accessible, and helping content creators. It’s okay to want to be the best or the market leader, but you need to give some context on how

• If your vision has been murky for a while, you need to provide more than just a vision statement. Company leaders need to spend time communicating their vision, explaining their choices, and painting an image of what is to come

• Even with the vision, the difficult part is connecting it back to the company’s operations. This is where it’s necessary for company leaders to specify strategic intents. These few, concise, outcome-oriented goals focus the company around how to reach the vision

• Although the vision should remain stable over a long period of time, how you intend to reach that vision changes as your company matures and develops. 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 are always aligned to the current state of the business. When determining what these intents are, the C-Suite of the company should ask, “What is the most important thing we can do to reach our vision, based on where we are now?” There should not be laundry list of desires or goals—just a few key things that need to happen to make a big leap forward. Keeping the list of strategic intents small focuses everyone

• When organizations plan their strategic intents, they should think about how each part of the organization can contribute to these goals

• 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. Think back to the Netflix example at the beginning of this section. Netflix had a clear strategic intent: “Lead the streaming market.” All of its decisions, from enabling internet-connected devices to focusing on creating more content for users, helped to achieve this goal. It pushed them in the right direction. When that goal was realized, Netflix changed course to maintain its position by creating its own content—another strategic intent. These are not small goals. They need an army to execute, from product development to marketing to content creation. That’s the point. The strategic intents are about the whole company, not just the product solution

• 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? With Netflix, the biggest thing it needed to do to really get streaming to take off was to enable people to watch Netflix on any device, wherever viewers wanted to. Think about it. At the time, if you wanted to download something, you could watch it only on your laptop. There were no internet-connected devices. And no one wants to watch TV on their tiny laptop screen all the time. First of all, you’re basically saying that no one can watch it with you. And second, a 13-inch screen is hardly a cinematic experience

• Netflix created a product initiative to tackle this problem for the user. Putting that in user story format, we’d get, “As a Netflix subscriber, I want to be able to watch Netflix anywhere, with anyone, comfortably.” This is the company’s product initiative. It then explored many possible solutions—developing the Roku, partnering with Xbox and creating an app for it, and ultimately enabling all the internet-connected devices it could. All of these solutions, which I call options, were aligned to this product initiative

• Options are your bets, as Spotify would call them. They represent the possible solutions that teams will explore to solve the product initiative. Now, sometimes the solution will be readily apparent or easy to understand, based on best practices or previous work, but other times you will need to experiment to find the solution.

• Product initiatives set the direction for the product teams to explore options. They tie the goals of the company back to a problem we can solve for the users or customers. Product managers are in charge of making sure the product initiatives and options are aligned with the vision of an existing product or portfolio. Sometimes, you might even end up creating new products to solve these problems for your users. The product vision and portfolio vision keep you anchored in the problems and solutions that you want to explore

• The product vision communicates why you are building something and what the value proposition is for the customer. Amazon does this particularly well by creating what they call Press Release documents for every product vision. These short (typically a page or two) notices describe the problem the user is facing and how the solution enables the user to solve that problem. 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. If you are too prescriptive, it could stifle the way you grow the product and what you might add to it later

• Companies with more than one product often wrap their products under what is called a product portfolio. Very large companies have multiple product portfolios, all aligned by the type of value they provide to customers. For example, Adobe has the Adobe Creative Cloud as a product portfolio, which consists of the applications Photoshop, Illustrator, and InDesign, among others. It also has another product portfolio for next-generation applications, consisting of newer creative tools, such as those for rapid prototyping

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

• The product initiatives emerge from the work that needs to be done across the product portfolio to achieve the strategic intents and to further the individual product visions. This is also where you want to make sure that you are balancing the work of the teams with the direction of the company. The CPO is responsible for figuring out how to balance these areas of work in a framework. For the portfolio, you need to look at all of the things that need to be accomplished to balance your investments, the number of people, and the capacity you’re putting into each area in order to achieve success across the board. One thing this approach also helps with is finding time for innovation. Leaders always complain that they don’t have time to innovate. Usually, this is due to poor capacity planning and strategy creation. 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

• 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 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. This is what Marquetly did during its research and analysis to arrive at the product initiatives of increasing content and building out a more robust assessment

• There can be many options that help reach the product initiative. One or all of these might be what it takes to get us to the successful outcome of the initiative, and that’s okay. To determine whether we are getting closer to achieving our product initiative, we need to break the success metrics into something we can measure on a shorter time scale. We call this the team goal, and it’s how we measure the success of the option. Although it can take six months or longer to reach the product initiative goal, the team goal should be something we can measure after every release, which gives us feedback that our option is working the way we want it to. We set the team goal with the same process as we did for the product initiative

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

• 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. 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 determine the leading indicators for retention, you can qualify what keeps people retained—for example, happiness and usage of the product

• 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. Although data analysis is important, it can’t tell the entire story

• User research, observations, surveys, and customer feedback are all tools that you can harness to better explore the problem from a user standpoint. 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

• 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. The only way you can end up there is by luck. I’m not saying that this process is easy, but it’s the more efficient, effective, and successful way

• 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

• 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 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. There are many ways to experiment to learn. Concierge, Wizard of Oz, and concept testing are three examples of solution experiments, each of which I explain shortly. Because these are not designed to be long-lasting solutions, you want to limit exposure to your customers. With any experiment, it is important to think of how you will end it—to “close the loop.” Setting expectations on experiments with your customers is key to keeping them happy and to mitigating risk of a failed experiment. Explain to them why you are testing, when and how the experiment will end, and what you plan to do next. Communication is key to a successful experimentation process

• 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. Someone is pulling the strings—just like the Wizard of Oz. 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

• 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. If the latter, you could use techniques like concept testing to get feedback

• 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. When you show the concept to users, you are asking them to put themselves into the scenario in which they are experiencing the problem, and you are asking them questions about how the solution would or would not solve their problem. If you want to make it evaluative, to firmly test a hypothesis, you need a definitive pass-or-fail criteria, when interviewing a customer about the concept. This can be what I call an ask—something you would need from the user, either in the form of a commitment, monetary value, time, or some other investment that shows they are interested. Landing pages almost always pitch the idea and contain an ask in the form of entering an email address.

• 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 it funding and to validate that it was on the right path

• 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

• 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

• The more you try to hide your progress, the wider that knowledge gap becomes. Leaders will demand more information and will crack down on your freedom to explore. If you keep things transparent, you will have more freedom to become autonomous. Many companies fall back into bad habits because they have not figured out how to consistently communicate progress across the company in the form of outcomes. When leaders do not see progress toward goals, they quickly resort to their old ways. 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. Each of these is on a different time horizon, and progress toward them should be communicated accordingly

• Many companies talk about how they want their people to be innovative and how they want to create crazy new products, but there has to be an understanding that it’s safe to fail in order to get innovation. When you don’t have safety built in to your company, your product managers won’t feel comfortable trying something new. No one will. 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. Netflix could have tested the waters with Qwikster. Instead, it went full force on an idea that hadn’t been validated. The company was fortunate enough to be able to get immediate feedback and to change course, but that’s not always the case for companies. 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. Taking 10 years to fail, slowly burning through cash and never getting anywhere, is more problematic than allowing for smaller failures along the way. Instead, if you adopt a great product mindset and you give people the freedom to fail, what you’re doing is allowing them to fail quickly, quietly, and at a lower cost because they’re testing things early. That’s the type of failure you want to encourage. That’s the type of failure from which we can recover

• Having the right communication, rewards, incentives, budgeting, policies, and safety are all important in an organization, but one more thing is still required to make you truly product-led. In addition to a culture that rewards and promotes learning, you need a culture that focuses on the customer. Many of the top companies today, such as Amazon, Netflix, Zappos, Dollar Shave Club, and Disney, have gotten where they are by focusing on the customer. You can see this attitude manifest in the way that executives talk about and treat their customers. One of the most famous Jeff Bezos quotes about how Amazon succeeds is, “The most important single thing is to focus obsessively on the customer. Our goal is to be earth’s most customer-centric company.” This approach really defines everything that Amazon does, and it pays off. It grew its Prime membership from 25 million in 2012 to more than 100 million in 2018, by making it easier for people to shop and find what they need on Amazon, with free two-day shipping and access to lots of entertainment. 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