More on this book
Community
Kindle Notes & Highlights
Read between
July 19 - July 23, 2020
This book is a guide to getting out of the build trap with great product management. We look at what it means to become and be a product-led organization (Figure P-1), which 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
“You’re stuck in the build trap, Chris. To get out, you need to change the way you approach software development, both as a company and as a leader. 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.” He looked overwhelmed.
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.
Every feature you build and any initiative you take as a company should result in some outcome that is tied back to that business value.
When companies do not understand their customers’ or users’ problems well, they cannot possibly define value for them. Instead of doing the work to learn this information about customers, they create a proxy that is easy to measure. “Value” becomes the quantity of features that are delivered, and, as a result, the number of features shipped becomes the primary metric of success.
I once worked with a company that made a data platform for enterprise companies. It had a total of 30 features, with about 40 more on the backlog, when I came in. When I measured the customer use of those existing features, we discovered people used only 2% of them consistently. And yet, development was underway to add more, instead of trying to reevaluate what they already had.
Outputs are easily quantified things that we produce — number of products or features, number of releases, or velocity of development teams. Outcomes are the things that result when we finally deliver those features and the customer problems are solved. True value is realized in these outcomes, both for the business and for the user or customer.
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.
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 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. Product managers identify features and products that will solve customer problems while achieving business goals. They optimize the Value Exchange System.
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?
Being a great product manager takes a thorough understanding of your users, a careful analysis of your systems, and an ability to see and execute on opportunities for your market. When you go through the motions without active thinking, you end up with a lot of useless features. We rarely teach product managers how to think, and, even if we do, we don’t measure this thinking for success. Instead, we are praised for writing detailed specifications or for making sure the developers are shipping on time.
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.
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. 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.
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.
The first thing Meghan wanted to understand was what was driving that 60% abandonment rate. She pulled the data to find out who had started the process but did not finish with their bank, and then she reached out to them. Quite a few of the people said they were frustrated with the process and eager for someone to make it better.
All solution ideas are subject to bias, organizational or personal. The only way to fight this bias is to learn from users and to experiment.
Product ownership is just a piece of product management. A good product manager is taught how to prioritize work against clear, outcome-oriented goals, to define and discover real customer and business value, and to determine what processes are needed to reduce the uncertainty about the product’s success in the market.
Without this background in product management, someone can effectively go through the motions of the product owner role in Scrum, but they can never be successful in making sure that they are building the right thing. In other words, product owner is a role you play on a Scrum team. Product manager is a career.
Product managers ultimately play a few key roles, but one of the most important ones is being able to marry the business goals with the customer goals to achieve value. Good product managers are able to figure out how to achieve goals for the business by creating or optimizing products, all with a view toward solving actual customer problems.
When we began breaking the product into value streams and organizing around feature sets that delivered whole value (instead of component areas, like an API), we found that there were not 20 areas. This often happens when teams restructure around value instead of components. They find they do not need as many people to accomplish their goals.
When organizations lack a coherent product strategy that is ruthlessly prioritized around a few key goals, they end up spreading themselves thin. There are many teams working to optimize components but not the whole. Don’t forget that, to make a considerable impact, you need to have everyone going in the same direction, working toward the same goals,
Netflix then self-organized around key outcomes and strategies to help reach its goals. Gibson Biddle, who was a VP of product at Netflix from 2005 to 2010, talks about aligning his team around a common guideline for evaluating its product strategy. That guideline was to “delight customers, in margin-enhancing, hard-to-copy ways.” He set goals that would accomplish this and would help Netflix execute on the company vision around key initiatives (Table III-1), including personalization, instant access to entertainment, and ease of use. Teams were then able to explore tactics to accomplish these
...more
This highlight has been truncated due to consecutive passage length restrictions.
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.
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.
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.
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
...more
That’s what a strategic framework promotes. If you’re aligned coherently and you have a good strategic framework, you can then allow people to make decisions without a lot of management oversight.
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.
Henrik Kniberg, a former consultant at Spotify, explains that this is how Spotify thinks.1 The company operates using something called DIBBs, which stands for Data, Insights, Beliefs, and Bets. The first three things, data, insight, and beliefs, inform a piece of work called a bet. The concept of thinking of initiatives as bets is powerful because it sets up a different type of expectation.
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.
Not having the right level of direction lands us in the build trap. Teams are given instructions that are either too prescriptive or too broad. Executives will get too far into the weeds, managing by authority and not allowing autonomy. Or teams could, as Bloom mentioned, be given so much freedom they are unable to act. That is why strategy deployment is key, from a product development perspective. 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.
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.
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.
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. 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
...more
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.
One intent is usually good for a small company, and three are plenty for a large organization. Yes, three. I know that sounds like very few goals for an organization of thousands of people, but that is key. This is also where the level and time frame matter. 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 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. 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
...more
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.
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 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.
After we have set the goal, we begin walking through the Product Kata. We ask ourselves the following: What is the goal? Where are we now in relation to that goal? What is the biggest problem or obstacle standing in the way of me reaching that goal? How do I try to solve that problem? What do I expect to happen (hypothesis)? What actually happened, and what did we learn?
“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.”
The tasks of focusing on the Product Kata and identifying which phase you are in and what tools are available there are key to successful product management. In the next few chapters, we talk about how to go through each of these phases: Understanding the direction Problem exploration Solution exploration Solution optimization
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.
