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?
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.
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?
- 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?
After the customer interview, you need to go away and figure out if you can build a solution to any of their big problems.
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.
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
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.
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
- Lean startup (wikipedia)
- Building the Right Thing by Sherif Mansour (Product Manager Atlassian)
- Atlassian Design Guidelines
- Lean UX book by Jeff Gothelf
- Why Lean UX? by Jeff Gothelf and Josh Seiden
- Lean UX Slideshare by Jeff Gothelf
- Stack Exchange Lean UX question
- Lean UX vs Agile UX blog
- Ten Principles of Lean UX
- Lean UX Manifesto
- UX Design in Agile Development
- UX for Lean Startups book by Laura Klein
- Customer Dev Labs by Justin Wilcox
- B2B Customer Interview links
- B2B Customer Inteviews
- Justin Wilcox answers questions
- Justin Wilcox Customer Interviews
- Justin Wilcox Solution Interviews
- Justin Wilcox Solution Interview (youtube)
- User-centred Design (UCD)
- Use case
- Usability testing
- Usability inspection
- Usability inspection methods
- Contextual inquiry
- Usability for Nerds
- Effective Customer Interviews Slideshare by Adrian Howard
- Value-stream mapping