Starting From Solutions: When a customer requests a solution

Gerald was leading a discussion on a feature. The customer asked to have a specific system behavior added to the system. He wrote down what the customer said and submitted it as a requirement. The architect soon intervened to let him know that what was requested wasn’t possible. Gerald was confused. The customer had requested that solution. He thought the request was the requirement.

When the customer requests a solution

I’ve been part of meetings where a customer expressed a need as a solution like in the example above. If left unanalyzed, this can set expectations that cannot be met by the system. The customer is telling you how they would experience the solution; however, assuming the behavior is the requirement can create solutions that don’t solve the problem. More exploration is needed when this happens.

But “Don’t talk solutions” is a bunch of malarkey

There’s a camp of purist analysts and designers who will tell you “don’t talk about solutions” when you’re discovering needs. I am not in that camp. I recognize that some customers will tell you the solution they want but not realize they’ve offered one. We should meet our customers where they are. (Check out my post on The Difference Between Hearing and Listening on how to do this) That is, we should start the requirements discovery from how they might see this problem solved. Note that that is not the same thing as assuming their solution is the requirement.

Striking a condescending tone (“I don’t think you really need a drop-down.”) or being abrupt (“We don’t need to talk about solutions”) will make the conversation awkward and could damage your relationship with the customer.

What do I do if the customer tells me how they want it coded?

First, assume the customer is sharing a future state with you. Your job will be to help them unpack it by asking smart questions that identify their real needs. Do that by retro-engineering how they got to that vision and start your discussion from there. The customer can correct or elaborate further on what you’re asking. This gets the discussion out of the design realm and back into a discovery mode.

Here’s an almost real-life example:

Customer: I want a drop-down on the page that includes the form number and name.

Me: How would showing both identifiers help you?

Customer: I wouldn’t have to keep a list of the form names on my desk when I’m writing a policy.

Me: OK, so you need the ability to know which form you are selecting when you are writing a policy? And you’re just picking one form at a time?

Customer: No, I can select one or several forms for that policy but I need to see their names to make sure I’m picking the right ones. (note to reader – this confirms that a drop-down might not be the right implementation).

Me: I see. You need to be able to multi-select forms as well. And can you pick any form in the list?

Customer: No. I can only pick certain forms based on the policy type. I have to keep that list on my desk too.

Me: Got it. You need the system to ensure that you only see the forms that you can pick for the type of policy.

Customer: Yes, that’s right.

The takeaway

Notice that I’m not taking the conversation forward to elaborate further on the solution provided by the customer. I’m taking the conversation backward by asking probing questions to find out how she got to this future state vision. I’m not committing or disagreeing to the solution either.

If I had just walked out of the room with the “I need a drop-down” statement, I wouldn’t have fixed the problem AND I might not have uncovered additional needs. That’s why we can’t assume that the request as phrased by the customer is the requirement. But, because we started the conversation from where the customer was, we could use her vision as a way to explore her needs.

Bottom line – don’t discount how can use the customer’s vision as a starting point for requirements discovery.

Want to learn more about how to use simple yet solid practices to achieve the best results? Subscribe to my newsletter!