by Marty Cagan
Note that, in many cases, you'll get people who say they are extremely interested in this product, but they first want to see your references. When you explain you're looking to work with them to become one of those references, they will probably say they are just too busy, but to come back once you have the references. That's fine. They're a useful lead. But we are looking for those customers that are so hungry and desperate for a solution that they will absolutely make time for this. Every market has this segment.
That said, if you find you are having real trouble recruiting even four or five prospective customers for this effort, then it's very possible you're chasing a problem that isn't that important, and you will almost certainly have a very hard time selling this product. This is one of the very first reality checks (aka demand validation) to make sure you're spending your time on something worthwhile. If customers aren't interested in this problem, you may want to rethink your plans.
You need to make sure your customers are truly from your target market and not more than one target market. A big benefit of this program is focus, and that means the customers are from a single target market.
You will want to work with your product marketing manager to ensure that the prospective customer has permission from their marketing organization to serve as a public reference. You will also want to keep your product marketing partner continuously involved in this program as she can help turn your reference customer into some great sales tools and collateral. But, remember, it is your job to develop those actual reference customers—so be sure you deliver a product they love.
Think of these early prospective customers as development partners. You're in this together. You need to treat them as colleagues—open the kimono, you are helping each other. You'll find that the relationships you create can last for many years.
You will be interacting with these people throughout the effort—you'll be showing them prototypes and testing with their users, you'll be asking many detailed questions, and you'll be testing early versions in their environment.
Make sure you release the delivered product to these people before the general release, and make sure they are live and happy before the release. When you launch, they'll be ready to stand up for you.
Now let's consider the common variations of this program for different types of products.
Platform/API Products
For developer products, the program is very much like the one for businesses, but the main difference is that we work with the development teams (engineers and product managers) that will use our APIs to get them successfully using our product. The result of the program is a set of reference applications rather than reference customers. We focus on the successful applications created with our APIs.
Customer‐Enabling Tools
For customer‐enabling tools, such as a new dashboard for your customer service agents, we pick six to eight well‐respected, influential internal users/employees—the individuals that the other agents look up to as thought leaders—and we work closely with them to discover the necessary product. Obviously, they are not customers and not paying anything, but instead we ask them to work closely with us through product discovery to make this tool great. Once they believe that the product is ready, we ask them to tell their colleagues how much they love the new tool.
Consumer Products
For consumer products, the same general concept applies. But, rather than focusing on six businesses to work closely with (where we have access to many different users at each customer), we instead focus on a somewhat larger number of consumers (on the order of 10–50) that we engage with to get them to the point that they are loving our product.
It's important to emphasize that, for consumer products, we will need to supplement this program with much broader testing of our product ideas—typically with people that have never been exposed to the product. But it is often very helpful to have a smaller group of prospective users that we can go back to over time, and that's what this is for.
In terms of marketing, when a consumer decides to buy or use a product, they may not look at reference customers as a business purchaser would. But they are affected by social media, the press, and other influencers, and when the press does write a story about your product, the first thing they'll look for is real users.
Summary
While you can see this may be a lot of effort, especially for the product manager, this powerful technique help ensures that you're building a product that customers love.
Remember that this technique is not designed to discover the necessary product—that comes next. Rather, it is designed to give you direct access to the target customers where you'll find the product ideas necessary to generate reference customers.
Defining Product/Market Fit
Product/market fit shows up in terms of happier customers, lower churn rates, shortened sales cycles, and rapid organic growth.
There are many ways of defining this critically important concept of product/market fit. Unfortunately, most of them are largely subjective.
It is true that product/market fit is one of those things that “you know it when you see it.” It certainly shows up in terms of happier customers, lower churn rates, shortened sales cycles, and rapid organic growth. But the threshold for any of these can be tough to define.
Companies often spend countless hours debating what product/market fit should mean for them and whether they have achieved it.
One of the most common techniques for assessing product/market fit is known as the Sean Ellis test. This involves surveying your users (those in your target market that have used the product recently, at least a couple times, and you know from the analytics that they've at least made it through to the core value of the product) and asking them how they'd feel if they could no longer use this product. (The choices are “very disappointed,” “somewhat disappointed,” “don't care,” and “no longer relevant because I no longer use.”). The general rule of thumb is that if more than 40 percent of the users would be “very disappointed,” then there's a good chance you're at product/market fit.
While useful, as you might imagine there are lots of caveats here, depending on the type of product and the size of the sample. I like this test for consumer products and services, but for products for businesses, one of the reasons I like this customer discovery program so much is that I consider this a very practical and very effective definition of product/market fit.
If we can get to the point where we have six reference customers in a specific target market, we will typically declare product/market fit for that market.
Remember product/market fit does not mean that you are done with working on that product. Not even close. We will continue to improve that product continuously for years. However, once we have those six reference customers, we can aggressively and effectively sell that product to other customers in that market.
So, each reference customer is a truly significant milestone. But, for example, getting six reference customers in a given target market for a B2B company is perhaps the most significant, meaningful milestone business result for a product organization and something truly worth celebrating.
CHAPTER 40
Profile: Martina Lauchengco of Microsoft
In 1993, Word 6.0 was the biggest release, feature‐wise, Microsoft had ever produced.
In addition to all the new features, the team had another very large objective. Their code base had diverged, and it was extremely slow and costly for Microsoft to implement Word separately for each platform: Windows, DOS, and Mac. This code convergence effort was supposed to save Microsoft substantial development time, and—they tried to convince themselves—improve the offering since Word would have the same features on every platform.
It also meant that there was great pressure to get the release out so they could start to gain the efficiencies of a single code base.
At the time, Word for Mac was a relatively small market. It was only $60 million, versus Windows, w
hich at that point was more than a $1 billion market. If you remember, back then Windows machines absolutely dominated, and the future of Apple was not a sure thing. However, the Mac community was also very vocal—with passionate fans of their platform—and this community had very little love for Microsoft.
PowerMacs were just hitting the market, which had significantly faster chips and more memory. Most of the team members were using those new computers because the Word 6.0 beta in its early days was just too slow on regular Macs. Of course, most of the Mac user base was not on new PowerMacs—they were on regular Macs. Hardware upgrade cycles were much slower then.
So, when Microsoft released the most “full‐featured word processor ever for the Mac,” it crawled on their Macs—we're talking two minutes just to start it up.
The community immediately started posting in newsgroups that Microsoft was trying to “kill the Mac.” Hate mail started streaming in from everywhere, including e‐mails directly to Bill Gates, who would forward them to the team with messages like “This is depressing MSFT's stock price. Fix it.”
Enter Martina Lauchengco, a young product manager recently out of Stanford, whose job it was to help turn this around.
The team quickly learned that, while it may be a worthwhile objective to get to a common code base, it's an empty victory if the product that results is not good. Moreover, users choose their devices and platforms because they value what's different, not what's the same. From the customer's point of view, they would rather wait a little longer and have a better platform‐specific solution, than simultaneously ship a generic product on all platforms.
The team ended up focusing hard on performance and taking advantage of what the Mac could do. They looked at when and how to load fonts, since Mac users tended to have so many more than Windows users, and ensuring all Mac keyboard shortcuts still worked.
They focused on word count—which is used 10 times a day by every press person—to make sure that it was lightning fast, as the press used the feature as their performance barometer. They even made it faster than the feature on Windows.
The result was that in a couple of months they produced a 6.1 release that was sent to every registered user with an apology letter—signed by Martina—along with a discount coupon for future purchases.
This is a good example of how hard it can be to do the right thing for the customer, often in the face of massive pressures. But that's exactly what strong product managers figure out how to do.
The release succeeded in fixing the perception problems, but more important, it genuinely made the version dramatically better for the Macintosh. It was a product the Mac team could be proud of and what the team felt they should have delivered to market in the first place.
This is a good example of how hard it can be to do the right thing for the customer, often in the face of massive pressures. But that's exactly what strong product managers figure out how to do.
In subsequent years, not only did Microsoft once again decide to diverge the code base, they completely separated the teams into different buildings and business units and had them fully embrace all things Mac. Strategically, it was a complete 180.
It's hard to estimate how important this was to both Microsoft and Apple. Even today, more than 20 years later, many businesses and consumers consider Word and the rest of Office absolutely essential to using their Mac for business and personal use. What started then became a multibillion‐dollar win for both Apple and Microsoft. There are more than 1 billion Macs and PCs running Office around the world.
Martina has gone on to have a remarkable career in both product management and product marketing. From Microsoft she went on to Netscape, where she was responsible for marketing of the Netscape browser, and then Loudcloud. And now I'm happy to say she's been my partner at SVPG for more than a decade, and she also teaches marketing at University of California, Berkeley.
Let me also add that there are few things as powerful as a marketing person who's also strong at product. The combination is amazing.
Discovery Ideation Techniques
Overview
There are, of course, any number of techniques for generating product ideas. I really haven't met many ideation techniques I haven't liked. But to me, the more relevant question is, “How do we generate the types of ideas that are likely to truly help us solve the hard business problems that our leaders have asked us to focus on right now?”
Remarkably, in the vast majority of companies (not the ones that are good at product), the actual product teams don't do much ideation themselves. This is because what's really going on is that the ideas are already handed to the product teams in the form of prioritized features on product roadmaps, where most of the items on those roadmaps are coming either from requests from big customers (or prospective customers), or from company stakeholders or execs. Unfortunately, these are rarely the quality of ideas we're looking for.
In general, if the product team is given actual business problems to solve rather than solutions, and the product team does their job and interacts directly and frequently with actual users and customers, then getting a sufficient quantity and quality of product ideas is not really a problem.
How do we generate the types of ideas that are likely to truly help us solve the hard business problems that our leaders have asked us to focus on right now?
I have some favorite techniques that consistently deliver to the team very promising and very relevant product ideas.
One important caveat, though. If you use these techniques, I am fairly certain you will get very excited by many of the ideas you discover. But that doesn't mean you should just go ahead and build them. In most cases, we will still need to test them to ensure they are valuable and usable for our customers, are feasible for our engineers, and are viable for our business.
CHAPTER 41
Customer Interviews
The customer interview is the most basic technique I'll discuss in this book. I wish I didn't need to include it because I'd like to be able to take it for granted that product managers already know how to do this well and do it frequently.
However, the reality is that this is often not the case. Or, if customer interviews are happening, the product manager is not present, so the learnings are not understood viscerally or taken as seriously as they need to be (see Discovery Principle #10 on shared learning).
But no question, this is one of the most powerful and important skills for any product manager and very often the source or inspiration for many breakthrough product ideas. Later, when we discuss techniques for testing your product ideas qualitatively, these skills will be a prerequisite.
There are many forms of customer interviews, so this is not really a single technique. Some are informal and some are more formal. Some have a user research methodology behind them (one of my favorites is the contextual inquiry), and others are more about just getting out of the building and learning what you don't know.
This is one of the most powerful and important skills for any product manager and very often the source or inspiration for many breakthrough product ideas.
But 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?
Now there are lots of ways to get these answers, and if you have access to a user researcher, you would normally follow their lead. Here are some tips for getting the most out of these learning opportunities:
Frequency. 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.
Purpose. You are not trying to prove anything during these interviews, one way or the other. You're just
trying to understand and learn quickly. This mindset is critical and needs to be sincere.
Recruiting users and customers. I talk much more about this when we discuss the usability testing technique, but for now, be sure to talk primarily to people in your intended target market. You're looking for about an hour of their time.
Location. 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.
Preparation. Be clear beforehand what problem it is you think they have, and think about how you'll either confirm or contradict that.
Who should attend. My favorite is to bring three people to these interviews: the product manager, the product designer, and one of the engineers from the team (we normally rotate among those that want to attend). Usually, the designer drives (because they've usually been trained how to do this well), the product manager takes notes, and the developer observes.
Interview. Work to keep things natural and informal, ask open‐ended questions, and try to learn what they're doing today (not so much what they wish they were doing, although that's also interesting).
Afterward. Debrief with your colleagues to see if you've all heard the same things and had the same learnings. If you made any promises to the customer during that session, be sure you keep them.