Why Not What – An Example

Obscenely complicated WW2 U-Boat controls

Forbes quoted Steve Jobs as saying “I’m as proud of what we don’t do as I am of what we do.”  This is a really enlightened perspective – and a way to enforce focus from the top down.  Before you can drive a “this goal is more important than that goal” focus, you have to make sure you’re actually focusing on the goals.

The Customer Does NOT Know Best

customer request from the Google Play store

The top review of a mobile phone app caught my attention over the weekend.  I highlighted a section which really provided clarity for me about the difference between building what the customer asks for, and what the customer actually needs.

The app provides food-item nutritional information.  As you might imagine, navigating the tables of information on a smaller touch-screen device (phone or tablet) could be tedious or tricky.  Definitely a place where the user’s experience could be improved.  This user, who likes the app, wrote a request to be able to sort the tables by column – a “faster horse” for the smart phone era.

This reviewer also added some prose to justify the request for sorting – the desire to avoid foods which are bad for him.

The extra information actually allows us to get closer to the “why” – a desire to eat healthy foods – and not fixate on the “what” – the ability to sort the information. I’ve worked with many people who would do something like the following:

  1. Add a story / feature request to the backlog / spreadsheet, to enable users to sort the information in the tables.
  2. Get feedback from other users – “would you like to be able to sort?”
  3. Prioritize and schedule the feature to be built.

This can easily happen because the product manager focused on the “what” of sorting.  It is an easy mistake to make.  The customer asked for sorting, so the customer wants (needs) sorting.  When I asked other customers if they wanted to be able to sort, they all said “sure.”  This is being customer-driven, and outside-in, right?  Wrong.

Being Market Drive Requires Synthesis

If you’re a regular reader here, you’ve already heard 100 times the importance of asking “Why?”  A different question approach, based on Clayton Christensen’s work in The Innovator’s Solution and the Jobs to be Done approach, will simultaneously ask “why?” and initiate the synthesis process.

“What are you trying to do, when you want to sort?”

There may be a much better way to avoid unhealthy foods than giving users the ability to sort.

You shouldn’t stop here, either.

What are you really trying to accomplish, which is driving you to avoid unhealthy foods?

Perhaps the user has a medical condition which restricts their dietary choices, if the goal is to feel better (in order to spend higher quality time with their family).

Conclusion

If you’re trying to build a nutrition-information app with the goal of helping someone feel better, you probably wouldn’t put “sort by sodium level” at the top of your backlog.  Instead you might build an app which asks them how they feel every day, correlates that with what they ate recently, and then warns them when they are about to make historically bad choices (or rewards them for repeated good behavior).

Being market driven is about synthesizing what customers tell you. Your area of expertise is to understand what is needed, based on what is asked for.  The customer’s area of expertise is not in root-cause analysis, abstraction, interface design, and software development – they won’t make directly-useful requests.

Give them what they need, not what they ask for.

7 thoughts on “Why Not What – An Example

  1. I couldn’t agree more. It is incredibly important to listen to the customer but the real value add is the interpretation of need. Products that are driven by customers’ item requests can quickly turn into a Frankenstein app. A great app can be ruined by not asking why. Death by item…

    1. Thanks, Katherine, and welcome to Tyner Blain!

      This also opens an interesting view into “requirements vs. design” – when someone asks for a feature, they are implicitly designing the solution.

  2. Tyner, This reminds me of the Rolling Stones song: “You Can’t Always Get What You Want.” … “because if you try sometime, you just might find you get what you need. Oh yeah!” A skilled BA and a usability analyst can partner with the customer and engage in dialog. Too often a BA settles for what the customer wants (what they ask for) rather than probing and discussing and arriving at what the customer really needs (to meet the why). Thanks for another thought-provoking article. How’s the book coming along?

    1. Hey Glenn,

      Whenever I hear that song now, I think of product design and requirements elicitation. I think that means I need help.

      I really should do something book-ish. I keep prioritizing other stuff ahead of a book. :)

  3. Thank you for the wonderful article. I agree wholeheartedly but dilemma is as always, how to convince the customer that what they really need, is not what they think they need. Personal experience has taught me that proposing alternatives to customers is always a delicate situation as it is easy to fall into the trap of sounding dismissive of the customer’s suggestions/feedback.
    Unfortunate as it is, the easy out for any business is to give in to the customer even if experience tells us that what they are providing is not optimal. Customer perception drives satisfaction, and that’s why so many products are cluttered with “sort by sodium level” type features.

  4. You can’t please everyone all of the time, and this is true with your customers too. Great article. Forward thinking and really analysisng your customers needs is key.

    1. Thanks, Ken, and welcome to Tyner Blain.

      The concept seems so straightforward, but so many teams violate it. I wish we could discover the “perfect” way to phrase it, such that people fully appreciate the trade-offs.

Leave a Reply

Your email address will not be published. Required fields are marked *