Building Products Your Customers Will Buy

Lean Customer Development

Building Products Your Customers Will Buy

With bestselling author, Cindy Alvarez, Director of Customer Research, GitHub.


  • Think of customer development as building your buying audience as you are building your product.
  • Find the problems your customers are impassioned about solving.
  • Use silence to draw out the answers you really need to hear.

Setting the scene:

Lean customer development is a topic that people may think relevant only to early stage startups, but in our opinion the imperative of customer development – building products your customers will actually buy – never stops, whether this is at the startup, grow up or scale up stage. Cindy Alvarez is one of the world’s leading thinkers and practitioners on this topic. She is the Director of Customer Research at GitHub and was previously a Principal Group Product Manager at Microsoft, where she embedded customer development practices across the organisation. She is also the bestselling author of Lean Customer: Building Products Your Customers Will Buy.

What is lean customer development and why does it matter?

Lean customer development is making sure that you're going to have customers by the time you've built something, which is a little bit foreign to many folks, who’d typically build a product and then try to find people to buy it.

The feeling of many founders and product managers is that you have to show something to someone to engage their time and that what people say that they want, is not actually what they'll end up buying. But everyone out there, every potential customer, has problems they need to solve and if you can figure out early what those problems are, you can actually co-develop a product with your customer base. So you should think of customer development as literally building your customer audience as you are building your product.

The first challenge for customer development is inside the building.

For early stage founders, a lot of their role is selling the vision. The phrase “reality distortion field” is very real in our industry, making people believe that this thing that doesn't exist, is going to exist. It's very easy for us to be convinced of our own brilliance - that's just a human trait - and to be in selling mode, where we're going out and saying, “don't you want this? Wouldn't you like this?” Iif you're pretty charismatic, you can get most people to agree that “yes, I do have that problem.” But when you're not in the room, standing there eagerly, and they're standing there with their credit card making a decision, they're not going to decide the way that you think.

Founders and product developers want to spend their time on ideas and creation and it feels like a step backwards to stop doing that, to take a pause and say, “let's go ask open-ended questions of some people and it might feel like a distraction!” Because honestly, if you're very excited about an idea, and you go talk to three people and one of them is eager, and the other two are like, "I don't know, I'm not really sure," it's demoralising and you lose a day of work thinking, "Huh, I don't know, if we should build this. We had a vision, but now we're not sure if it's right," and that feels like you're wasting time.

Especially in the startup phase, where everyone knows their burn rate, you've got this amount of money, you want to get something out the door, it's very easy to think "let's focus on building and we can talk to customers later." But that’s a big mistake.

The two most common mistakes companies make when they're thinking about implementing a customer development strategy...

One of the most common mistakes is thinking you can outsource customer development. So people will say “let's hire a researcher to do a bunch of interviews, that way we can focus on the real work!”. That mindset of thinking is basically saying “talking to customers is not real work.” v

The other is to dismiss whatever the researcher finds. This is human nature. If someone comes to you and says, "I did those interviews and people don't want what you're selling," our instinctive, defensive response is to say "you probably talked to the wrong people,” or “you obviously didn't explain it right."  

As a founder, you're not going to be able to do every single interview, but it's really important to hear the interviews where someone is not excited. Now that doesn't mean that they're necessarily saying "wow your idea stinks!" But someone who's kind of giving you, "Oh, yes, maybe" answers because that's someone who's honestly putting a polite face on it but you can see that they just don't get it but the problem is not them. The problem is that you have not yet found the problem that they're passionate about solving.

The critical steps of the customer development process.

What you really need is a testable hypothesis.

But in the very beginning, we're starting from zero, which might be, “I have this vague sense that there's a population with a problem,” or “I’m pretty confident there's a problem that needs to be fixed,” such as if you're seeing busy parents who seem stressed out about something, if you're seeing a situation where there's an inefficiency in a market or a location where traffic is constantly piled up or trash that isn't getting taken out. Any of those things could be problems worth solving.

You might want to do some simple observation in the beginning, or some exploratory interviews, where you're really just saying, “tell me about this problem." And a lot of times, for folks who are in specific domains, you're going to get that naturally from being at conferences, or being in professional societies, or talking to friends. So that's step zero.

Then you want to get to step one, which is the hypothesis, something you can prove yes or no. That's going to look like a statement that's got a person and a problem and a situation in which those should be testable. So, for example, you might say something like, "I've noticed that whenever I call my barber, I have to call and call and call, and it takes forever to get through and make an appointment. Every time I go in, it seems like this person is very ambitious and they want to grow their business. So I'm wondering how they can possibly get customers when they are so busy and can't even pick up the phone?"

One solution may be that they hire a receptionist, but you think to yourself, "surely all these small businesses can't hire someone to answer the phones, what could we do about this?" And so you might get to, "I have a hypothesis that business owners with fewer than 10 employees have a problem with wanting to grow their businesses, but being too busy with the day-to-day to do xyz." So this is the hypothesis, here's a set of customers with a pain point, which is that they can't invest in growing their business. But they're ambitious, they have a vision that they're not able to achieve and you go out and find people who fall into that category.

Now you've got your hypothesis and your target customers so you're going to validate, which may be talking to say five small business owners that fall into that category. You'd ask them fairly open ended questions about "how do you run your business?” or, “what frustrates you the most?” Or maybe, “What do you wish you could do that you can't?" A lot of people worry about the exact questions in the early stage. Almost every interview that I support, or that I do myself has the same exact questions.

  1. Tell me about how you do this.
  2. What frustrates you the most?
  3. What takes you the most time?
  4. What do you wish you could be doing?
  5. If you could wave a magic wand and make anything about running your business easier? What would it be?

You do those five interviews and you'll see some patterns. Or maybe you'll see the complete absence of a pattern, which suggests maybe it's not that big a problem. But five gives you enough to kind of take stock in what you've heard and think more about, "do I feel more confident about this hypothesis or less?" and depending on the direction, you either rejig your hypothesis, or you say "let's talk to more of these people." And maybe now that I've had five conversations, I've got a sense of some specific questions that I really want to dig in on for my next five or so interviews. And you just repeat that process.

The mechanics of it are very simple. sticking to it is what's actually a lot more difficult. And I find my team's role at GitHub often is not in doing the interviews but in trying to make that process as simple as I just explained it, so ensuring that all the customer interviews are done correctly and the insights are captured, categorised and synthesized.

Like any project management role, it is about the basics - you need to follow the checklist.

How you conduct successful customer interviews, because that's at the heart of it really, isn't it?

The first thing I like to tell people is to think about what you want to learn. That's not the same as spending a lot of time on writing questions. But I find there's kind of a funny thing where, when people want to learn something, they tend to jump to these oddly formalised ways of asking questions  The same way as whenever you read a statement from a company it sounds like lawyers have been hard at it, so people ask these very convoluted questions and I say, "Well, what do you actually want to know?" Examples could be:

  • I want to know from this small business owner, what's frustrating them?
  • I want to know if they've got things written down on paper. If they've got wall calendars, if they're using their phone.
  • I want to know when things run very smoothly?
  • When do things fall apart?
  • What makes them really excited?
  • What makes them proud?
  • How do they make decisions?
  • Who are they listening to when they want advice?
  • What's top of mind for them?"

So another thing that I think frustrates founders immensely is that a lot of your customers have problems that are very valid, but they don't really care. They're just dealing with it, they're walking around the squeaky step every single day and they're fine with it.

That's not going to be someone who's ready to invest in a solution yet, they may in the future, so you think about what you're going to ask and prepare a little opening statement. A lot of folks believe that "a customer's not going to want to talk to me, if I don't have something to sell them," but I've never actually found that to be true. It really helps to have a canned one or two sentences at the beginning to establish that you feel confident.

Begin with something such as, "Hi, Stephen, I'm really in an exploratory phase where I'm trying to learn more about the needs of small business owners, so I'm just going to have an open ended conversation, I'm going to try and listen more than I talk. And trust me, nothing you say will be boring. So please dig into the details. Before we begin, do you have any questions for me?"

I could wake up in the morning and say that in a flash and it doesn’t matter what the interview topic is. I tell people if you try to memorise your questions, you won't come across as human and people won't actually be honest with you. But if you stammer over that first couple of sentences, you will feel worse, and so will the other person. So start with that memorised a bit and then you dive into your first question, which is, "tell me a little bit about how you're doing this thing today." And I always like to abstract up a level. So if you want to know about someone's tooth brushing routine, don't ask about their tooth brushing, but how they get ready in the morning, or how they take care of their health in general, because that's the more abstracted question. And then when they ask that first question, be quiet for what seems like an uncomfortably long period of time. I say in the book a minute, that's actually almost certainly too long. But the point is that it should feel awkward, you should feel to the point where you think I've got to say something difficult.

So people feel awkward and they fill the silence with content. What typically happens is you think about when you see someone that you vaguely know, on the street, or online these days, and you say "How are you?" And they say "fine," and you just keep going because you are on your way to a meeting. You don’t actually want a deep dive but a lot of questions are asked with that sort of perfunctory politeness. So you ask someone about how their business is going. And they say, "great." But that's not what you want to hear. I mean, hopefully, their business is going well, but you want to hear the details of how so you ask that question. You pause for that uncomfortable period of time. They'll say "things are going great”, and after a few seconds, they'll say, "you know, I have everything written down on paper, I've got everything in my book, I don't need to worry about anything, as long as I don't lose that paper." And then you might have said, "Well, hang on, has that ever happened? Have you lost that book?" and that’s when you get the breakthrough, "Well, actually, it did happen about a year ago, I lost a bunch of appointments and it took me weeks to catch up." That's a very interesting point.

That's why you need to use silence. You don't want to go on mute. This feels like such a nitpick but if you put yourself on mute while you're doing a customer interview, people will think you’ve disconnected and that's disconcerting. So I try to make these very non-committal noises or breathing noises, so people know you're still there. If you're in person, even if I'm recording, I like to take notes, on paper or even on a laptop. I think at this point, most people consider that polite, even though it's a bit weird, because then you can be looking down and taking notes and making that little gesture like, "Oh, just let me get this down”, and in that silence, they will still continue talking.

Turning interviews into insights can be tough, especially at first.

It's very important to explain to people that there's a period of time in which this customer development process will seem like a really stressful mess and that you're not getting anything out of it.  You do this interview, they're almost always very pleasant, you come away feeling very energised, you've done a few of them. Then you've got a bunch of notes, you're thinking, "Wait, are we learning anything, these feel all over the map like I don't, it doesn't make any sense?" I have found that this is extremely common. So there's this period where you're struggling in the void. Suddenly, you start noticing little common patterns, such as, "you know what this person said about the times that they feel stressed, it sounded similar to our second interview. And actually, if you think about it, one of the things they have in common is they're both working across time zones. If you think about that, this other person was also complaining about the struggles of working with their co-workers across the world." Now you’re seeing a pattern.

I've really not found a better way than rehashing your interview notes on sticky notes, whether physical ones or virtual ones like Mural or Miro. You get these stickies and you kind of rearrange them in your physical or virtual mode, and you'll see a bunch of stickies clustered in this area - that's really interesting. It's helpful to have another head to bounce this off, so hopefully, you've got someone on your team or another startup founder, who is also willing to do this with you and say, "I noticed that there's a lot of commentary around this, it seems like the problem might be here, what do we know about how able they are to change or what their skill set is today?". It’s the ideation of anything else in product development, you throw things around and talk about them until something starts to emerge.

I think the main thing that I would say is, "when you get that thing that starts to emerge, you're going to want to test it out as quickly as possible." So what often happens is you've done exploratory interviews, and at some point, they turn to sort of a hybrid, where the first part of your conversation is exploratory and I always like to start with that. Then you take a break and say, "Hey, thank you so much for talking to me about this but I am curious if we could talk through a concept?" And you might say, "I was wondering if, magically, something like this were to appear? How would that fit into the process you have today?" Not, "would you buy it? Not would you use it?" But rather, "how would that fit In?" Or, “What reasons might there be working or not working?” Because at that very high level, when it doesn't sound like "my heart is on my sleeve, look at this amazing thing I've built," people are willing to be honest and say, “I don't think that would work.” Or, “Oh, I can't imagine using something like that.” And then you can politely dig in, “Oh, I'm curious, why is that?” That's where you get a lot of the gold. So you come up with this idea of, "hey, maybe this solution would work." You float it very casually, you get a reaction of some kind, and you try and dig in, "why that reaction? What about that solution is not sitting right with you?" And that's really where you get those ideas honed, and more importantly, you get them honed before you become really attached to them.

Get your customers to open up with open ended questions.

People won't tell you what they're going to buy, they also will not tell you what they're going to use as they can't really predict what they're going to do next year. That is just human nature. A lot of times what we want to do is ask not a yes or no question, but something that starts with the how or what or who. It actually goes so far as to say you should never ask a yes, no question. And if you start to ask one, because that is what you will want to do. It's okay to pause and reframe it midstream. In an interview, if you say, you know, "Do you find it hard to? Excuse me? Let me reframe that. When do you find it difficult to do X and Y?”

Asking open questions will give you a better and broader answer. My favorite one in the developer space is asking people, "do you always test your code?" And there's no engineer out there who wants to honestly say "no, we don't always test our code.” But the reality is that for most companies, there will be times when you don't. There'll be an emergency, there's a deadline, there's a terrible bug that you need to roll back. There's always some reason. So if you're the person trying to build solutions for this, what you really want to find out is what is that reason that causes people to do this thing they don't want to do, that they’re incredibly stressed about, because if you can figure out when it's happening, then I can architect a solution.

If you say something like, "tell me in the last six months, about a time when you were just unable to test some code that you were putting into production." Now you've signaled that it's actually Okay, it's socially acceptable to say, well, there was that one time you still left the door open for I'm going to say actually, we're really proud of this. We've tested 100% of our code in the last six months, great. But for everyone else, they can say, "well, there was this time," and you can pull out one of those elements of creating the situation. So open ended questions all the way; it's incredibly hard but people will be very forgiving of you stopping midstream and redirecting your yes, no questions into one that allows for that storytelling.

Applying the concept of customer development to later stage companies

Customer development is if anything more important as you get to the later stage, because the stakes are higher. Not only are you potentially building the wrong thing, but you're losing goodwill with your customers who are out there in the world, talking to other customers, potentially complaining. If you upset a customer, there's an incredible amount of work that goes into support tickets and reassuring people and reestablishing trusted sales relationships. So there's a lot on the line. You want to use a similar method, what's going to be different is that you have to think about, first of all, who you're talking to.

Among enterprise customers, there are always going to be a few with whom you can't float exploratory ideas, because you just will never set that expectation that it is exploratory, and you run the risk of seriously setting back relationships. People who work in your field teams probably know who those customers are, so don't talk to them. Pick the folks with whom you can have a hypothetical conversation, where you can set the expectation, “we'd love to talk about some exploratory ideas, adjacent to the way you're using our solutions today, because we're thinking about how we can expand and better serve you.” Then you do the same thing as before you say, “tell us about how you're doing this today.” A lot of times, there's a sensitivity there because you feel rightfully like you ought to know this. So if you've been working for the customer for two years, it feels silly to go in and say "so how are you using our product?" Because, well that's your job! This is where I find it's incredibly helpful to bring in someone from another team to reinforce that not everyone has that baseline understanding. If you are the person who is an account manager for a team, you're probably not going to want to be the person who goes in saying, “tell us how you're using our product, or tell us what's working and not working,” you're going to want to borrow someone from the product team or from a research team or a design team or some adjacent team where there is a reason for them to not know.

GitHub puts customer development into action at scale

Within GitHub, customer development happens naturally, in the flow of things. Everyone is trained to ask ‘why’ questions and open-ended questions. We practice this a lot. Once a month, there's a day set aside for people to learn anything they want. I think just on all of those days, someone on my team is doing a talk or a workshop so that we can practice the skills we are discussing, for example “okay, so a customer comes to you and says, I want this feature, how are you going to respond” and practicing saying things like, "Oh, that's really interesting. You know, I'd love to hear more about that." Or, “you're right. We don't support that today. I'm curious if we did support that, what would it allow you to do?” Or, “I'd love to understand more about why you're asking.” Instead of saying yes or no, both of which eliminate avenues for further conversation, practicing asking “why.”

One thing that a lot of us have heard, and I think everyone who's been to business school, is the rule of five whys, the idea of asking ‘why’ five times to get to the root cause. But if you ever tried doing that, it sounds incredibly rude, especially if you have a customer who says I want this feature, and you say why five times, they're probably going to think you're being a bit of a jerk. We practice padding it, so for example saying, "interesting, I would love to know more." Eventually, you're going to get a why in there, but that padding becomes important. That practice allows product managers to throw in open-ended questions and a solutions engineer to ask good questions and so on. We practice and encourage that across the company and give people a lot of avenues for sharing that back, whether that's in the company Slack, or we've got a repository that's dedicated to customer insights, so that we can cross pollinate that information.

Microsoft, Netflix and Airbnb are tech giants that do customer development really well.

Microsoft has not been known for this historically, but there are several divisions who have really strongly embraced this concept. Airbnb, Netflix are also companies that have a good way of asking contextual questions, and really thinking about how we can gather the learning as we go, because that's the other thing that makes people hesitate about customer development, they think of it as this long process they're going to have to invest in. I would say the only times that I've been in and seen people invest in full time, customer development is at the very beginning of a startup process. Or if you are a large enough enterprise company, that you have the luxury of carving off some people and sending them off to do a white space exploration for a number of weeks, and almost everything in between, you just are never going to have that luxury of time. And so most customer development is a little bit every week and accumulates over time.

Once it becomes second nature, it doesn't feel like this additional tax. It's just something you're doing.

Fve things to bear in mind:

  1. Don’t outsource customer development, instill it into your businesses
  2. Don’t over complicate things, ask simple questions
  3. Make sure your questions are open-ended
  4. Implement a process to capture and synthesize your findings
  5. Instill customer development into your company culture as you grow

If people want to learn more they can find me on Linkedin, Twitter or on my website below.

And of course look out for my book, Lean Customer: Building Products Your Customers Will Buy.

I also highly recommend O'Reilly Safari Learning Library which has some excellent video classes from me and from other people praising the customer development mantra. One thing that's kind of a side topic that I always recommend, as well is learning about cognitive biases, which is also a course that I sometimes teach on O'Reilly.

you also may like to read
No items found.
you also may like to read

Get the latest from Notion Capital. Sign up to our newsletter.