How do I distil users’ wish lists of requirements to a core handful?

I was recently asked this question:

Can you make suggestions of how best to distil users’ wish lists of requirements/outcomes to a core handful that will encompass most people’s problems?

Read on for my answer:

Hi there,

Thanks for the question. I have a couple of suggestions that may give you a different perspective for your problem.

You mention users’ wish lists of requirements. I appreciate this may not be what you meant, but this is a good point worth reiterating anyway. Yes, you absolutely need to be user-centric, but that doesn’t mean you implement what your users are asking for. Confusing, right?

Let me explain a little further. Marty Cagan says he learnt this while working at Apple: “People think they can learn what to build from their customers. But of course, we can’t.”

There are two main reasons for this:

• users don’t know what’s possible; and
• users don’t know what they want until after they see it.

In other words, users can only define their solution in terms of what they already know. It’s a bit like that other quote often attributed to Henry Ford, along the lines of “if we asked people what they wanted, they’d ask for faster horses”, when in fact the answer was the automobile.

So if you ask your users to recommend features as their wish list for the product, you’re actually asking them to design the product for you, and at best you’re only ever going to get is a slightly better product.

Instead, you do still need to talk to your users. In fact you need to talk to them even more and watch them using your product (or if you’ve not built it yet, observe them while they experience the problem you intend your product to solve). Your goal is to understand their context well enough so that you can discover the underlying problem.

To give an example from the UK government again, one of our services¹ at the Ministry of Justice allowed people on low income or state benefits to receive a reduction in court fees. To make use of this service, people used to have to fill out a paper form. User research told us they found the questions confusing and tedious. And because they often made mistakes, forms would be processed, rejected and the whole cycle would go round again, wasting time and money on all sides.

But when we asked people directly how to improve the process, all they could suggest was to clarify questions on the form – at best making the existing paper form only slightly better. Instead, we saw the paper form was disrupting the flow of allowing an eligible person to start using a service.

So the answer was actually to do away with the paper form entirely, verify the user’s identity, then use information government already held to determine whether the individual had a low income or received benefits.

We didn’t actually need to ask the user for all that information in the paper form because we already had the answers we needed in information held in existing government systems – the sources of that information just weren’t linked up. Now, several hours of collating and checking a user’s paper evidence of low income or benefits is replaced by a near-instant API call.

So going back to the original points:

• users don’t know what’s possible; and
• users don’t know what they want until after they see it.

Users could only envisage improving the process with a slightly better paper form, but when the automated eligibility check was presented to them, meaning they didn’t have to fill out the form at all, they could see it was it was a far better alternative. They simply didn’t know (and arguably, neither did the Ministry of Justice for a good while) that it was possible to do away with the paper form in the first place.

If you conduct user research in this way to reveal the underlying problems or user goals, then it becomes much easier to distil down to the core set of user stories. You can ask yourself “will this roadmap item get us closer or further away to what our users are trying to achieve?”

Cheers,

Jock