Pretty good. Very actionable. Good supplement/continuation to Ries’ The Lean Startup. Will be great to have as a resource to reference on my bookshelf.
Notes:
Customers are what make a product successful.
Customer development = reducing business risks by challenging assumptions on who customers are, what they need, and why and how they buy. Customer development parallels product development. Hypothesis (guess) driven approach. Shift your mindset to actively trying to poke holes in your ideas, prove yourself wrong, and invalidate your hypotheses. Five steps to lean customer development: (1) form a hypothesis, (2) find potential customers to talk to, (3) ask the right questions, (4) make sense of the answers, (5) figure out what to build to keep learning. If your hypothesis is wrong or even partly wrong you want to find out fast. Customer development answers the question “will they buy it.” User research = advocating for the user. Customer development = advocating for the company. Every hour spent on customer development saves HOURS of wasted time building.
Exercise:
(1) what are our assumptions? Make an Excel tracker of all assumptions and whether or not they’ve been validated. Use evolving questions list to validate these. See page 19 for list of prompts to help figure out assumptions.
(2) what is our problem hypothesis? “I believe [type of people] experience [type of problem] when doing [type of task].” Or “I believe [type of people] experience [type of problem] because of [limit or constraint]. Think about the who, what, where, when, why. Use Excel to track problem hypotheses. The more narrow your hypothesis the quicker you can prove/disprove it (“Is it easier to disprove that acts like water or that animals like water?”).
(3) what is our target customer profile? Focus on day one people (i.e. innovators/early adopters). Think about their traits/preferences on a spectrum (e.g. do they value cash or do they value time). See page 25 for a list of traits/preferences to consider.
Need to find earlyevangelists = people suffering the most severe pain, not necessarily early adopters = willing to take the risk on your unfinished, unproven product. These people will like to help others, sound smart, help fix things, and complain. See page 36 for an example of how to ask for introductions.
See page 60 for basic customer questions. These are the only scripted questions: (1) “Tell me about how you do ___ today…” (2) “Do you use any [tools] to help you get ____ done?” (3) “Forget what’s possible, if you could wave a magic wand and be able to do anything that you can’t do today, what would it be?” (4) “Last time you did ____, what were you doing right before you got started? Once you finished, what did you do afterward?” (5) “Is there anything else about ___ that I should have asked?” Each of these five scripted questions is a prompt/conversation starter. “It’s not the customer’s job to know what they want” - Steve Jobs. Customers’ current behavior is your competition, whether it works well or not. Abstract up one level to not narrow down your answers (e.g. don’t ask a parent how she delivers groceries to her house, ask how she feeds her family). Focus on the present, not the future; use prompts that yield actual responses instead of aspirational responses. Ask your customers to break down their procedures and realize that their second nature should be questioned.
In the first minute of the interview: (1) make the interviewee feel confident that she will be helpful, (2) explicitly say that you want her to do the talking, (3) get the interviewee talking. Have a scripted intro and outro, the rest shouldn’t be SCRIPTED. See page 88. Don’t say a word for the next 60 seconds after your intro. Don’t ask yes or no questions; open-ended answers only. Avoid asking leading questions. Summarize what the interviewee said back to them and dig deeper on anything you don’t understand or is surprising. Ignore what customers “want,” and focus on how they behave and what they “need”; focus on their problem, not their suggested solution. “If I had asked my customers what they wanted, they would have said a faster horse” - Henry Ford.
In the last three minutes of the interviewee, you should: (1) offer some of your own time to the interviewee, (2) make the interviewee feel that she succeeded in helping you, (3) thank her personally for giving her time. See page 101 with example outro.
Maintain healthy skepticism. If someone says “maybe” treat that as a “no.” The best predictor of future behavior is current behavior. “Enough interviews” = you no longer hear things that surprise you.
Four components of a validated hypothesis: (1) customer confirms there is a problem, (2) customer believe the problem can and should be solved, (3) customer has actively invested (effort, time, money, learning curve) in trying to solve this problem, (4) customer doesn’t have circumstances beyond his role that prevent him from trying to fix the problem.
Each interview should tell you: (1) if I had a product today that completely solved this customers problem, do I see any obstacles that would prevent her from buying or using it? (2) how would she use it and fit it into her day to day activities? (3) what would it replace? (4) if she would not buy my solution, what are the specific reasons why not? Industry experience will lessen the number of interviews needed.
Don’t worry about a script/consistency with customer development because you’re learning about unique individuals.
The only proof that customers will pay for your product comes when customers pay for your product.
The goal of MVP is to maximize learning while minimizing risk and investment. “Minimum” = low investment and time, and should be able to explain in a couple of sentences. “Viable” = enough experience to show value to your customers, and providing enough information to prove/disprove a hypothesis. Some common MVP types are:
(1) pre-order MVP: describe the solution and have customers sign up and order before it is available. Their card is not charged until the product is available. For enterprise solutions, a letter of intent or agreement to roll out a pilot program may suffice. Think about giving preorder people a discount for maybe the first year or so. Every company should aim for a pre-order MVP in some form.
(2) audience building MVP: create a gathering place for your audience. Doesn’t validate whether people will pay for your solution or not, but allows you to gauge customer retention and participation.
(3) concierge MVP: manual effort is used to solve a customer’s problem. Customer is aware of this, and in exchange for your large investment of attention and time to them, they agree to provide you with lots of feedback. Allows you to give the experience of the product to customers before you actually build it. Not scalable.
(4) wizard of Oz MVP: provide a product that appears to be fully functional, but is actually powered by manual human effort. Not scalable.
(5) single use case MVP: focuses on a single problem or task. Helps you validate features as you go, using customer demand and adoption. Can be good to test new features for an existing website.
(6) other peoples product MVP: use existing solutions and mask them to be your own to validate a new hypothesis before you go and build everything. Similar to Wizard of Oz MVP.
There is no point where you should stop doing customer development; you will benefit from continuously learning and validating.
Complaining is a sign of interest. It shows the customer values the experience enough that they want to improve it.
Ask “how disappointed would you be if you could no longer use our product,” as opposed to the positive version of “how satisfied are you with using our product.” Reach out to and learn from the customers who say “very disappointed.” Those will be the most passionate. Use their same language. Enthusiastic customers will talk about benefits more than features. Words that customers choose to describe the product can help you sell more of it.
Focus should be on making your customers feel awesome, not on telling customers that your product is awesome.
Explain to customers and make it clear the feedback stage that you’re at.
Use both: ask the customer to show you how they use your product, and also show and tell the customer how to use your product while being didactic for them to clearly agree or disagree with you.
When customers ask for new features, restate their description and ask them why/what this would allow them to do. You need to understand and solve the underlying problem, as you may get many different requests from customers that all have the same underlying problem.
See page 195 for questions to use:
“Tell me about the last time you ___.”
“If you could wave a magic wand and change anything about how you ____, what would it be?”
“What tools do you use for ____?”
“When you started using [tool], what benefit were you expecting?”
“How often do you ____? Let’s say, how many times in the past month?”
“When this occurs, how much additional time or money does it cost you or your company?”
“Who else experiences this problem?”
“When you do (or use) ____, is there anything you do immediately before to prepare?”
“When you do (or use) ____, is there anything you do immediately afterwards?”
“Would you be willing to help us by participating in user research or beta testing?”
“When you use [our product], what’s the first thing you do with it?”
“What’s the most useful thing that you regularly do with our product?”
“If you had [requested feature] today, how would that make your life better?”
“Other customers have told me they experience [problem]…”