Note: My experience in customer development has been largely with SAAS (B2B) startups. Therefore, many of my lessons may not be directly applicable in a B2C scenario.
I conducted a workshop a few months ago, on customer development as part of the ProductNation initiative. Much of the content in this post is derived from the notes I had prepared for that workshop.
I’ve divided this post into the following 3 sections:
- What is Customer Development?
- How Customer Development Works
- Closing Notes
In the 2 years I spent in the product and growth team at BrowserStack, I spoke with hundreds of customers on the phone. The primary objective of this customer development exercise at BrowserStack was to improve the product and build new features to drive growth for the company.
What is Customer Development?
Customer development is certainly not asking your customers what they want and then building it.
What customer development really does is help identify the right problems to solve so that you build something that your customers will buy. Additionally, it helps you validate your hypothesis and assumptions. The idea is to spend more time speaking with your customers and less time and money on engineering and design.
I cannot overemphasize the importance of identifying the right problems to solve. BrowserStack gets this right. I was told by the CEO there that solutions are relatively easy but identifying the right problem to solve is not. I couldn’t agree more.
In sum, customer development doesn’t provide you with all the answers on what to build. But it definitely provides a better understanding of customers and a keener appreciation of the problems they grapple with. You will still need a founder or a product manager to sift through all the information to determine what is relevant, prioritize the inputs received and decide how to turn the inputs into a tangible feature or a product.
How Customer Development Works?
1. Start With Your Hypotheses
A good point to start the the process of customer development is with some hypotheses you’re trying to validate. If you’re building a new product from scratch, there will be some hypotheses you have about the industry or the problems you think your potential customers face. Your logical next step then would be to get on a call with your potential customers and find out as much as you can about their problems before you even start building anything. This step is applicable to even a small feature you’re trying to build for an already existing product.
For example, in BrowserStack, one of the hypotheses we had was that occasional usage of the product was one of the biggest contributing factors to a high churn rate. Therefore, our customer development exercise in this case was focused on understanding the behavior and day-to-day activities of our customers and the availability of alternatives as a result of which they were canceling their subscriptions.
2. Identify Your Users
In order to validate your hypothesis, you need to speak with your customers or your potential customers if you don’t already have a product. Therefore, let’s first identify who your ideal customers are or who your ideal customers could be. You should be able to define your ideal customers through a mix of the following parameters: Industry, Size of company (based on the number of employees or revenue), Region, Role/Function, Title. Let’s call the different sets of ideal customers created through the parameters above as user personas. For example, in BrowserStack, one of the personas was QA Managers in Enterprises (1000+ employees) in the Technology (Software) industry.
3. Create a List of Users to Speak With
Once you’ve identified your user personas, you need to create an actual list of users you could speak with. If you already have a product that is being used by customers, then creating the list is not a problem. However, do note that the user personas of your free and paid product could be different and you will need to speak with the relevant ones based on the problem you’re trying to solve. If you’re building a new product, in addition to reaching out to your personal network, you could also scour LinkedIn for potential contacts and get in touch with them over LinkedIn itself or through Twitter. Quora could also be a place where you could identify people you could speak with.
Once you start this exercise, you will realize that people are actually not that averse to speaking with you. They do it for different reasons. At BrowserStack, people loved the product and they loved propagating the product in their organization. Who wouldn’t want to be known as the person who introduced and evangelized an amazing product in their company? We had many such users at BrowserStack. Scheduling calls with them was a breeze. Some others are just willing to help. And many others feel important when you tell them that this exercise is limited to a certain number of people and that their inputs would help shape the future of a product or a business.
4. Get in Touch With Your Users
Once you’ve created this list of users, reach out to them through email to schedule a call or an in-person meeting. Among the customers you reach out to, the response rates for the ones willing to get on the phone with you depend on how you sell to your customers. For self-service sales (as was the case with BrowserStack), around 20% of the free users (those without a subscription) I reached out to were willing to get on the phone with me. For paid users, the response rate was as high as 50% to 70%. For inside-sales or field sales (as is the case at WebEngage, the startup I work with currently), almost all the customers want to speak with me.
Following is an example of an email I had sent to some of our registered users on BrowserStack who had not purchased a subscription. Once they responded with an answer, I was successful in requesting them to get on the phone with me to answer some of the other questions I had based on their first reply.
I have a slight preference for conducting customer development studies over the phone than through in-person meetings. I can take notes during the call without distracting the customer whereas taking notes in an in-person meeting can be a distraction for the other person. I have done some customer development studies on Email as well but these have been mostly for very specific questions I had. I personally don’t prefer online surveys. I think these should only be done when you already have some options/solutions in mind and you’re only seeking help from your customers to validate and prioritize.
If you’re doing customer development over the phone, take into consideration the timezone your users reside in and suggest time-slots to them based on their time zones. Use LinkedIn or Rapportive to figure out where your customers are located. Also, ask them for their mobile numbers specifically. I’ve had people not join the scheduled conference calls in the past as they forgot about it or missed the calendar reminder. And I tend to now ask them directly for their mobile numbers as the odds of the call happening are much better in this case.
Lastly, for the emails you send out to schedule these calls, remember to follow up with a 2nd email to those who did not respond to your 1st email. I cannot overemphasize the power of the follow up. Half my calls at BrowserStack got scheduled through the follow up! Needless to say the emails have to be personalized. Nobody likes signing up for some generic customer study.
Here’s an example of a follow-up email I had sent to the customers at BrowserStack:
5. Ask Your Users These Questions
In this section, I’ll cover some of the questions I always ask customers. This is not an exhaustive list and your exact list of questions will differ based on the hypothesis you’re trying to validate. I generally tend to prepare around 15 to 20 questions that I need answers to during the call. Of course, the order in which I ask my questions is dynamic and depends completely on how the call is going.
In my experience, open-ended questions work much better than close-ended ones. I tend to not ask the user to choose among options or what they think about a particular solution. I’ve realized that I only end up biasing the user or constraining their thinking with such close-ended questions. An example of a close-ended question is Do you prefer A or B? Instead of asking the user to choose between two options, I tend to ask more questions about the problem the user is facing.
Following are some basic questions I usually include in my customer development calls:
- About the company (what it does, industry, number of employees)
- About the person (objectives, responsibilities at work etc.)
- Their single biggest challenge and other problems they face
- The last time they faced the problem(s) and how often do they face it. This helps you in understanding whether the problem is occasional or if it is persistent. It might be difficult to build a business around a product that solves only occasional problems for a user
- How does this problem impact their business or how much time and money does this problem cost their company. This helps in understanding the gravity of the problem. Even if the problem is persistent, if it doesn’t cost the customer substantial time and money, he/she wouldn’t be that keen on solving the problem
- How are they currently solving the problem? Even if the user claims that the problem is persistent and that it results in a substantial loss of time and money, let’s try to validate this. If the problem is big enough, the user would already have some sort of solution to alleviate the problem. If there is no solution currently, then is the problem as grave as the user is making it out to be?
- Problems with their current solution
- If there was anything I didn’t ask them that I should have
6. Take Notes & Summarize
Take copious notes during your call. Record your calls so that you can refer to them later. As soon as your call is done, create a summary of what was discussed during the call. When you start doing multiple such calls in a day, it becomes difficult to remember who said what.
Once all your calls are done, create a summary of all the call logs in one place. Look for patterns in the summary and try converting these patterns into solid findings. Based on these findings you will be able to determine the plan of action for your product.
Of course, this entire customer development process is iterative in nature. You will take these inputs, build a product or feature or create a strategy and put that into practice, do more of the customer development to validate what you’ve built and so on.
Lastly, while the process of customer development is continuous in nature where you’re speaking with your customers on almost a daily/weekly/fortnightly basis, the majority of customer development tends to happen in the initial stages when you’re trying to validate your hypothesis.
Closing Notes
You will start seeing some patterns as soon you have made between 10 and 15 calls. Later user interactions tend to yield similar patterns. Hence, you may decide to conclude customer development studies for the your hypothesis when you stop hearing new things.
Each call can take anywhere between 30 and 45 minutes. I would not suggest doing more than 4 customer development calls or meetings in a day as the process can be exhausting. Remember, in addition to just speaking with your customers, you’re also taking notes and summarizing the discussion as soon as you’re done with the call.
If your product has been in the market for a few years, you could also consider putting together a Customer Advisory Board that you can depend on for testing your initial hypothesis and for validating your solution. While I was at BrowserStack, our competitor SauceLabs had put together this board. This made their customers feel important. So much so that some of them had updated their LinkedIn profile to mention that they were a part of this board.
At BrowserStack, we employed customer development to build features addressing a number of problems eg. increasing conversion, reducing churn, revamping pricing etc. In the future, I will cover some of the specifics of how we went about solving these problems and the role that customer development played in tackling these problems.
Arpit Rai is Product Lead @ WebEngage | ex-BrowserStack, Deloitte | Also created ghatiparty.com, bridgebill.com
[Cross-posted by Arpit Rai from his Medium article]
