After introducing Lean startup
in the last episode, this installment focuses on
good ways to communicate with customers.
Don't do what customers say they want, understand their problems and solve them.
-- Per Haug Kogstad (Tandberg founder)
Problems, Products and Markets
Most startups begin with a brilliant new product idea. Most startups fail.
While pulling an ingenious new product idea from your lower torso may work on occasion,
a more systematic approach is to perform a sober analysis of the following three aspects:
- A problem is the reason people want your product. Is it a big enough problem for people to pay you to solve it?
- A product is the way you solve the problem. Are you capable of solving the problem? How do you know if you've found the "best" way to solve the problem? Are there other ways to solve it?
- A market is a group of people who might want to buy your product. Who wants the problem solved badly enough to buy your product? Can you build a sustainable business in this market?
Perhaps the worst way to answer these questions is to ask the customer what they want.
A more promising approach is to observe and listen to the customer,
so as to gain a deep understanding of their problems.
Focus on their big problems, the ones they'll be glad to pay you to solve.
You need to differentiate between cool and interesting problems and real problems for real people.
Laura Klein gives some examples:
- Word processors solved the problem that it was tough to edit something once you've typed it.
- GPS navigation solved the problem that we are likely to get lost when away from our homes.
- Angry Birds solved the problem of delivering pleasure hormones to our brains while waiting for a train.
Admittedly, this is hard to predict and there is no guarantee of success.
Is playing Angry Birds while waiting for a train really a vital problem?
While there is no guarantee of success, and yes, most startups fail,
early validation of product ideas ensures you fail as cheaply as possible,
allowing you more shots at success.
Customer Interviews
Justin Wilcox suggests you start by asking your customer two introductory questions:
- How do you describe your role?
- What does success look like for you?
With that context clarified, ask the following five questions:
- What's the hardest part about <your problem context>?
- Can you tell me about the last time that happened?
- Why was that hard?
- What, if anything, have you done to solve that problem?
- What don't you love about the solutions you've tried?
Notice that we are trying to steer away from hypothetical questions,
in search of genuine problems that might be used to start a new
business or grow an existing one.
After the customer interview, you need to go away and figure out
if you can build a solution to any of their big problems.
Solution Interviews
Rather than pitch a proposed solution to the customer with a demo
that ends with them saying: "Thanks very much, we'll get back to you",
Wilcox recommends doing a Solution Interview instead.
- Don't start with a demo!
- Pick the big problems from the customer interview that you think you can solve. Restate the problem; for example, I heard about this problem you have. Is that right? You need confirmation that you've properly understood their problem.
- Propose a potential solution. Honestly ask for feedback. What do you think about this solution? Initiate a two-way discussion.
- Finally, now we agree we've got the right problems, and we think we can solve them together, what do we need to do to make progress? What are the next steps? Make a to-do list with the customer.
The general idea is
not to pitch your solution, rather to engage the customer, build trust, build a partnership.
User Testing
If the Solution Interview went well, build a prototype solution (MVP) and observe the user interacting with it.
Don't fall into the trap of building a broad MVP that is crappy and unusable.
Instead, build a usable, but limited, version of your product.
Laura Klein gives some tips on how to get good feedback from customers,
based on years of watching mistakes made by folks lacking a user-experience background:
- Shut the hell up. You want their opinions, not your own. You also need to give them more time than you think to figure things out on their own.
- Don't give a guided tour. Let the user explore a bit on his own. Then give the user as little background information as possible to complete a task.
- Ask open-ended questions. The more broad and open-ended your questions, the less likely you are to lead the user and the more likely you are to get interesting answers.
- Follow up. For example, if the user says "that was cool", follow up and ask precisely why that was cool. Don't assume you know what makes a product cool.
- Let the user fail. This can be painful, especially if it's your design that's failing. You're not testing if a person can be shown how to use a product, you're testing to see if a person can figure out how to use the product.
Quantitative vs Qualitative research
Quantitative research, for example A/B testing or Funnel analysis,
measures what real people are actually doing with your product.
It's statistically significant.
Qualitative research, for example customer interviews and observing users and understanding their behavior, gives important insights,
but is not statistically significant.
Quantitative research tells you what.
Qualitative research tells you why.
You need both.
Miscellaneous Tips
Some general tips taken from a talk by Atlassian Product Manager Sherif Mansour on Building the right thing:
- Distill customer interviews and customer conversations into a manageable set of Personas. Make these personas visible to everyone (Atlassian even stick them in the toilets).
- Ask why. Understand why.
- Find the root of the problem.
- Understand the problem.
- Define the solution.
- User Journey Mapping. Shows end to end flow of a persona using a feature, starting with installation.
- Get the user journey right (e.g. map out how someone enters/exits a feature).
- Fake it till you make it. They use a variety of Pretotyping techniques as discussed in episode one; e.g. recording videos and showing to customers to elicit feedback.
- Get feedback before you start (fake to validate you are building the right thing).
- Choose carefully (beware domino effect).
- Tell your story. Before you start. Build your box (hero shot, pitch and three pillars).
- Assume no docs. This changes how you build your solution.
Perl Monks References
External References
