Tower
Tower (source: Pixabay)

It is humbling to see how bad experts are at estimating the value of features (us included). Despite our best efforts and pruning of ideas, most fail to show value when evaluated in controlled experiments.

The literature is filled with reports that success rates of ideas in the software industry are below 50%. Our experience at Microsoft is no different: only about a third of ideas improve the metrics they were designed to improve.

—Ronny Kohavi, Partner Architect at Microsoft

Nature hath given man one tongue but two ears, that we may hear from others twice as much as we speak.

—Epictetus

Customers are what make a product successful.

Without customers willing to buy, it doesn’t matter how good or innovative or beautiful or reasonably priced a product is: it will fail.

It makes no sense, then, that we spend most of our time and effort optimizing our product development process. What about customer development? Shouldn’t we invest at least as much time in understanding our customers, their needs and pain points, and how to deliver solutions to them?

Customer development is an approach for doing just that.

It’s a way to reduce your business risks by challenging your assumptions about who your customers are, what they need, and why and how they buy.

By applying the scientific method to learning about your customers, you can help confirm that you’re on track to a business model that works and a product that people want to buy.

Sounds great in theory, right?

But theory is useless if you can’t put it into practice. That’s why I’ve written this book—because I’ve worked with, mentored, and spoken to hundreds of companies who love the lean ideas and principles but struggle to make them work.

The First Challenge Is Inside the Building

Customer development is a big change for most organizations.

To many people, customer development sounds like saying, “Hey! You know that expertise that we’ve amassed over decades of experience, dozens of products, and millions of customers? Let’s shelve it and start from scratch.”

Of course that’s not what we’re saying. But as a pragmatist, I recognize that it’s difficult to correct a mistaken first impression. If your team doesn’t understand what customer development is and how it enhances (rather than replaces) your competencies, it’ll be far more difficult to get started.

Customer development is admittedly the new kid on the block. Everyone knows about the role of product development, marketing, customer support, and even user research in an organization. But customer development? You’re likely to encounter some skepticism.

Unless your team has been exposed to lean startup conferences or Steve Blank’s work, you may find yourself having to sell customer development to your organization before you can really get started.

This chapter takes a step back, explaining what customer development is (and isn’t), why you need it, and who can do it. It also offers responses to some common objections.

What Is Customer Development?

So let’s back up a minute and talk about definitions. What is customer development? What does it replace? What does it not replace?

The term customer development is meant to parallel product development. While everyone has a product development methodology, almost no one has a customer development methodology. And the truth is, if you don’t learn what customers really want, you’re at a very high risk of building something that no one wants to buy.

Customer development is a hypothesis-driven approach to understanding:1

  • Who your customers are

  • What problems and needs they have

  • How they are currently behaving

  • Which solutions customers will give you money for (even if the product is not built or completed yet)

  • How to provide solutions in a way that works with how your customers decide, procure, buy, and use

You probably have ideas or intuitions about all of these. Let’s identify what those really are: guesses. Let’s make it sound a bit better and call them hypotheses. Those hypotheses may be around forming a new company, building a new product, or even adding new features or capabilities to an existing product.

Everything you do in customer development is centered around testing hypotheses.

What Is Lean Customer Development?

You may have heard of customer development. So what’s the difference between “customer development” and “lean customer development”?

I call my approach to customer development “lean customer development.” I’m using “lean” as a synonym for pragmatic, approachable, and fast.

Lean customer development takes the heart of Steve Blank’s ideas and renders them into a simple process that works for both startups and established companies. It’s what I write about on my blog, speak about at tech events, and teach when I mentor companies.

Lean customer development can be done by anyone who speaks with customers or prospects. It works whether you’re a startup founder with no product and no customers, or at an established company with numerous products and customers. Now that I’ve explained my perspective on lean customer development, from here on out, I’m going to talk simply about customer development.

In my experience across multiple companies and in mentoring startups, every hour spent on customer development has saved 5, 10, or even more hours of writing, coding, and design (Figure 1-1). That doesn’t even include the harder-to-measure costs such as opportunity cost, snowballing code complexity, and eroding team morale from working hard on features that no one ends up using.

Figure 1-1. Talking to customers saves time and money

Customer development starts with a shift in mind-set. Instead of assuming that your ideas and intuitions are correct and embarking on product development, you will be actively trying to poke holes in your ideas, to prove yourself wrong, and to invalidate your hypotheses.

Every hypothesis you invalidate through conversations with prospective customers prevents you from wasting time building a product no one will buy.

Lean customer development is done in five steps:

  • Forming a hypothesis

  • Finding potential customers to talk to

  • Asking the right questions

  • Making sense of the answers

  • Figuring out what to build to keep learning

If your hypothesis is wrong or even partially wrong, you want to find out fast. If you can’t find customers, you modify your hypothesis. If customers contradict your assumptions, you modify your hypothesis. Those course corrections will lead to validating an idea that you know customers want and are willing to pay for.

What Customer Development Is Not

There are as many misunderstandings about what customer development isn’t as about what it is. Let’s clear those decks right now.

Customer Development Is Not Just for Startups

When The Lean Startup was published in 2009, many companies were slow to embrace the ideas it introduced. “We’re not a startup,” they replied.

Although Eric Ries uses the word “startup” in the title of his book and Steve Blank wrote specifically about customer development as it pertains to startups, startups are not the only companies that benefit from customer development. Startups certainly have a higher degree of uncertainty than mature companies; they are still searching for a business model, a distribution strategy, a customer base.

But larger, more mature companies also can’t assume that their models will remain static. Markets and technology change. In addition, larger companies often find it difficult to shift attention and resources away from profitable lines of business in order to explore new markets and areas of innovation—leaving them ripe for disruption. (Kodak, which I write about in not available, enjoyed over 100 years of success before missing the boat on digital imaging and declaring bankruptcy in 2012.)

Customer development, with its focus on small-batch learning and validation, can promote internal innovation. Intuit, for example, has launched multiple products using customer development—including SnapTax and Fasal. General Electric is using lean principles. So is Toyota, the New York Department of Education, and the White House’s Presidential Innovation Fellows program.

Much of the content in this book is applicable for readers from early-stage startups, massive established companies, and anything in between. When a section is more useful for one audience than the other, I have called that out.

Customer Development Is Not Product Development

Product development answers the question “When (and what) can they buy?”

Customer development answers the question “Will they buy it?”

Product development is the process of building a new product or service and (one hopes) bringing it to market. Start with a concept, define the requirements, build the requirements, test the near-finished product, refine it, and launch it.

How you develop a product varies tremendously based on the methodology your organization follows (e.g., Waterfall, Agile, Scrum, etc.). What all product development methodologies have in common is the desired outcome: a completed product for customers to buy.

But what if the product you build is not a product that customers will buy? Is “product” the biggest risk your team faces? What about market risk? As Marc Andressen said, “Market matters most. And neither a stellar team nor a fantastic product will redeem a bad market.”2

With customer development, you are building your customer base while you’re building a product or service that solves their specific problems. Customer development doesn’t replace product development; it’s a second process that you do in parallel with product development.

If you’ve done customer development alongside product development, you don’t need to wait until your product is launched to know whether customers will buy. You’ll know, because you will already have beta customers, evangelists, and paying customers.

Customer development and product development are two independent activities, and both are necessary to maximize your company’s chances for success.

Customer Development Does Not Replace Product Management

Some folks object, “Well, what’s left for product managers to do?”

Customer development does not replace product vision. Talking to your customers does not mean asking them what they want and writing it all down. Product management requires a disciplined approach to gathering information from a variety of sources, deciding which pieces to act upon, and figuring out how to prioritize them.

Customer development simply adds two components: a commitment to stating and challenging your hypotheses and a commitment to learning deeply about your customers’ problems and needs.

Customer development does not provide all the answers. Although it can replace many of your assumptions with actual information, it still requires a disciplined product manager to decide which pieces of information to act upon, how to prioritize them, and how to take what you’ve learned and turn it into a feature, product, or company.

Customer Development Is Not User Research

Your company may be conducting user research already. That doesn’t mean you’re practicing customer development.

Customer development does borrow from many of the techniques that have served user researchers well for decades. But the context, the practitioners, and the timing are very different.

User researchers often describe their work as “advocating for the user.” It is, unfortunately, still viewed in many companies as optional, something you should do because it delights customers.

Customer development is “advocating for the business.” It’s not something that you should do because it makes customers happy. It’s something you must do to build a sustainable business where people open their wallets and pay for your product or service.

Most new products (and companies) fail. The odds are against you. Around 75% of venture-backed startups fail.3 Anywhere from 40% to 90% of new products fail to gain significant market adoption.4

But surely, we think, we will be the exception. We like to think of building products as an art—something guided by our creativity, intuition, and intellect. We all know that there are good product managers (and designers and engineers and strategists) and mediocre ones. Maybe that’s what makes the difference between a failed product and a success?

Unfortunately not.

Universally, we’re just not very good at building products and companies solely based on creativity, intuition, and intellect. It’s not just a startup problem, either: in 1937, the companies that made up the S&P 500 had an average life expectancy of 75 years; recently that number has dropped to just 15 years.5

On a smaller scale, we’re not as good as we think we are, either. Most of our ideas don’t increase value for customers or companies—Microsoft estimates that only around one-third of their ideas improve the metrics they are intended to improve. Amazon tests every feature and fewer than 50% work; Yammer’s numbers are roughly the same. Netflix and Intuit don’t claim any higher proportion of successes.6

The truth is that it doesn’t matter how much companies research, how well they plan, how much money they spend, or how smart their employees are: the odds that they’ll avoid big mistakes are worse than a flip of a coin.

How Do We Improve Our Odds?

In part, we improve our odds by embracing the idea that building products is a systematic, repeatable process. There are tools that you can use, regardless of your company’s size, maturity, or industry, to help increase your chances of success. Customer development is one of those tools.

By practicing customer development as a parallel process in conjunction with product development, you can greatly maximize your learning and reduce your risks.

If you’ve read The Lean Startup, you’ll recognize the diagram on the left side of Figure 1-2 as the Build-Measure-Learn feedback loop. It’s meant to describe how your organization should be continuously learning and adapting based on the new information you get from measuring results and learning from customers. The diagram on the right side, the Think-Make-Check loop, is a variation coined by LUXr CEO Janice Fraser.

Figure 1-2. The Build-Measure-Learn feedback loop Ries described in The Lean Startup (left) and the Think-Make-Check cycle that Janice Fraser describes in her thinking on lean UX (right)

What’s the difference? Just the starting point. You don’t need to start with the Build phase—in fact, doing so is often an expensive way to experiment.

Customer development is an important part of the Think phase. It allows you to explore and iterate during the cheapest phase of development—before any code is written or mockups are created. Customer development gives you the necessary information to build the best possible first guess, which you will then validate.

I’ve talked about learning more and reducing risk—those are valuable gains, but they don’t feel very tangible. What else will you gain from practicing customer development?

  • You’ll get a richer picture of your customer and your competition (not just companies and products but established habits and routines)

  • You’ll uncover new opportunities for differentiation

  • You’ll reduce the amount of product you need to build

Yes, that’s right: you’ll almost certainly end up writing less code! This is a consistent benefit I’ve heard from development teams: the ability to make their minimum viable product (MVP) even smaller. By talking to customers, you’ll frequently find that customers really want only two of the five features you think you need (and they may want one more you hadn’t thought of).

In 2009, I was lucky enough to join a startup called KISSmetrics, which had Eric Ries as an advisor. KISSmetrics had previously built two unsuccessful versions of a web analytics product. For both versions, the company had spent many months in development, only to launch and realize that their product wasn’t solving a problem that customers needed to solve.

KISSmetrics CEO Hiten Shah hired me to help them build the third version of their product in accordance with lean startup principles. This time, they wanted to build a version that would allow the team to get the maximum amount of validated learning about customers with the least amount of effort. My first task: figure out what should be in that MVP.

I spent the first month of that job on the phone, on IM, and drinking coffee with people. I was shocked to find that:

  • So many people were willing to talk to a total stranger who didn’t even have a product

  • The features that most people requested were far more ambitious than their current behaviors and tool usage

  • We’d be able to cut our product scope in half for our initial beta

The third version of KISSmetrics was built in a month.8 It was missing tons of features and included a lot of code that made our CTO cringe. But it was enough to provide value to customers and enough for us to glean valuable insights that shaped the future direction of the product.

Answering Common Objections

I’ll assume that you’re convinced of the value of customer development having read this far. But how can you respond to people who are not so convinced? Table 1-1 offers tactics for responding to common objections.

Table 1-1. Responding to common objections
Objection to customer development Your response

If we talk about our future product ideas, what’s to stop someone from stealing them and launching them before we do?

First of all, we’re not telling people our product idea. That would bias what we hear from them. We’re talking to people who have a problem we hope we can solve. We’re talking to them about their problem, and how they’ve tried to solve it so far.

What if they figure out what our idea is and then steal it?

It’s extremely unlikely that anyone we talk to is in a position to act upon our ideas.

But even if someone was, a great idea is nothing without great execution. By talking to customers and understanding their needs and what makes them buy, we’ll be more likely to release a superior product.

What if we get bad press coverage because of this?

For startups:

We’re not at a place yet where anyone wants to give us press coverage of any kind.

For enterprise:

We’re talking to an extremely small sample size, and we will set expectations appropriately. If it makes you feel more comfortable, we can ask prospective customers to sign nondisclosure agreements (NDAs). But this hasn’t been a problem for GE, Intuit, or Microsoft...so it’s unlikely to be a problem for us.

How will we find people to talk to? We don’t have a product or customers yet.

We’ll have to figure this out once we have a product, won’t we? Come on, we know we’re solving a specific problem for a specific kind of person—we just need to figure out where those people are online or in the real world. (See not available.)

What if this damages our relationships with existing customers?

Customer development is actually an opportunity to build stronger relationships with some of our customers. We’ll choose those most likely to be receptive, and we’ll set expectations appropriately. (See not available.)

If we do customer development, what’s left for the product manager to do?

Customer development doesn’t mean asking customers what they want and building exactly that!

It’s a process for gathering information, and it will require a skilled product manager to prioritize that information and figure out what and how we respond to it. Customer development is just another tool to help our product managers do their jobs more effectively.

We already do market research and usability testing. How is this different?

Customer development gives us information on how individual customers behave and buy.

We don’t get that from market research—it’s more high-level, covering aggregate populations. We don’t get that from usability testing—that just tells us whether someone can use our product, not whether they would buy it. Market research and usability testing may still be valuable, but they serve different purposes from customer development.

Customer development is the best low-effort way to confirm our assumptions about who our customer is, what he needs, and what he’ll buy.

How can we justify taking time away from building our product?

If a few hours of customer development helps us discover that even one of our assumptions is flawed, that’s likely to save us weeks of coding and design time.

Plus, doing customer development doesn’t mean we can’t make progress on the product. We can—and should—do both in parallel.

Shouldn’t we let product managers, engineers, and designers focus on what they’re good at: building the product?

If the team wants our product to be successful, they should understand the problem the product is trying to solve!

But I understand that not everyone wants to spend all day talking to customers. We can involve folks in a very lightweight way so that they have a half-hour or an hour’s exposure to customers without killing their productivity.

Let’s Make This Work

In the next nine chapters, I’ll show you exactly how to do customer development. I’ll cover specific exercises, tools and templates, sample questions, and methods that you can immediately put into practice. I’ll also provide some necessary background in behavioral economics and social psychology research—not because I love theory, but because understanding why a technique works will help you adapt it to suit your needs and the needs of your organization.

You don’t need experience in market research or user research or even in talking to customers at all—all you need is an open mind and a willingness to challenge your ideas to make them stronger.

Next Step: Get Started

As I mentioned at the beginning of this chapter, everything you do in customer development is centered around testing hypotheses. Now it’s time to start forming those hypotheses. In not available, you’ll jump into exercises that help you identify your assumptions, the problem you’re solving, and who your customer is.

1If you’ve read Steve Blank’s The Four Steps to the Epiphany, you’ll recognize that this is not his original definition of customer development. Blank defined the four steps as customer discovery, customer validation, customer creation, and company building.

But The Four Steps was written explicitly for startups, and Blank is very clear that “a startup is not a small version of a big company.” Having worked for over a decade in startups and now being a part of Microsoft, I completely agree. They are very different beasts!

Since customer development works for both startups and larger enterprise companies, I’ve proposed a broader definition that works for companies of any size, at any stage of maturity.

2http://web.archive.org/web/20070701074943/, http://blog.pmarca.com/2007/06/the-pmarca-gu-2.html

3You’ll hear varying numbers. The National Venture Capital Association, for instance, estimates that only 25% to 30% of venture-backed startups fail completely. But the discrepancy may be due to different definitions of failure. Harvard Business School senior lecturer Shikhar Ghosh estimates that 30% to 40% of high-potential startups end up liquidating all assets—a failure by any definition. But if a startup failure is defined as not delivering the projected return on investment, then 95% of VC companies are failures, Ghosh said (http://www.inc.com/john-mcdermott/report-3-out-of-4-venture-backed-start-ups-fail.html).

4The number varies across product categories. Highly innovative products fare even worse. For more information, see http://www.cob.unt.edu/slides/paswan/MKTG4320/freepdfgrab.pdf.

5“What went wrong? [startup guru John Hagel III] argued that American companies and their leaders were essentially not prepared for a move away from a corporate model of ‘knowledge stocks’—developing a proprietary product breakthrough and then defending that innovative advantage against rival companies for as long as possible—and toward a more open and collaborative business model that he called ‘knowledge flows.’ The problem, he said, is that because of the increasingly global nature of business competition, the value of a major proprietary breakthrough or invention erodes in value much more quickly than in the mid-20th century” (http://knowledge.wharton.upenn.edu/article.cfm?articleid=2523).

6Numbers from a Microsoft ThinkWeek paper (http://ai.stanford.edu/~ronnyk/ExPThinkWeek2009Public.pdf).

7http://en.wikipedia.org/wiki/Confirmation_bias

8KISSmetrics CEO Hiten Shah talked about the failed first two versions of KISSmetrics at the first Startup Lessons Learned conference (now called The Lean Startup conference): http://www.slideshare.net/hnshah/kissmetrics-case-study-about-pivots.

Article image: Tower (source: Pixabay).