Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Building the Right Thing (Part III): Customers

by eyepopslikeamosquito (Bishop)
on Nov 01, 2015 at 05:37 UTC ( #1146604=perlmeditation: print w/replies, xml ) Need Help??

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

  • Comment on Building the Right Thing (Part III): Customers

Replies are listed 'Best First'.
Re: Building the Right Thing (Part III): Customers
by talexb (Canon) on Nov 01, 2015 at 15:19 UTC

    Interesting post.

    A few months ago, I spent an hour at Freshbooks, answering questions for a $50 gift card. It was a really interesting session, and the two poeple running the session did two things right. 1. They encouraged me to think out loud as I explored and evaluated the various screens -- which is something I also heard during my interviews with Google. What's going on inside a test subject's head is really what they are interested in. 2. They knew when to move from just observing what I was doing into the more probing "Tell why .." or "How would you improve .." questions.

    It's quite an art to extract the most juice from a willing test subject. And it's vital research for a company to be doing.

    Alex / talexb / Toronto

    Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

      A few months ago, I spent an hour at Freshbooks, answering questions for a $50 gift card. It was a really interesting session, and the two people running the session did two things right. They encouraged me to think out loud as I explored and evaluated the various screens...
      Interesting to learn of your experience. Though not a UX professional, thinking out loud seems an excellent way to do it. I see that usability testing has got a lot cheaper and faster in recent years, with many web sites popping up, offering a variety of testing services, for example, ("get videos of real people speaking their thoughts...") and many others.

      Another way for smaller companies to do UX research cheaply (well, cheaper than your $50 gift card) is to go into a coffee shop with a laptop and offer to pay for people's coffee in exchange for them having a go at using your software.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://1146604]
Approved by kcott
Front-paged by kcott
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (5)
As of 2021-06-12 15:33 GMT
Find Nodes?
    Voting Booth?
    What does the "s" stand for in "perls"? (Whence perls)

    Results (53 votes). Check out past polls.