 Hey friends, and thank you for tuning in. My name is Christopher Gill, and I am a product manager at Microsoft working on developer tools. Today, you'll learn how to get started with customer development, what it is, why you need it, and strategies you can use. So let's dive in. What is customer development? If you read enough books or articles, you'll likely find multiple definitions and philosophies for customer development. Steve Blank popularized the term for startups, and Cindy Alvarez adopted it to apply to companies of any size and at any stage of maturity. However, my favorite definition for customer development is one that I heard from Travis Loudermilk, a well-regarded UX researcher at my division at Microsoft. I like it because it's simple and easy to remember. Customer development is any work that helps inform your team about your customers, their identity, hopes, goals, dreams, pain, and even ideal solutions. This is a learning-based parallel to product development, which is any work we do to respond to what we've learned about our customers and usually means building something. Now, technically, an organization can build a product without customer development, but customer-driven organizations seek to constantly learn more about the customer before, during, and after building a product or feature. Now, to make that definition more concrete, let me give a few examples of what makes up customer development. It includes market research, surveys, product analytics, and more. But in my opinion, the most powerful tool is talking to customers, a wild idea. Customer interviews are cheap, fast, and can be done at any company, for any product at any stage and maturity. You can and absolutely should do it before you even have a product. Interviews are also rich in why. The fact is that product analytics and telemetry cannot give you the full picture. They can tell you what is happening or has happened, like that a user engagement has dropped 10% in the last month, but they usually can't tell you why it dropped, which you'll want to know to be able to fix it. For those reasons, I'll be focusing on customer development as a driver, or I'll be focusing on customer interviews as a driver for customer development today. In her book, Lean Customer Development, Cindy Alvarez says, every hour spent on customer development saves five, 10, or even more hours of writing, coding, and design. So why do you need it? Well, the fact is, if you're building a new product or even a new feature for an existing product, the odds are probably stacked against you. According to Harvard professor Clayton Christensen, 95% of new products introduced every year fail. According to Harvard professor, Shikhar Ghosh, 75% of VC backed businesses fail. Microsoft estimates that only one third of implemented ideas improve their intended metrics. People are just almost universally bad at guessing what their customers want based on sheer intelligence and creativity. Rigorous customer development can help shift those odds in your favor. Additionally, the world, especially the tech world change so fast. The long-term success of any business depends on both key business metrics and customer learning. Customers and their context change and that's why a product manager's work is never really done. Customers largely loved Windows 7, but what do you think would happen if Microsoft had just stopped there and not continued iterating or learning? You can iterate on a product without talking to customers. You can build a feature, watch your metrics and keep trying until you get it right, but that can be expensive and slow. Today, organizations that can't move quickly are at significant risk of being disrupted. So how does customer development work? I like to think of it in four steps. First, formulate hypotheses. I recommend a hypothesis-driven approach because it keeps your team humble and curious. Question the assumptions your business depends on and test them like a scientist. Next, find customers to talk to. You can talk to your current customers or potential customers if you don't have a product yet. In the modern hyper-connected world, you have so many avenues for finding people. Next, talk to customers. That sounds obvious given the previous step, but there are non-obvious techniques and strategies you can use to get the most value out of your conversations with customers. Lastly, make sense of the answers. Convert what you heard from customers into learnings that drive real change to your product or organization. Your customer development efforts are only as valuable as your ability to turn them into concrete outcomes. The first step to formulating your hypotheses is to get your assumptions out in the open. If your team is completely new to customer development, it's a great idea to get everyone together for an assumption brainstorming exercise. I recommend grabbing a whiteboard and some sticky notes or using an online collaborative tool like Microsoft Whiteboard. Put 10 minutes on a timer and let everyone go wild, let everyone work independently during that time, you'll be able to discuss afterwards. You can use some of the prompts below to get your ideas going for things to put on the sticky notes. One, who are your customers? Think of their job title, experience, industry, age, interests, this will help you identify and differentiate types of customers. For example, small and medium businesses may have very different needs than large enterprises. What goals do these customers want to achieve? This is a really foundational question. Even the most amazing product won't succeed if it's not helping a customer achieve their goals, their actual intended outcome. What tools or processes are these customers using to achieve their goals? Are these tools working for them? Are they using your product or competitors? Why? What problems or constraints make it harder to achieve these goals? You really need to understand the problem well before you dive into the solutions. How much will customers invest to solve this problem? This addresses the fundamental concern of will a customer actually buy this? You can be pretty confident before you build it. What features might help solve our customers' problems? Just get all your creative ideas out into the open. Now, after the 10 minutes is up, take time to group similar sticky notes. One approach is to organize them by customer, problem, solution, and then discuss. What ideas showed up over and over? What ideas are conflicting? This is a good opportunity to get your team on the same page or find areas that you really need to validate because everyone has different ideas. Next, you wanna convert your assumptions into hypotheses. One template you can use for a problem hypothesis is we believe customer type experience problem when doing type of task, or experience problem because of limit slash constraint. You don't have to follow the template exactly. It's mostly there to encourage you to think about who the target customer is, what task or goal they're trying to accomplish, and what problems might be getting in their way. All of these are very helpful contexts to have put together. The we believe phrasing is meant to reinforce that this is a hypothesis, not a fact. Here are a few examples. We believe personal Gmail users experienced missed important emails because they get lost among many less important promotional emails. This might have been the problem hypothesis behind Gmail's smart separation of primary inbox from updates and promotions. We believe families with children experience worry that their children will hurt themselves when eating their food in the microwave. I know that I accidentally put metal in the microwave a couple of times as a kid and scared the heck out of my parents. There might be some opportunity for innovation here. And we believe busy espresso drinking professionals are frustrated that espresso takes too long to make when they're trying to get ready in the morning. That's definitely a problem I have. And have you ever heard of an espresso machine? Now, you want to find customers to talk to. The best place to find customers will largely depend on if you already have a product. And if so, what type of business you're in. I bolded a few of my favorite options, but some of the others may work better for you if you don't have a product yet. For your online avenues, you have product surveys. Surveys are personally my favorite because you can include questions that tell you of a particular customer is the type of customer you're looking for. You can also ask in advance how satisfied they are with your product before meeting them, which might help give you some useful context. You can also reach out to current customers via email if they signed up for your service or more creatively engage with communities on Reddit, LinkedIn, Slack groups, Quora, and other online forums, especially Reddit has a community for almost anything you can think of. And if you're really scrappy, you can build a preview or fake website advertising your product. When customers arrive to it, you can say the product is still under development, but ask for their email to be notified of additional updates. You also have physical avenues. If you can manage it, visiting your customer's workplace can be invaluable. You can see how they work and use your product in real time. Conferences are also really valuable because people who attend conferences are likely to be passionate individuals in that subject and give you really high quality feedback and be more likely to talk to you. You should also consider relevant gathering places for your customers. If you're building a workout app, talk to people at the gym. Friends and family are also usually easy to reach and get feedback from if they fit your target customer profile. You can also ask for introductions from friends and co-workers or even go to social places in your local community like coffee shops and start talking to people or put up a sign that says what you're advertising. Especially if you're building a new product from nothing, you'll want to be creative and scrappy. You might be surprised how many people are willing to talk to you, especially if they really resonate with the problem that you're trying to solve. A lot of people actually really like to help out other people. And if you already have a product that's important to your customers, many will be genuinely appreciate being asked for their feedback. I've had customers who were ecstatic to talk to me and they're like, I've never been able to do this for a product I cared about before. Pro tip, customers are also typically pretty excited to get a sneak peek of upcoming or possible features. So that's something that you might be able to use to lure customers in. Now, it's time to get ready to talk to customers. The first step of talking to customers is to set up the interview. Here are a few tips. Where? Well, I think you can conduct the interview anywhere that's most convenient for you and the customer. In person, in public, an office visit, video call, phone call, text chat. In person or video is probably ideal to observe body language and expression. But you can still get a lot of value from phone calls or even text chats, which are very accessible for everyone. It's usually not worth spending too much time on logistics if it's avoidable. How long should your interview be? I think the sweet spot's usually 20 to 30 minutes for the interview and then I usually budget 10 to 15 minutes to organize my notes afterwards. How many interviews? I would say no more than four or five interviews in a day. They can be really exhausting since you have to be listening closely and attentive the whole time. Now, the real question is, how many do I need overall to validate a hypothesis? It really depends. The general answer is that you can stop when you stop learning valuable new things, which may take upward of 15 interviews. However, that can change significantly based on the impact, risk and scope of the hypothesis. Is it foundational to your business or is it a small low risk change or feature? Whether or not there is other evidence to support it? Have you already heard this over and over from feedback tickets or surveys? How repetitive your initial interviews are? If you hear the exact same thing five times in a row, 15 interviews may be a little overkill. And then the urgency of the decision. Interviews take time, so sometimes you just have to make do. Lastly, who should be there? Well, you should at least stand your customer, hopefully. However, I highly recommend bringing one to two additional team members. They can help take notes. So you can focus on the interview and this is also a great way to grow customer empathy directly on your team. It will leave a much stronger impression on them than any report will. So now your interviews are scheduled. It's time to build a discussion guide. It's a list of questions that align with your hypotheses and help structure your conversation with the customer. You can have a bunch of fairly specific or tightly-scoped questions, but what's a lot more effective is having four or so broad questions and then being strategic with your follow-ups. These sorts of broad questions encourage the customer to tell a story about their experience and include details you might not have even thought to ask about. They may even challenge assumptions that you missed in earlier steps. Here are a few examples of great, broad questions to include in your discussion guide. Tell me how you do X today. Tell me about your experience doing or using X. What if anything frustrating or what if any frustrations do you have when doing X or using X? What do you think could be improved about X? What have you tried or ready to solve or get around this problem? How often do you do X? If you have a magic wand that would let you do anything you can't do today, what would you do? The magic wand question is an absolute classic and can help your customers really open up if they seem to be constrained by their ideas of technical feasibility. I usually like to have it as a last question in interviews. Now, it's tempting to just ask, is X an important problem for you? I mean, you already have your problem hypothesis. Why not just ask directly about it? It's tempting, but I would caution you against doing that because if it really is an important problem, it should be top of mind when you ask more generally about their top frustrations or problems without leading them in a particular direction. Similarly, if you ask a customer, do you want X? Should we build X? They'll almost always say yes because they don't share the cost of building a solution. It also doesn't mean if they say yes, that they're willing to buy it. You often will need to have other indicators like emotion and validate that the problem that the thing solves is really valuable to know if they'll buy it. Now, a few interview tips to help things go more smoothly. If you're relatively new to this, practice with a colleague. It'll make you a better interviewer and help you get more value when you actually have customers in front of you. Keep your tone conversational and personal. Try to avoid being too intense or frustrated if they're not seeing what you wanted to hear. Reinforce that their feedback is helpful. This interview is about them as an individual and their experiences as an individual. Even if they're not experts on the product, we want to know more about them. Use open-ended questions. Avoid yes-no questions even in follow-ups. Yes-no questions are often the least informative and they don't encourage more details. Even in follow-ups, consider questions like, could you tell me more about X or, I heard you mention X is a problem. What did you do the last time you ran into X? Pair up with a teammate so you can get another perspective on the interview and leave an impression with them. I really like to leave time at the end of interviews for an engineer to ask some questions of their own if I missed anything or if they had any of their own curiosities. And if the customer asks for a feature, guide the conversation back to the problems. For example, if they say, I want X feature, you can reply with, that sounds like a really interesting idea. I'd love to know what the core problem that solves for you is or that's really cool. I'd love to know how you would use that. Now you're ready to actually interview a customer. Exciting. Make sure you take special note of statements that validate your hypothesis, statements that invalidate your hypothesis, things that surprised you, potentially new hypotheses, repeated patterns, things you heard over and over again and strong emotions or emphasis. Review and organize your notes right after the interview, sort feedback into validates, invalidates and also interesting categories. Direct quotes are often best. Finally, it's helpful to know what a validated hypothesis looks like if your customer says, yeah, I guess that's annoying sometimes. That's probably not gonna cut it. Here are four things to look out for. The customer confirms that enthusiastically that there is a problem or frustration. The customer believes that the problem can and should be solved. The customer has invested time, money or effort to solve this problem. If they're not investing time and effort to solve it right now, what makes you think they're going to spend money to solve it later? The customer doesn't have circumstances beyond their control that prevent them from trying to fix the problem. This can be some really useful context for how they're currently behaving. And then after you've conducted several interviews enough to validate, enough to feel like you're hearing the same things over and over again, you've stopped learning or you've done 15 or more, it's time to make sense of the answers. For each hypothesis, given overall validated invalidated or inconclusive judgment, inconclusive might mean that you had half your interviews validate and half your interviews invalidated, which is often an indicator that maybe your target customer profile isn't sufficiently narrow or your target customer type. I also recommend collaborating with some of your co-interviewers you had to make sure that you have the same perspective, they heard the same things and to also just get them more involved in the process. Next, prepare a written summary report for your team, including the state of each hypothesis as you have already decided, new hypotheses, new insights and proposed next steps. Again, include direct quotes and try to tell a compelling story. Now, while a written summary is great to reference in the future and share with stakeholders across the organization, nothing quite replaces a live presentation and you'll be much more likely to get good questions. So present your findings to your team live, really focus on the customer story, not just a run through of each hypothesis, use quotes, convey emotion, and if you have clips of customers running into issues or passionately talking about their problems, that's pure gold, use that. So that's my summary of customer development, but there's a lot more to learn. We focus primarily on validating problems because it's so fundamental, but there are also techniques you can use for validating solutions as well. Without a single line of code, here are some of my favorite books on customer development. In Lean Customer Development, Cindy Alvarez adapted the term customer development to be applicable to any organization of any maturity. This book is very thorough and you'll be hard pressed to find anyone out there who's thought more about this topic. The customer driven playbook has the most detailed step-by-step guidance for exploring customer, problem, concept, and feature hypotheses, especially for techniques in the solution space, I think it's really unique and unbeatable. These two books largely shaped my philosophy of effective product management, but one that I more recently read and really enjoyed is Escaping the Build Trap. It has some great real examples of customer development used to build the right thing and how it can radically change an organization for the better. And that's all for today. Thank you so much for joining me and until next time.