INSPIRED

by Marty Cagan

  I think this is at least partly because risk is subjective and hard to quantify. So, depending on your perspective, you may think some risk is secondary when I think it is primary.

  Mostly, however, I think the major reason is that it's human nature for people to focus more on those areas they feel they can control and are knowledgeable about.

  So, let's say your startup founder is someone who comes from a business background, probably trained as an MBA. He or she is likely acutely aware of the risks associated with coming up with a good business model. They're often focused on unique value proposition, pricing, channels, and costs. These are all real risks, which are part of assessing business viability.

  But, I will often have to sit these people down and explain that, while these are real risks, they are largely academic at this stage. And then I try to point them at what, in my experience, is the biggest reason that startups and new products fail.

  You're probably thinking that I'm speaking of market risk—that the new product is focused on solving a problem that customers just don't care enough about. This is a very real risk, and one that's responsible for its share of failed efforts, but I argue this is not usually the most significant risk.

  I need to mention a couple caveats here.

  First, I have to say that the vast majority of the teams I meet are not solving truly new problems. They are working on long‐standing problems with long‐proven markets. What's different about the startup or product is their approach to solving the problem (their solution), most often—and increasingly—because they are leveraging newly available technology to solve the problem in an innovative way.

  Second, if the market is indeed new, then today the techniques we have for validating demand have never been better. If you don't use these techniques, you proceed at your own peril. This is an especially egregious mistake because the techniques are not expensive in terms of money and time, so there's just no excuse not to do this.

  I believe the major risk facing most efforts is value risk. On a startup canvas, this shows up under solution risk—discovering a compelling solution to customers. A solution that your customers will choose to buy and use.

  This is generally hard enough but realize that to get someone to switch to our new product, it's not enough that it's comparable (sometimes referred to as feature parity), it must be demonstrably and substantially better. This is a high bar.

  However, if you've created a canvas before, you know that there's precious little in there about the solution. The official rationale for that is that it's far too easy to fall in love with your particular approach and lock yourself in prematurely. In fairness, this is a very real issue with teams. I see this behavior frequently. But a consequence of this meager representation of the solution in a canvas is that it plays to the tendency of many to focus on those risks they feel more comfortable with and leave the solution as “an exercise for the engineers.”

  Rather than delegating or deferring figuring out the solution, we need to embrace product discovery as the most important core competency of the startup.

  Look, if you can discover a solution that your customers love, then you can tackle the risks of monetization and scale. However, without that solution, the rest of your work is very likely going to be wasted. So, whether your constrained resource is cash or management's patience, you need to make sure you primarily use your time to discover a winning solution. Get that risk resolved first and then you can focus on the other risks.

  The point is that you don't need to spend your time doing pricing optimization testing, sales tools, marketing programs, and cutting costs, until and unless you have discovered a truly valuable product.

  Discovery Planning Techniques

  Overview

  Now that we've framed our discovery work, we're ready to jump in and start figuring out solutions. For complicated product efforts, it often helps to have some way to scope out and plan your discovery efforts.

  In this section, I describe two of my favorite discovery‐planning techniques. One is simple (story maps), and the other is fairly complicated (customer discovery program), but they are both remarkably powerful and effective.

  I don't want to scare you away from a technique just because it's a lot of work. I often tell product teams that if they could only pick a single technique, the one I'd recommend is the customer discovery program. Yes, it's a lot of time and effort—especially on the shoulders of the product manager—but it's my favorite leading indicator of future success. I attribute much of the success in my own career to this technique.

  CHAPTER 38

  Story Map Technique

  Story maps are one of the most generally useful techniques I know. They are essentially a framing and planning technique, but they are just as useful for ideation. They are also used as a design technique when working on prototypes, and they are great for communicating with your team and stakeholders. They also play a very practical role in managing and organizing your work. Further, a story map is helpful throughout product discovery and delivery.

  I think you'll agree that's a lot of benefits. But the best part is how simple it is.

  The origin of story maps came from frustration with the typical flat backlog of user stories. There's no context, just a prioritized list of stories. How can the team know how one story fits in with the big picture? What does it mean to even prioritize at that granularity with so little context? And what set of stories constitutes a meaningful milestone or a release?

  Jeff Patton, one of the early Agile thinkers, was frustrated by this, so he leveraged some proven UX design techniques, and adapted them to Agile concepts and introduced user story maps.

  Many teams I know consider a high‐fidelity user prototype and a story map as their go‐to techniques.

  These are two‐dimensional maps, in which major user activities are arrayed along the horizontal dimension, loosely ordered by time from left to right. So, if there are a dozen major user activities, they would be along the top from left to right, generally in the order you would do them—or at least, if you were describing the overall system to someone else, the order in which you'd describe them.

  Along the vertical dimension, we have a progressive level of detail. As we flesh out each major activity into sets of user tasks, we add stories for each of those tasks. The critical tasks are higher vertically than the optional tasks.

  If you lay out your system this way, you can, at a glance, get the holistic view and consider where to draw the line in terms of different releases and their associated objectives.

  Now each story has context. The entire team can see how it fits in with the other stories. And not just as a snapshot in time. The team can see how the system is expected to grow over time.

  We can use this story map to frame our prototypes, and then as we get feedback on our prototypes and learn how people interact with our product ideas, we can easily update the story map to serve as a living reflection of the prototypes. As we finalize our discovery work and progress into delivery, the stories from the map move right into the product backlog.

  Many teams I know consider a high‐fidelity user prototype and a story map as their go‐to techniques.

  Another must‐read book for product managers: User Story Mapping: Discover the Whole Story, Build the Right Product, by Jeff Patton (O'Reilly Media, 2014).

  CHAPTER 39

  Customer Discovery Program Technique

  Our job in the product organization is to create products that can sustain a business. Make no mistake about it: Everything depends on strong products.

  Without strong products, our marketing programs require customer acquisition costs that are too high; our sales organization is forced to get “creative,” which drives up cost of sales, lengthens the sales cycle, and puts downward pressure on price; and our customer success organization is forced to take it on the chin every day with frustrated customers.

  The downward spiral continues because the sales organization loses a
lot of deals when they try to compete with a weak product. So, what do they do? They start yelling at you about all the features you don't have, and the competitor they lost to who does, which typically just makes the bad situation even worse. And then you start complaining about working at a sales‐driven company.

  Many of you may be thinking I've just described your company. Sadly, I find this to be the state of affairs in far too many companies, especially those with either a direct sales organization or an advertising sales organization.

  This entire book, in one way or another, is intended to prevent or correct this situation. However, in this chapter, I talk about what I consider one of the most powerful techniques we have to ensure and prove we have a strong, viable product and prevent the situation I've just described.

  The Power of Reference Customers

  First, we need to talk about the nearly magical power of a happy reference customer.

  There are few things more powerful to a product organization than reference customers.

  Let's be clear about what it means to be a reference customer: This is a real customer (not friends or family), who is running your product in production (not a trial or prototype), who has paid real money for the product (it wasn't given away to entice them to use it), and, most important, who is willing to tell others how much they love your product (voluntarily and sincerely).

  Please believe me when I say that there are few things more powerful to a product organization than reference customers. It is the single best sales tool you can provide to your sales and marketing organization, and it completely changes the dynamics between the product organization and the rest of the company.

  Ask any good salesperson the single best tool you can provide to help her do her job, and she'll say, “happy reference customers.”

  If you find that you're constantly frustrated by having to react to sales and the latest big‐deal prospect they've managed to bring in, this is how you turn the situation around.

  Without reference customers, it's very hard for the sales team to know where the real product/market fit is. And remember—they have a quota and are paid by commission. So, without good examples, they will sell however and whatever they can. Without reference customers, this situation is not their fault—it's your fault.

  We are discovering and developing a set of reference customers in parallel with discovering and developing the actual product.

  The reason I love the customer discovery program technique so much is because it is designed to produce these reference customers.

  We are discovering and developing a set of reference customers in parallel with discovering and developing the actual product.

  I will warn you that this technique takes substantial effort, primarily on the part of the product manager. I wish it were easier. But I will also say that if you do this technique, I consider it the single best leading indicator of future product success.

  I will also say that this technique is not new, although every few years some influential person in the product world rediscovers its power and it gets attention once again. It also goes by multiple names. In any case, I'm convinced that everyone would do the technique if it didn't require so much actual work.

  There are four main variations of this technique for four different situations:

  Building products for businesses

  Building platform products (e.g., public APIs)

  Building customer‐enabling tools used by employees of your company

  Building products for consumers

  The core concept is the same for all four variations, but there are some differences. I'll describe the variation for businesses first and then describe the differences for each of the other uses.

  I also need to point out that you would not do this program for small efforts like features or minor projects. This is for larger efforts. Good examples would be creating a new product or business, taking an existing product to a new market or new geography or a redesign of a product.

  The basic driver behind this technique is that, with a significant new product, the most common objection is that prospective customers want to see that other companies, like themselves, are already successfully using the product. They want to see the reference customers. In general, the more reference customers the better but too few, and the prospective customer is worried that the product is a special and only works for those one or two customers.

  For products and services aimed at businesses, I was taught years ago that the key number is six reference customers. This is not meant to be statistically significant—it is meant to instill confidence—and I have found that number has held up over time. Again, more than six would be even better, but we shoot for six because each one is a lot of work.

  Single Target Market

  Now these are not just any six customers. We are looking to develop six reference customers in our specific target market or segment, so, the idea is to find six similar customers. If you end up targeting two or three customers from two or three different markets, this program will not give you the focus you want and need.

  In the earlier chapters on product vision and strategy, we talked about the product strategy of pursuing a product vision by tackling one vertical market after another. For example, first develop six references for the financial services industry, then six for the manufacturing industry, and so on. Or you can expand geographically in this same manner (for example, first develop six references for the United States, six for Germany, and then six for Brazil, and so on).

  I do my best to persuade teams to not launch a product in the marketplace until after they have those six reference customers. We don't want to turn on the sales or marketing machine until we have evidence that we can help them be successful, and the reference customers are our best evidence.

  The concept behind this technique is to focus on developing this set of reference customers for a specific target market, which then makes it easy for sales to go after those specific types of customers. Once we have those reference customers for that initial target market, we can move on to expanding the product to meet the needs of the next target market.

  Recruiting the Prospective Reference Customers

  We want to end with six reference customers, so we'll typically recruit between six and eight in case one or two turn out to be not a match or unavailable. We need them to be from the specific target market we are going after. They may be from your existing customer base, prospects, or a blend.

  We are looking for prospective customers that truly feel the pain and are near desperate for the solution we want to build. If they could find a solution that worked for them elsewhere, they would have already bought it.

  However, it's also important we screen out technologists. These people are mainly interested because of the technology, not because they desperately need the business value.

  We need them to have people and time willing to work closely with us. They need to be willing to spend time with the product team, testing out early prototypes and helping the team ensure the product works well for them. If possible, we would like them to be well‐recognized marquee names, because that will be of the most value to the sales and marketing staff.

  Coming up with the right set is normally something the product manager does in tight collaboration with the product marketing manager.

  The Relationship

  The benefit to the prospective customer is that they get real input, not lip service, to the solution—and, most important, they get a solution that truly works for them.

  The benefit to the product team is that you get ready access to a set of users and customers that you can go deep with and figure out a solution that will work for them. They've provided you access to their users. They have agreed to test early versions. And, what's really important, they have agreed to buy the product and serve as a public reference if the resulting product works for them.

  It's critical to explain to each prospective member of the program that you
r job is to come up with a general product—something your company can successfully sell to a large number of customers. You're not trying to build a custom solution that only works for that one company (and they wouldn't want that in any case as they would be left with unsupported, dead‐end software). You are, however, deeply committed to coming up with a product that works extremely well for them and just a handful of other companies.

  Further, your job as product manager is not to put in the features that all six companies request. While that would be much easier, that would yield an awful product. Your job is to dive deep with each of the six customers and identify a single solution that works well for all six customers.

  There are a number of important points to consider with this technique.

  Not everyone agrees with me on this, but I don't personally like the customer to pay in advance to participate in this program. That makes this a different type of relationship. You want a partner in coming up with the product. You do not want to build a custom solution just for them, and you're not a custom project shop. You can take their money after you deliver them a product they love. That said, if you're a very early stage startup with little cash, you may have to bend this rule just a bit. A compromise is to have them put the money into escrow.

  If you are working on an important and difficult problem, you will likely be overwhelmed with customers that want to participate. It really is a good deal, and customers know this. If you have a sales organization, they'll try to use this as a bargaining chip, and the result is that you'll be leaned on to include many more customers than you can handle. This will take finesse at times, but it's important that the members of the customer discovery program be the right set, and no more than eight. However, it's no problem also having an early release program that is essentially unlimited for those customers that want the software early, but you determine aren't right for the customer discovery program.