To be customer focused, shouldn’t we also be problem focused?

I have at times been accused of being too intellectually pure – apparently I can have a habit of analysing a problem when all that is needed is to get moving with a solution.

It may be true because I love to understand puzzles and problems. Perhaps it is true because I do enjoy playing those corny puzzle games on my outdated nintendo gadget even though I have no time left in my day and even have access to far more sophisticated games if I want to try them.

So maybe what follows is good advice or maybe this is my own bias.

I recently saw some great proposals for small projects and some pretty decent requirements. I could understand what people were proposing and even who would be using the solutions we were providing. And my advice each time was the same – “we are clear on what we are doing but not really why”.  In response people told me we were doing it because these customers want it (our team, people who purchase our software etc).  When I then asked why they wanted it, the response was “so they can …. “.

They can do (what our requirements say) but that is repeating what their requirements are, not explaining why they have them or how we know those are the real requirements.  So I generally asked why again and got a reasonable response:

• They told us they want it; or
• We can see them doing it now (or having that problem now).

Maybe this is enough – if people want it and they will use it then isn’t that why we build solutions?

Unfortunately the intellectually pure part of me detects more of a puzzle to wrestle with, so I am hassling people for one more piece of information – What specific problem are the users/customers going to solve?

Most of the time the answer I get is the same – the problem they are solving is that they want to do this.  But I am still trying to work out what difference that make to them.  They are doing this so that (something is better) but what is better?

The answer I get is often that they can sell more stuff or do things faster.  But I still think there is a missing link and this is what I am wrestling with.

This is the requirement … it is for this specific user.  They want it because it will remove a problem or allow them to do something new

… but what is that thing and why do they want it?

So here are my new questions

1. Who is this for?
2. Why do they want it? Cool is that the real problem they have or is it a symptom of the problem?
   1. People often deal with symptoms of underlying problems, without really knowing the real problem.
   2. For new solutions people often ask for “accomodations”. An accomodation is a solution that is needed to compensate for the weaknesses in their current solution. Fo example, “we need more spare parts” might be caused by the weakness that our existing spare parts are poor quality and fail too often.  More spare parts will help, but better would be to remove the need for more spare parts.
3. So what problem are they solving when they get this?  What problem will they still have?  is this second problem the one we
4. Do they know they have that problem? how important is it compared to other things? How often do they have the problem?
5. What solution do they have in place at the moment?  (I know they don’t have this thing yet but they might have something even if it is hand-written post-it notes on their fridge) Have they tried anything else that hase faded away?
6. When we solve this problem, what happens next?  What will they want next, what will their issues be with our solution?

Maybe I ask too many questions when we have already been told what they want.  When I send people off to ask more questions they often get the response that things are urgent and their questions are slowing us down – “we know the requirement already -so let’s get on with the solution?’

We know the requirements already – we need to move onto the how we will implement the solution.

But if we are focussed on providing a solution we should know what we are solving shouldn’t we? And even if we know what the requirements are – what are they the requirements for?

Maybe I would settle for this much (but i will still have more questions).  In the book “Four Steps to the Epiphany” they recommend these questions for early adopters of products

1. Who is it for?
2. What problem will it solve for them?
3. Is it already hurting them? ie are they aware of the problem and if so how important is it to them?
4. What solution do they have in place?
5. Do they have a budget to pay for the solution?

But even then I will secretely have one more question, I can’t help myself – Who will this not help? Or who might use this but won’t care too much?  Then rather than solving the generic problem for all our customers (and being “lot’s of customers focussed), we can solve a specific problem for a specific customer.