Inspired - Marty Cagan | Manas J. Saloi

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!

You might recognize that while I mentioned Agile, and while almost everyone today claims to be Agile, what I’ve just described is very much a waterfall process. In fairness to the engineers, they’re typically doing about as much Agile as they can, given the broader waterfall context.
The way most companies do them at this stage to come up with a prioritized roadmap is truly ridiculous and here’s why. Remember those two key inputs to every business case? How much money you’ll make, and how much it will cost? Well, the cold, hard truth is that, at this stage, we have no clue about either of these. In fact, we can’t know. We can’t know how much money we’ll make because that depends entirely on how good the solution turns out to be. If the team does an excellent job, this could be wildly successful and literally change the course of the company. The truth, however, is that many product ideas end up making absolutely nothing. And that’s not an exaggeration for effect.
In any case, one of the most critical lessons in product is knowing what we can’t know, and we just can’t know at this stage how much money we’ll make. Likewise, we have no idea what it will cost to build. Without knowing the actual solution, this is extremely hard for engineering to predict. Most experienced engineers will refuse to even give an estimate at this stage, but some are pressured into the old t-shirt sizing compromise—just let us know if this is “small, medium, large, or extra large.” But companies really want those prioritized roadmaps, and to get one, they need some kind of system to rate the ideas. So people play the business case game. An even bigger issue is what comes next, which is when companies get really excited about their product roadmaps. I’ve seen countless roadmaps over the years, and the vast majority of them are essentially prioritized lists of features and projects. Marketing needs this feature for a campaign. Sales needs this feature for a new customer. Someone wants a PayPal integration. You get the idea. But here’s the problem—maybe the biggest problem of all. It’s what I call the two inconvenient truths about product. The first truth is that at least half of our ideas are just not going to work. The first truth is that at least half of our ideas are just not going to work. There are many reasons for an idea to not work out. The most common is that customers just aren’t as excited about this idea as we are. So, they choose not to use it. Sometimes they want to use it and they try it out, but the product is so complicated that it’s simply more trouble than it’s worth, so users again choose not to use it. Sometimes the issue is that customers would love it, but it turns out to be much more involved to build than we thought, and we decide we simply can’t afford the time and money required to deliver it. So, I promise you that at least half the ideas on your roadmap are not going to deliver what you hope. (By the way, the really good teams assume that at least three quarters of the ideas won’t perform like they hope.) This entire process is very project-centric. The company usually funds projects, staffs projects, pushes projects through the organization, and finally launches projects. Unfortunately, projects are output and product is all about outcome. This process predictably leads to orphaned projects. Yes, something was finally released, but it doesn’t meet its objectives so what really was the point? In any case, it’s a serious problem, and not close to how we need to build products.
The biggest flaw of the old waterfall process has always been, and remains, that all the risk is at the end, which means that customer validation happens way too late. The key principle in Lean methods is to reduce waste, and one of the biggest forms of waste is to design, build, test, and deploy a feature or product only to find out it is not what was needed. The irony is that many teams believe they’re applying Lean principles; yet, they follow this basic process I’ve just described. And then I point out to them that they are trying out ideas in one of the most expensive, slowest ways we know.
While we’re busy doing this process and wasting our time and money, the biggest loss of all usually turns out to be the opportunity cost of what the organization could have and should have been doing instead. We can’t get that time or money back. In modern teams, we tackle these risks prior to deciding to build anything. These risks include value risk (whether customers will buy it), usability risk (whether users can figure out how to use it), feasibility risk (whether our engineers can build what we need with the time, skills, and technology we have), and business viability risk (whether this solution also works for the various aspects of our business—sales, marketing, finance, legal, etc.)
It’s all about solving problems, not implementing features.Conventional product roadmaps are all about output. Strong teams know it’s not only about implementing a solution. They must ensure that solution solves the underlying problem. It’s about business results.
Discovery and delivery are our two main activities on a cross-functional product team, and they are both typically ongoing and in parallel. There are several ways to think about this and to visualize it, but the concept is fairly simple: We are always working in parallel to both discover the necessary product to be built—which is primarily what the product manager and designer work on every day—while the engineers work to deliver production-quality product.
The purpose of product discovery is to quickly separate the good ideas from the bad. The output of product discovery is a validated product backlog.
Specifically, this means getting answers to four critical questions: 1. Will the user buy this (or choose to use it)? 2. Can the user figure out how to use this? 3. Can our engineers build this? 4. Can our stakeholders support this?
Product discovery involves running a series of very quick experiments, and to do these experiments quickly and inexpensively, we use prototypes rather than products. At this point, let me just say that there are several types of prototypes, each for different risks and situations, but they all require at least an order of magnitude of less time and effort than building a product. To set your expectations, strong teams normally test many product ideas each week—on the order of 10 to 20 or more per week. I want to emphasize that these are experiments, typically run using prototypes. A prototype is not something that’s ready for prime time and certainly not something your company would try to sell and stand behind. But they’re immensely useful, as they’re all about learning fast and cheap.
The purpose of all these prototypes and experiments in discovery is to quickly come up with something that provides some evidence it is worth building and that we can then deliver to our customers. This means the necessary scale, performance, reliability, fault tolerance, security, privacy, internationalization, and localization have been performed, and the product works as advertised. The purpose of product delivery is to build and deliver these production-quality technology products, something you can sell and run a business on.
Just because we’ve invested the time and effort to create a robust product does not mean anyone will want to buy it. So, in the product world, we strive to achieve product/market fit. This is the smallest possible actual product that meets the needs of a specific market of customers.
We use prototypes to conduct rapid experiments in product discovery, and then in delivery, we build and release products in hopes of achieving product/market fit, which is a key step on the way to delivering on the company’s product vision.
Mercenaries build whatever they’re told to build. Missionaries are true believers in the vision and are committed to solving problems for their customers. In a dedicated product team, the team acts and feels a lot like a startup within the larger company, and that’s very much the intention. We need teams of missionaries, not teams of mercenaries.
When a product succeeds, it’s because everyone on the team did what they needed to do. But when a product fails, it’s the product manager’s fault.
There’s probably no more important relationship for a successful product manager than the one with your engineers. If your relationship is strong, with mutual and sincere respect both ways, then the product manager job is great. If your relationship is not strong, your days as product manager will be brutal (and probably numbered). Therefore, this is a relationship worth taking very seriously and doing everything you can to nurture. This strong relationship begins with you. You need to do your homework and bring to the team the knowledge and skills of good product management.
Modern product marketing managers represent the market to the product team—the positioning, the messaging, and a winning go-to-market plan. They are deeply engaged with the sales channel and know their capabilities, limitations, and current competitive issues.
The nature of product marketing is a bit different, depending on the type of business you have and how your product gets to market. When you make products for businesses that are sold through either a direct sales force or a channel sales organization, it is a very significant and critical job to declare the positioning—by that we mean the market position the product must occupy, in addition to the messaging—digital/content assets, sales tools, and training that enable sales to effectively sell.
Great product leaders are highly valued and often go on to found their own companies. In fact, some of the best venture capitalists only invest in founders who have already proved themselves as great product leaders. Competencies Specifically, you are looking for someone who is proved to be strong in four key competencies: (1) team development, (2) product vision, (3) execution, and (4) product culture. Team Development The single most important responsibility of any VP product is to develop a strong team of product managers and designers. This means making recruiting, training, and ongoing coaching the top priority. Realize that developing great people requires a different set of skills than developing great products, which is why many otherwise excellent product managers and designers never progress to leading organizations. One of the worst things you can do is take one of your poor-performing people and promote them to this leadership position. I know that may sound obvious, but you’d be surprised how many execs reason, “Well, this person is not very strong, but he works well with people, and the stakeholders seem to like him, so maybe I’ll make him the head of product and hire a strong individual contributor to backfill him.” But how do you expect this poor performer to help develop his or her team into strong performers? And what message does this send to the organization? For this position, you need to ensure you hire someone who has proven ability to develop others. They should have a track record of The single most important responsibility of any VP product is to develop a strong team of product managers; identifying and recruiting potential talent, and then working actively and continuously with those people to address their weaknesses and exploit their strengths.
Product Vision and Strategy The product vision is what drives and inspires the company and sustains the company through the ups and downs. This may sound straightforward, but it’s tricky. That’s because there are two very different types of product leaders needed for two very different situations: 1. Where there is a CEO or a founder who is the clear product visionary 2. Where there is no clear product visionary—usually in situations where the founder has moved on There are two very bad situations you may encounter related to product vision and strategy. The first is when you have a CEO who is very strong at product and vision, but she wants to hire a VP product (or, more often, the board pushes her to hire a VP product), and she thinks she should be hiring someone in her own image—or at least visionary like her. The result is typically an immediate clash and a short tenure for the VP product. If this position looks like a revolving door, it’s very possible that’s what’s going on. The second bad situation is when the CEO is not strong at vision, but she also hires someone in her own image. This doesn’t result in the clash (they often get along great), but it does leave a serious void in terms of vision, and this causes frustration among the product teams, poor morale across the company, and usually a lack of innovation. The key here is that the VP product needs to complement the CEO. If you have a strong, visionary CEO, there may be some very strong VP product candidates that won’t want the position because they know that, in this company, their job is primarily to execute the vision of the CEO. One situation that unfortunately happens is when you have a visionary founder CEO, and she has a solid partner running product who is very strong at execution, but the founder eventually leaves and now the company has a problem because nobody is there to provide the vision for the future. It’s generally not something a VP product can easily turn on and off, and even if they can, the rest of the company may not be willing to consider the product leader in this new light. This is why I generally prefer when the founders stay on at the company, even if they decide they want to bring in someone else as the CEO. If you’re wondering what to do when you have a CEO who thinks she’s a strong visionary leader, but the rest of the company knows she’s not, you need a very special head of product, one that is a strong visionary, but also has the ability and willingness to convince the CEO the vision was all her idea. Execution No matter where the vision comes from, all the great vision in the world doesn’t mean much if you can’t get the product idea into the hands of customers. You need a product leader who knows how to get things done and has absolutely proved her ability to do so. There are many aspects that contribute to a team’s ability to execute consistently, rapidly, and effectively. The product leader should be expert on modern forms of product planning, customer discovery, product discovery, and product development process, but execution also means that they know how to work effectively as part of an organization of your size. The bigger the organization, the more critical it is that the person has proven, strong skills—especially in stakeholder management and internal evangelism. The product leader must be able to inspire and motivate the company and get everyone moving in the same direction. Product Culture Good product organizations have a strong team, a solid vision, and consistent execution. A great product organization adds the dimension of a strong product culture. A strong product culture means that the team understands the importance of continuous and rapid testing and learning. They understand that they need to make mistakes in order to learn, but they need to make them quickly and mitigate the risks. They understand the need for continuous innovation. They know that great products are the result of true collaboration. They respect and value their designers and engineers. They understand the power of a motivated product team. A strong VP product will understand the importance of a strong product culture, be able to give real examples of her own experiences with product culture, and have concrete plans for instilling this culture in your company.
With more than a million customers of the existing Creative Suite, Lea understood the technology adoption curve and that a segment of the customer base would strongly resist a change of this magnitude. Lea understood that it’s not just about whether the new Creative Cloud would be better, it would also be different in some meaningful ways. Some people would need more time to digest this change than others. Realize also that the Creative Suite is, as the name implies, a suite of integration applications—15 major ones and many smaller utilities. So, this meant that not just one product had to transform, but the full suite needed to transform, which dramatically increased the risk and complexity. It is any wonder that few companies are willing to tackle a product transformation of this magnitude? Lea knew she had a tough job in front of her and her teams. She realized that, for all of these interrelated pieces to be able to move together in parallel, she needed to articulate clearly a compelling vision of the new whole as greater than the sum of the parts. Lea worked with Adobe’s then-CTO, Kevin Lynch, to put together some compelling prototypes showing the power of this new foundation and used this to rally executives and product teams. Lea then began a sustained and exhausting campaign to communicate continuously with leaders and stakeholders across the entire company. To Lea, there was no such thing as over-communication. A continuous stream of prototypes helped keep people excited about what this new future would bring. Because of the tremendous success of the Creative Cloud—as of this writing, Adobe generated more than $1 billion in recurring revenue faster than anyone else has—Adobe discontinued new releases of the desktop-based Creative Suite to focus their innovation on the new foundation. Today, more than 9 million creative professionals subscribe to, and depend on, the Creative Cloud. Thanks, in large part to this transition, Adobe has more than tripled the market cap it had before the transition. The company today is worth roughly $60 billion. It’s easy to see how big companies with lots of revenue at risk would hesitate to make the changes they need to not only survive but thrive. Lea tackled these concerns and more head-on with a clear and compelling vision and strategy and clear and continuous communication to the many stakeholders.
I view product discovery as the most important core competency of a product organization.
If we can prototype and test ideas with users, customers, engineers, and business stakeholders in hours and days—rather than in weeks and months—it changes the dynamics, and most important, the results.
The issue is that anytime you put a list of ideas on a document entitled “roadmap,” no matter how many disclaimers you put on it, people across the company will interpret the items as a commitment. And that’s the crux of the problem, because now you’re committed to building and delivering this thing, even when it doesn’t solve the underlying problem. There are a few product teams out there that have modified their product roadmaps so that each item is stated as a business problem to solve rather than the feature or project that may or may not solve it. These are called outcome-based roadmaps. In general, when I see these, I’m pretty happy because I know the product teams are stepping up to solve business problems rather than build features. Outcome-based roadmaps are essentially equivalent to using a business objective–based system such as the OKR system. It’s the format that’s different more than the content.
In most Agile teams, when you even mention the word “commitments” (like knowing what you’re going to launch and when it will happen), you get reactions ranging from squirming to denial. It’s a constant struggle between those executives and stakeholders who are trying to run the business (with hiring plans, marketing program spend, partnerships, and contracts depending on specific dates and deliverables) and the product team that is understandably reluctant to commit to dates and deliverables. They’re reluctant when they don’t yet understand what they need to deliver, and if it will work in terms of delivering the necessary business results, in addition to not knowing how much it will really cost because they don’t yet know the solution. Underlying all of this is the hard-learned lessons of product teams that many of the ideas won’t work as we hope and those that could work will typically take several iterations to get to the point where they move the needle enough to be considered a business success. In a custom software environment, you might just be able to iterate until the business is satisfied with the software (or they just give up on it). In a product company, this won’t fly. Now don’t get me wrong—you’ve just heard how I feel about the perils of conventional roadmaps. Good product companies minimize (continued) these commitments. But there are always some real commitments that need to be made in order to effectively run a company. So, what to do? The key is to understand that the root cause of all this grief about commitments is when these commitments are It’s a constant struggle between those executives and stakeholders who are trying to run the business and the product team that is understandably reluctant to commit to dates and deliverables. made. They are made too early. They are made before we know whether we can deliver on this obligation, and even more important, whether what we deliver will solve the problem for the customer. In the continuous discovery and delivery model, the discovery work is all about answering these questions before we spend the time and money to build production-quality products. So, the way we manage commitments is with a little bit of give and take. We ask the executives and our other stakeholders to give us a little time in product discovery to investigate the necessary solution. We need the time to validate that solution with customers to ensure it has the necessary value and usability, with engineers to ensure its feasibility, and with our stakeholders to ensure it is viable for our business. Once we have come up with a solution that works for our business, we now can make an informed and high-integrity commitment about when we can deliver and what business results we can expect. Note that our delivery managers are key to determining any commitment dates. Just because your engineers believe something might take only two weeks to build and deliver, what if that team is already occupied on other work, and they can’t start on this work for another month? The delivery managers track these commitments and dependencies. So, the compromise is straightforward. The product team asks for a little time to do product discovery before commitments are (continued) made, and then after discovery, we are willing to commit to dates and deliverables so our colleagues can effectively do their jobs as well. Again, in good companies these types of commitments are minimized, but there are always some. It’s important for the organization to get comfortable with making these high-integrity commitments and explain to the company that, while they are not something we do frequently, when we do them, they can depend on the product team delivering on these commitments.
The product vision describes the future we are trying to create, typically somewhere between two and five years out. For hardware or device-centric companies, it’s usually five to 10 years out. Note that this is not the same as the company mission statement. Examples of mission statements are “organize the world’s information” or “make the world more open and connected” or “enable anyone anywhere to buy anything anytime.” Mission statements are useful, but they don’t say anything about how we plan on accomplishing that. That’s what the product vision is for. Note also that the vision is not in any sense a spec. It’s mainly a persuasive piece that might be in the form of a storyboard, a narrative such as a white paper, or a special type of prototype referred to as avisiontype. 123 Its primary purpose is to communicate this vision and inspire the teams (and stakeholders, investors, partners—and, in many cases, prospective customers) to want to help make this vision a reality. When done well, the product vision is one of our most effective recruiting tools, and it serves to motivate the people on your teams to come to work every day. Strong technology people are drawn to an inspiring vision—they want to work on something meaningful. You can do some amount of testing of the vision, but it’s not the same as the testing of specific solutions we do in product discovery. In truth, buying into a vision is always a bit of a leap of faith. You likely don’t know how, or even if, you’ll be able to deliver on the vision. But remember you have several years to discover the solutions. At this stage, you should believe it’s a worthwhile pursuit. Its primary purpose is to communicate this vision and inspire the teams to want to help make this vision a reality. The product strategy is our sequence of products or releases we plan to deliver on the path to realizing the product vision. I’m using the phrase “products or releases” here loosely. It might be different versions of the same product, a series of different or related products, or some other set of meaningful milestones. For most types of businesses, I encourage teams to construct product strategy around a series of product/market fits. There are many variations on this (the strategy for the product strategy, if you will). For business-focused companies, you might have each product/ market fit focus on a different vertical market (e.g., financial services, manufacturing, automotive). For consumer-focused companies, we often structure each product/market fit around a different customer or user persona. For example, an education-related service might have a strategy that targets high school students first, college students next, and then those already working but who want to learn new skills. Sometimes, the product strategy is based on geography, where we tackle different regions of the world in an intentional sequence. And, sometimes, the product strategy is based on achieving a set of key milestones in some sort of logical and important order. For example, “First deliver critical rating and reviews functionality to developers building e-commerce applications; next, leverage the data generated from this use to create a database of consumer product sentiment; and then leverage these data for advanced product recommendations.” There’s no single approach to product strategy that is ideal for everyone, and you can never know how things might have gone if you sequenced your product work differently. I tell teams that the most important benefit is just that you decided to focus your product work on a single target market at a time. So, all teams know we’re tackling the manufacturing market now, and that’s the type of customers we are obsessing on. Our goal is to come up with the smallest actual deliverable product that makes these manufacturing customers successful. Ideas that come up that pertain to other types of customers or markets are saved for future consideration. Besides significantly increasing your chance of delivering something that can power your business, the product strategy now gives you a tool to align your product work with your sales and marketing organizations. We want the sales organization to sell in the markets where we’ve demonstrated product/market fit.
As soon as we demonstrate product/market fit for a new market (usually by developing an initial set of reference customers), we want the sales force to go out and find as many additional customers in that market as possible.
For a product team to be empowered and act with any meaningful degree of autonomy, the team must have a deep understanding of the broader context. This starts with a clear and compelling product vision, and the path to achieving that vision is the product strategy. The more product teams you have, the more essential it is to have this unifying vision and strategy for each team to be able to make good choices. And, just to be clear—the idea is not that every product team has its own product vision. That would miss the point. The idea is that our organization has a product vision, and all the product teams in that organization are helping to contribute to making that vision a reality.
There are any number of approaches to product strategy, but good strategies have these five principles in common: 1. Focus on one target market or persona at a time. Don’t try to please everyone in a single release. Focus on one new target market, or one new target persona, for each release. You’ll find that the product will still likely be useful to others, but at least it will be loved by some, and that’s key. 2. Product strategy needs to be aligned with business strategy. The vision is meant to inspire the organization, but the organization ultimately is there to come up with solutions that deliver on the business strategy. So, for example, if that business strategy involves a change in monetization strategy or business model, then the product strategy needs to be aligned with this. 3. Product strategy needs to be aligned with sales and goto-market strategy. Similarly, if we have a new sales and marketing channel, we need to ensure that our product strategy is aligned with that new channel. A new sales channel or go-to-market strategy can have a far-reaching impact on a product. 4. Obsess over customers, not over competitors. Too many com panies completely forget about their product strategy once they encounter a serious competitor. They panic and then find themselves chasing their competitor’s actions and no longer focusing on their customers. We can’t ignore the market, but remember that customers rarely leave us for our competitors. They leave us because we stop taking care of them. 5. Communicate the strategy across the organization. This is part of evangelizing the vision. It’s important that all key business partners in the company know the customers we’re focused on now and which are planned for later. Stay especially closely synced with sales, marketing, finance, and service.
The purpose of product discovery is to address these critical risks: • Will the customer buy this, or choose to use it? ( Value risk) • Can the user figure out how to use it? (Usability risk) • Can we build it? (Feasibility risk) • Does this solution work for our business? (Business viability risk) And it’s not enough that it’s just the product manager’s opinion on these questions. We need to collect evidence.
The most important thing is to establish compelling value. It’s all hard, but the hardest part of all is creating the necessary value so that customers ultimately choose to buy or to use. We can survive for a while with usability issues or performance issues, but without the core value, we really have nothing. As a result, this is generally where we’ll need to spend most of our discovery time.
We must validate our ideas on real users and customers. One of the most common traps in product is to believe that we can anticipate our customer’s actual response to our products. We might be basing that on actual customer research or on our own experiences, but in any case, we know today that we must validate our actual ideas on real users and customers. We need to do this before we spend the time and expense to build an actual product, and not after.
Our goal in discovery is to validate our ideas the fastest, cheapest way possible. Discovery is about the need for speed. This lets us try out many ideas, and for the promising ideas, try out multiple approaches. There are many different types of ideas, many different types of products, and a variety of different risks that we need to address (value risk, usability risk, feasibility risk, and business risk). So, we have a wide range of techniques, each suitable to different situations.
We need to validate the business viability of our ideas during discovery, not after. Similarly, it is absolutely critical to ensure that the solution we build will meet the needs of our business—before we take the time and expense to build out that product. Business viability includes financial considerations, marketing (both brand and go-to-market considerations), sales, legal, business development, and senior executives. Few things destroy morale or confidence in the product manager more than finding out after a product has been built that the product manager did not understand some essential aspect of the business.
Most product teams normally think of an iteration as a delivery activity. If you release weekly, you think in terms of one-week iterations. (continued) But we also have the concept of an iteration in discovery. We loosely define an iteration in discovery as trying out at least one new idea or approach. It’s true that ideas come in all shapes and sizes, and some are much riskier than others, but the purpose of discovery is to do this much faster and cheaper than we can do in delivery. To set your expectations, teams competent in modern discovery techniques can generally test on the order of 10–20 iterations per week. This may sound like a lot to you, but you’ll soon see that’s not so hard at all with modern discovery techniques. Also, realize that many iterations never make it beyond just you, your designer, and your tech lead. The very act of creating a prototype often exposes problems that cause you to change your mind.
Product discovery is mostly about quickly trying out an idea. We are essentially trying to separate the good ideas from the bad. Here we are defining a good idea as one that solves the underlying problem in a way that customers will buy, they can figure out how to use, we have the time and skills and technology on the team to build, and that works for the various aspects of our business. It’s important to recognize that many ideas don’t have that much risk associated with them. They may be very straightforward. Or they might just have one area that’s a risk, such as our legal department’s concern about a potential privacy issue. Occasionally, however, we need to tackle much tougher problems, and we may in fact have significant risks in most or even all these areas.
So, the way to think about discovery is that we only validate what we need to, and then we pick the right technique based on the particular situation. Testing Feasibility These techniques are designed for the engineers to address areas where they identify concerns. The solution being tested might require some piece of technology that the team has no experience with. There may be significant scale or performance challenges. Or there might be third-party components that need to be evaluated. Testing Usability These techniques are designed for the product designers to address areas where they have identified concerns. Many of our products have complex workflows and the designers need to ensure their interaction designs make sense to the user and potential sources of confusion are identified and pre-empted. Testing Value Much of our time in product discovery is spent validating value or working to increase the perceived value. If it’s a new product, we need to ensure that customers will buy it, at the price we need to charge, and that they’ll switch from whatever they’re using today. If it’s an existing product, and we are improving that product (such as with a new feature or a new design), where the customer has already bought the product, we need to ensure the customers will choose to use the new feature or new design. Testing Business Viability Sadly, it’s not enough to create a product or solution that our customers love, that is usable, and that our engineers can deliver. The product also must work for our business. This is what it means to be viable. This means that we can afford the cost of building and provisioning the product and the costs to market and sell the product. It needs to be something our sales force is capable of selling. It means that the solution needs to also work for our business development partners. It needs to work for our legal colleagues. It needs to be consistent with our company’s brand promise. These techniques are about validating these types of risks.
More often than not, our initial solutions don’t solve the problem—at least not in a way that can power a successful business.
It usually takes trying out several different approaches to a solution before we find one that solves the underlying problem. This is another reason why typical product roadmaps are so problematic. They’re lists of features and projects where each feature or project is a possible solution. Somebody believes that feature will solve the problem or it wouldn’t be on the roadmap, but it’s all too possible they are wrong. It’s not their fault—there’s just no way to know at the stage it’s put on the roadmap. However, there very likely is a legitimate problem behind that potential solution, and it’s our job in the product organization to tease out the underlying problem and ensure that whatever solution we deliver solves that underlying problem.
There are a few techniques that are central to how Amazon builds product, and one of them is referred to as the working backward process, where you start the effort with a pretend press release. The idea is that the product manager frames the work ahead of the team by writing an imagined press release of what it would be like once this product launches. How does it improve the life of our customers? What are the real benefits to them? You’ve all read a press release before—the only difference is that this is entirely imagined. It is describing a future state we want to create. It’s so tempting for product teams to immediately slip into an enumeration of all the features they plan to build, with little real thought into the actual benefits for our customers. This technique is intended to counter that and to keep the team focused on the outcome, not the output. The actual reader of this press release is the product team, related or impacted teams, and leadership. It’s a terrific evangelism technique—if people don’t see the value after reading the press release, then the product manager has more work to do, or perhaps should reconsider the effort. Some people also consider this a demand-validation technique (if you can’t get your team excited, maybe it’s not worth doing). It’s only validating demand or value with your colleagues rather than with real customers, however, so I think of it primarily as a framing technique. In any case, Walker Lockhart, a former long-time Amazonian who joined Nordstrom a couple of years ago, shared with me a variation of this technique that was developed and refined at Nordstrom. The idea is that rather than communicate the benefits in a press release format, you describe them in the format of a customer letter written from the hypothetical perspective of one of your product’s well-defined user or customer personas. The letter—sent to the CEO from a very happy and impressed customer—explains why he or she is so happy and grateful for the new product or redesign. The customer describes how it has changed or improved his or her life. The letter also includes an imagined congratulatory response from the CEO to the product team explaining how this has helped the business. I hope you can see that this customer letter variation is very similar to Amazon’s imagined press release, and it is intended to drive much the same type of thinking. A press release version includes a customer quote as well. I like this customer letter variation even better than the press release style for a couple of reasons. First, the press release format is a bit dated. The press release doesn’t play the role it used to in our industry, so it’s not something that everyone is familiar with. Second, I think the customer letter does an even better job of creating empathy for the customer’s current pain and more clearly emphasizes to the team how their efforts can help the lives of these customers. I will also admit that I love actual customer letters. I find them to be extremely motivating. And it’s worth noting that even when a customer letter is critical of the product, it helps the team to understand the problem viscerally, and they often feel compelled to find a way to help.
In every user or customer interaction, we always have the opportunity to learn some valuable insights. Here’s what I’m always trying to understand: • Are your customers who you think they are? • Do they really have the problems you think they have? • How does the customer solve this problem today? • What would be required for them to switch?
Establish a regular cadence of customer interviews. This should not be a once-in-a-while thing. A bare minimum would be two to three hours of customer interviews per week, every week.
It’s always amazing to see customers in their native habitat. There’s so much to learn just by observing their environment. But it’s also fine to meet them somewhere convenient or have them come to your office. If you need to do this over a video call, that’s not as good, but much better than not doing at all.
A concierge test is a relatively new name to describe an old but effective technique. The idea is that we do the customer’s job for them—manually and personally. Just as if you went to a hotel concierge and asked if he could find you some theater tickets to a popular show. You don’t really know the details of what that concierge is doing for you to get those tickets, but you do know that he is doing something. With this technique, you become the concierge. You do what the user or customer needs done for them. You may have to ask them to train you first, but you are in their shoes doing the tasks they would do. This is similar, but not the same, as spending some time with your customer service or customer success staff. That is also valuable, and often a good source of product ideas as well, but that is helping customers once they call with a problem. A concierge test requires going out to the actual users and customers and asking them to show you how they work so that you can learn how to do their job, and so that you can work on providing them a much better solution. If you are building a customer-enabling product, the users may be employees of your company, but the technique is the same—you go to these colleagues and ask them to teach you how they do their job. Like the principle of shared learning, it is most valuable if the product manager, the product designer, and one of the engineers does the concierge test.
Some product people can get upset when they find customers using their products for unintended use cases. This concern is usually tied to the support obligations. I’m suggesting, however, that this special case can be very strategic and well worth the investment to support. If you find your customers using your product in ways you didn’t predict, this is potentially very valuable information. Dig in a little and learn what problem they are trying to solve and why they believe your product might provide the right foundation. Do this enough and you’ll soon see patterns and, potentially, some very big product opportunities.
All forms of prototypes have certain characteristics and benefits in common. Here are five key principles behind their use. 1. The overarching purpose of any form of prototype is to learn something at a much lower cost in terms of time and effort than building out a product. All forms of prototype should require at least an order of magnitude less time and effort as the eventual product. 2. Realize that one of the key benefits of any form of prototype is to force you to think through a problem at a substantially deeper level than if we just talk about it or write something down. This is why the very act of creating a prototype so often exposes major issues otherwise left uncovered until much later. 3. Similarly, a prototype is also a powerful tool for team collaboration. Members of the product team and business partners can all experience the prototype to develop shared understanding. 4. There are many different possible levels of fidelity for a prototype. The fidelity primarily refers to how realistic the prototype looks. There is no such thing as one appropriate level of fidelity. Sometimes we don’t need the prototype to look realistic at all, and other times it needs to be very realistic. The principle is that we create the right level of fidelity for its intended purpose, and we acknowledge that lower fidelity is faster and cheaper than higher fidelity, so we only do higher fidelity when we need to. 5. The primary purpose of a prototype is to tackle one or more product risks (value, usability, feasibility, or viability) in discovery; however, in many cases, the prototype goes on to provide a second benefit, which is to communicate to the engineers and the broader organization what needs to be built. This is often referred to as prototype as spec. In many cases, the prototype is sufficient for this, but in other cases—especially when the engineers are not co-located or when the product is especially complex—the prototype will likely need to be supplemented with additional details (usually, use cases, business rules, and acceptance criteria).
Most of the time your engineers will review your product ideas and tell you that they have no real concerns about feasibility. This is because they have likely built similar things many times before. However, there are several situations wherein your engineers may identify a significant feasibility risk involved in solving a particular problem they are working on. Common examples include: • Algorithm concerns • Performance concerns • Scalability concerns • Fault tolerance concerns • Use of a technology the team has not used before • Use of a third-party component or service the team has not used before • Use of a legacy system the team has not used before • Dependency on new or related changes by other teams The idea is to write just enough code to mitigate the feasibility risk. The main technique used for tackling these types of risks is for one or more of the engineers to build a feasibility prototype. An engineer will create the feasibility prototype because it is typically code (as opposed to most prototypes created by special-purpose tools intended to be used by product designers). A feasibility prototype is a long way from a commercially shippable product—the idea is to write just enough code to mitigate the feasibility risk. This typically represents just a small percentage of the work for the eventual shippable product. Further, most of the time the feasibility prototype is intended to be throwaway code—it’s okay and normal to be quick and dirty with this. It is intended to be just enough to collect the data, for example, to show that performance would likely be acceptable or not. There is usually no user interface, error handling, or any of the typical work involved in productization.
Customers don’t have to buy our products, and users don’t have to choose to use a feature. They will only do so if they perceive real value. Another way to think about this is that just because someone can use our product doesn’t mean they will choose to use our product. This is especially true when you are trying to get your customers or users to switch from whatever product or system they were using before to your new product. And, most of the time, our users and customers are switching from something—even if that something is a homegrown solution. So many companies and product teams think all they need to do is match the features (referred to as feature parity), and then they don’t understand why their product doesn’t sell, even at a lower price. The customer must perceive your product to be substantially better to motivate them to buy your product and then wade through the pain and obstacles of migrating from their old solution. All of this is a long way of saying that good product teams spend most of their time on creating value. If the value is there, we can fix everything else. If it’s not, how good our usability, reliability, or performance is doesn’t matter.
Sometimes it’s unclear if there’s demand for what we want to build. In other words, if we could come up with an amazing solution to this problem, do customers even care about this problem? Enough to buy a new product and switch to it? This concept of demand testing applies to entire products, down to a specific feature on an existing product. We can’t just assume there’s demand, although often the demand is well established because most of the time our products are entering an existing market with demonstrated and measurable demand. The real challenge in that situation is whether we can come up with a demonstrably better solution in terms of value than the alternatives.
I want to emphasize the most important point for technology companies: If you stop innovating, you will die. Maybe not immediately, but if all you do is optimize your existing solutions, and you stop innovating, it is only a matter That said, we need to do of time before you are someone this in a responsible way. else’s lunch.
I believe it’s a non-negotiable that we simply must continue to move our products forward, and deliver increased value to our customers.
Qualitative testing of your product ideas with real users and customers is probably the single most important discovery activity for you and your product team. It is so important and helpful that I push product teams to do at least two or three qualitative value tests every single week. Here’s how to do it: Interview First We generally begin the user test with a short user interview where we try to make sure our user has the problems we think she has, how she solves these problems today, and what it would take for her to switch (see Customer Interview Technique). Usability Test We have many good techniques for testing value qualitatively, but they all depend on the user first understanding what your product is and how it works. This is why a value test is always preceded by a usability test. During the usability test, we test to see whether the user can figure out how to operate our product. But, even more important, after a usability test the user knows what your product is all about and how it’s meant to be used. Only then can we have a useful conversation with the user about value (or lack thereof). Preparing a value test therefore includes preparing a usability test. I described how to prepare for and run a usability test in the last chapter, so for now let me again emphasize that it’s important to conduct the usability test before the value test, and to do one immediately after the other. If you try to do a value test without giving the user or customer the opportunity to learn how to use the product, then the value test becomes more like a focus group where people talk hypothetically about your product, and try to imagine how it might work. To be clear: focus groups might be helpful for gaining market insights, but they are not helpful in discovering the product we need to deliver (see Product Discovery Principle 1).
You might determine that you just aren’t able to get people interested in this problem, or you can’t figure out a way to make this usable enough that your target users can realize this value. In that case, you may decide to stop right there and put the idea on the shelf. Some product managers consider this a big failure. I view it as saving the company the wasted cost of building and shipping a product your customers don’t value (and won’t buy), plus the opportunity cost of what your engineering team could be building instead.
The two big reasons why stakeholders especially are so attracted to roadmaps: 1. They want some visibility into what you are working on and assurance that you are working on the most important items. 2. They want to be able to plan the business and need to know when critical things will happen.
In terms of the stakeholders, the product manager has the responsibility to understand the considerations and constraints of the various stakeholders, and to bring this knowledge into the product team. It doesn’t do anyone any good to build things that may work for the customer, but then at some review meeting find out that you’re not allowed to deploy what was created. This happens much more than you might realize, and every time it does happen, the company loses a little more confidence in the product team.
However, beyond understanding the constraints and concerns of each stakeholder, if you want the latitude to come up with the most-effective solutions, then it’s critically important that the product manager convince each of these stakeholders that she not only understands the issues, but that she is committed to coming up with solutions that not only work for the customer, but also work for the stakeholder as well. And this must be sincere. I emphasize this because, if the stakeholder does not have this trust that you are going to solve for their concerns as well, then they will either escalate, or they will try to control.
Success in terms of stakeholder management means that your stakeholders respect you and your contribution. They trust that you understand their concerns and will ensure solutions work well for them too. They trust that you will keep them informed of important decisions or changes. And, most of all, they give you the room to come up with the best solutions possible, even when those solutions end up being quite different from what they might have originally envisioned. It’s not that difficult to have this kind of relationship with stakeholders, but it does require first and foremost that you are a competent product manager. This especially means having a deep understanding of your customers, the analytics, the technology, your industry, and in particular, your business. Without this, they won’t trust you (and in fairness they shouldn’t). The main way we demonstrate this knowledge to the organization is by sharing very openly what we learn. With this as a foundation, the key technique is to spend one-on-one time with the key stakeholders. Sit down with them and listen. Explain that the better you understand their constraints, the better your solutions will be. Ask lots of questions. Be open and transparent. One of the most common mistakes product managers make with stakeholders is that they show them their solution after they have already built it. And, sometimes, there are issues because the product manager did not have a clear enough understanding of the constraints. Not only will the stakeholder be frustrated, but your engineering team will be frustrated as well with all the rework. So, commit to previewing your solutions during discovery with the key stakeholders before you put this work on the product backlog.
This is one of the keys of product discovery. In discovery, you are not only making sure that your solutions are valuable and usable (with customers), and feasible (with engineers), but you are also making sure your stakeholders will support the proposed solution.
The other big mistake I often see being made is when situations boil down to the product manager’s opinion versus the stakeholder’s opinion. In this case, the stakeholder usually wins because he or she is usually more senior. However, as we’ve already discussed many times before, the key is to change the game by quickly running a test and collecting some evidence. Move the discussion from opinions to data. Share what you’re learning very openly. It may be that neither of your opinions were right. Again, the discovery work is designed specifically as a place for these tests. Mostly this is about creating a collaborative, mutually respectful personal relationship. For most companies, it takes about two to three hours a week—meeting for half an hour or so with each key stakeholder—to keep them apprised, and to get their feedback on new ideas. My favorite way to do this is a weekly lunch or coffee with your most-involved stakeholders.
Many product managers tell me that the way they deal with testing business viability with all their different stakeholders is by scheduling a large, group meeting and inviting all the stakeholders. The product manager then presents to them what they want to build, usually with a PowerPoint presentation. There are two very serious (potentially career limiting) problems with this. First, presentations are notoriously terrible for testing business viability. The reason is that they are far too ambiguous. A lawyer needs to see the actual proposed screens, pages, and wording. A marketing leader wants to see the actual product design. A security leader needs to see exactly what the product is trying to do. Presentations are terrible for this. In contrast, high-fidelity user prototypes are ideal for this. I plead with product managers in larger companies to not trust a sign-off on anything other than a high-fidelity prototype. I have seen far too many times where the execs agree to something based on a presentation, but when they see the actual product, they are completely shocked, frustrated, and often visibly angry. The second problem is that a group setting is not the forum for designing strong products. It results in design by committee, which yields mediocre results at best. Instead, meet privately with each stakeholder, show them the high-fidelity prototype, and give them the chance to raise any concerns. This may sound like more work to you, but please believe me that, in the long run, it will turn out to be far less work, time, and grief. One final note: in many companies, some of the stakeholders may not even understand what product does, and some may even feel threatened by the role. Be sensitive to this. You may need to spend some time explaining the role and how technology-enabled product companies operate and why.
Organizations that lose the ability to innovate at scale are inevitably missing one or more of the following attributes: 1. Customer-centric culture. As Jeff Bezos, the CEO of Amazon says, “Customers are always beautifully, wonderfully dissatisfied, even when they report being happy and business is great. Even when they don’t yet know it, customers want something better, and your desire to delight customers will drive you to invent on their behalf.” Companies that don’t have this focus on customers—and direct and frequent contact with them—lose this passion and critical source of inspiration. 2. Compelling product vision. By the time many companies reach scale, their original product vision is now largely realized, and the team is struggling to understand what’s next. This is often compounded because the original founders may have moved on, and they were likely the keepers of the vision. In this case, someone else—usually either the CEO or the VP product—needs to step up and fill this void. 3. Focused product strategy. One of the surest paths to product failure is to try to please everyone at once. Yet large companies often forget this reality. The product strategy needs to spell out a logical and intentional sequence of target markets for the product teams to focus on. 4. Strong product managers. The lack of a strong and capable product manager is typically a major reason for lack of product innovation. When a company is small, the CEO or one of the co-founders usually plays this role, but at scale, each product team depends on a strong and capable product manager. 5. Stable product teams. One of the prerequisites for consistent innovation is a team that has had a chance to learn the space, technologies, and customer pain. This doesn’t happen if the members of the team are constantly shifting. 6. Engineers in discovery. So often the key to innovation is the engineers on the team, but this means (a) including them from the very beginning, and not just at the end and (b) exposing them directly to the customer pain. 7. Corporate courage. It’s no secret that many companies become extremely risk averse as they grow larger. There is, of course, much more to lose. But the best technology-product companies know that the riskiest strategy of all is to stop taking risks. We do have to be smart about how we work, but the willingness to risk disruption to our current business is essential to consistent innovation. 8. Empowered product teams. Even though your organization might have begun by using best practices, many organizations regress as they scale, and if you’ve reverted to just handing your teams roadmaps of features, then you no longer can expect the benefits of empowered product teams. Remember that empowerment means the teams are able to tackle and solve the business problems they’ve been assigned in the best way they see fit. 9. Product mindset. In an IT-mindset organization, the product teams exist to serve the needs of the business. In contrast, in a product-mind set organization, the product teams exist to serve the company’s customers in ways that meet the needs of the business. The resulting differences between these mind sets are many and profound. 10. Time to innovate. At scale, it’s very possible that your product teams are entirely consumed just doing what we call keep the lights on activities. Fixing bugs, implementing capabilities for different parts of the business, addressing technical debt, and more. If this is your situation, you shouldn’t be surprised at the lack of innovation. Some of this is normal and healthy, but be sure that your teams have the room to also pursue harder and more impactful problems.
As organizations grow, it’s not unusual for things to slow down. They don’t need to, and in the best organizations, they can accelerate. But if you are seeing a slowdown, these are the first things to look for. 1. Technical debt. Often, the architecture does not facilitate or enable the rapid evolution of the product. This is not something that can be fixed overnight, but it needs to be attacked in an ongoing and concerted effort. 2. Lack of strong product managers. The lack of a strong and capable product manager is typically a major reason for slow product. The impact of a weak product manager shows up in many ways, but it shows up very visibly as a team of mercenaries rather than missionaries. The product manager has not inspired or evangelized to the team, or the team has lost confidence in their product manager. 3. Lack of delivery management. The most important function of the delivery manager is to remove impediments, and the list of impediments grows non-linearly as the technology organization grows. Most impediments won’t go away quickly without someone actively chasing them down. 4. Infrequent release cycles. Most teams with slow velocity have release vehicles that are too infrequent. Your team should release no less frequently than every two weeks (very good teams release multiple times per day). Correcting this typically means getting serious about test automation and release automation so the team can move quickly and release with confidence. 5. Lack of product vision and strategy. It’s essential that the team have a clear vision of the big picture and how their immediate work contributes to the whole. 6. Lack of co-located, durable product teams. If teams are split across locations—or worse, if engineers are outsourced—besides the dramatic decrease in innovation, the velocity of the organization will suffer significantly. Even simple communication becomes difficult. It gets so bad that many outsourcing firms will add another layer of people to coordinate and communicate, which usually makes things worse. 7. Not including engineers early enough during product discovery. The engineers need to participate in product discovery from the start of ideation. They will often contribute alternative approaches that can be significantly faster to implement if you include them early enough in the process for the product manager and designer to adjust. If not, their critical input will come too late in the process. 8. Not utilizing product design in discovery and instead having them try to do their work at the same time engineers are trying to build. Not doing this will both slow things down and lead to poor designs. 9. Changing priorities. Realize that rapidly shifting priorities cause significant churn and substantially reduces the total throughput and morale. 10. A consensus culture. Many organizations strive for consensus. While this typically comes from good intentions, what this means in practice is decisions are very hard to make and everything slows to a crawl.
What does it really mean to have a strong innovation culture? • Culture of experimentation— teams know they can run tests; some will succeed and many will fail, and this is acceptable and understood. • Culture of open minds—teams know that good ideas can come from anywhere and aren’t always obvious at the outset. • Culture of empowerment—individuals and teams feel empowered to be able to try out an idea. • Culture of technology—teams realize that true innovation can be inspired by new technology and analysis of data, as well as by customers. • Culture of business- and customer-savvy teams—teams, including developers, have a deep understanding of the business needs and constraints, and understanding of (and access to) the users and customers. • Culture of skill-set and staff diversity—teams appreciate that different skills and backgrounds contribute to innovative solutions—especially engineering, design, and product. • Culture of discovery techniques—the mechanisms are in place for ideas to be tested out quickly and safely (protecting brand, revenue, customers, and colleagues). What does it really mean to have a strong execution culture? • Culture of urgency—people feel like they are in wartime, and that if they don’t find a way to move fast, then bad things could happen. • Culture of high-integrity commitments—teams understand the need for (and power of) commitments, but they also insist on high-integrity commitments. • Culture of empowerment—teams feel as though they have the tools, resources, and permission to do whatever is necessary to meet their commitments. Establishing a Strong Product Culture • Culture of accountability—people and teams feel a deep responsibility to meet their commitments. Accountability also implies consequences—not necessarily being terminated, except in extreme and repeated situations, but more likely consequences to their reputations among their peers. • Culture of collaboration—while team autonomy and empowerment is important, teams understand their even higher need to work together to accomplish many of the biggest and most meaningful objectives. • Culture of results—is the focus on output or is the focus on results? • Culture of recognition—teams often take their cues from what is rewarded and what is accepted. Is it just the team that comes up with the great new idea that gets rewarded, or the team that delivered on a brutally tough commitment? And what is the message if missing a commitment is seen as easily excusable?