A fool-proof method to drastically improve the quality of your solution requirements

"Customers don't know what they want! They ask for X, but when you build it, they just change their mind and realize they actually want Y. It's really frustrating."

Every time I hear this complaint from a business analyst, product manager, or IT manager, I have to refrain from starting a tirade that could be summarized in two bullet points:

• Yes, people are bad at predicting what kind of solution will satisfactorily address their needs.
• If you ask the right questions, customers [*] will tell you what their motivations, problems and frustrations are. Armed with this information, you can define the optimal solution to address the customer problem or opportunity.

What really bothers me in the statement "customers don't know what they want" is that it's typically said with a tone of resignation and powerlessness. The implication is that it's the customer's job to clearly describe what a winning solution looks like. If he doesn't, there is nothing the analyst can do but accept excessive requirements churn and its consequences in terms of higher cost and lower quality of the final product.

A skilled business analyst knows the last statement couldn't be farther from the truth. It's the BA's job, not the customer's, to get to the bottom of the problem to be solved. A huge amount of craftsmanship is required to go from a problem or opportunity that a company decides to address to finding a great solution for it. The right solution rarely comes out like it starts; it evolves and changes as the analyst begins to explore the subtleties of the problem and identify the tradeoffs involved.

But even BAs with the right mindset often get lost in the minutiae of the requirements process, focusing on tasks, features, and tools, rather than asking,

• Why is this solution needed?

• What benefit does it bring to users over a different approach?

• How will it improve how customers do their work compared to now?

• How does it fit into their current toolset?

With the wrong approach, BAs fail to answer the most important question of all: what is the big, important problem that we're going to solve for our customers?

Here are two examples from different business domains to illustrate this difference in perspective:

Wrong approach: "I've talked to a significant number of customers, and they all agreed that making the questions we ask at tax time more user-friendly is going to be a great improvement to our tool, as it will help them finish filing their tax return faster."

Right approach: "I've talked to a significant number of customers, and the big problem we must solve for them is how to reduce their tax liability at tax time, maximizing their tax refund or minimizing what they have to pay, while keeping manual data entry as small as possible."

When we use the wrong approach and focus on tasks, features and tools too soon, we risk missing out on the best solution. Here, instead of simply trying to make the questions the customer has to answer at tax time more user-friendly, a better solution might be to allow the customer to forward documents to the tax return tool as they are received (W-2, bank statements, etc.). The software could automatically extract the information directly from the documents, minimizing and potentially eliminating the need to ask questions at tax time. By focusing the elicitation process on the "job to be done" for the customer, it’s much easier to see the opportunities to improve the solution without being restricted by the current capabilities.

Wrong approach: "Interviews with the marketing team confirmed that they need functionality to allow prospects to submit their name and email address prior to downloading resources from the company's website so the company can collect contact information for marketing purposes."

Right approach: "Interviews with the marketing team clarified that the big problem we need to solve for the business is how to collect as much information as possible about our prospects to inform future promotional campaigns."

Again, focusing on tools and features limits our ability to find the optimal solution for the real business need. With the right approach of focusing on the big problem to be solved, we gain visibility into the kinds of solution that could produce the best results. In this particular case, a superior solution might consist of a system that allows the company to produce contests, sweepstakes, and sign-up forms to entice prospects to provide valuable information that goes beyond name and email address, ranging from product usage and preferences to birthday and location. Armed with the right data, the company's marketing team would be able to make smarter decisions for the company's brand.

In the spirit of The Checklist Manifesto, a book that prescribes a disciplined adherence to essential procedures to prevent potentially fatal mistakes and corner cutting, here is a checklist to help you produce high-quality solution requirements:

• Write down a description of what customers are trying to get done (the "customer job"), expressed in their own words (e.g., file tax return, gather customer insight, track employee hours).

• List the undesired outcomes, risks and obstacles related to the customer job (e.g., become confused by tax forms, lose credibility if customer privacy is violated, time-consuming process to enter employee time).

• Describe what outcomes and benefits your customers want (e.g., minimize tax liability and aggravation at tax time, improve the quality of promotional campaigns, efficiently track project costs).

Only after collecting the answers for these first questions you should move on to the next steps:

• Ask yourself what type of solution might help your customers avoid the undesired outcomes and gain the required, expected, or desired outcomes and benefits (e.g., replace tax forms with automated extraction of information from documents, provide marketing with the ability to create contests and sweepstakes to entice customers to provide personal information, automate the calculation of upcoming and previous employee time off to reduce the manual work).

• Validate your findings, confirming with your customers that the problem or pain point has been correctly identified, and the proposed solution is capable of producing the desired outcomes.

Follow this script at the beginning of your requirements discovery process, and you should see visible results in terms of the quality of your solution requirements. This checklist will help you anchor any and all discussions about features and designs on how they will help your customers achieve their desired outcomes and benefits. It will also allow you to define a valuable, usable, and feasible solution without having to rely on your customers being able to describe it for you.

References/Footnotes:

(*) The term "customer", here, applies both to an external customer who buys products or uses services from your company, and an internal stakeholder who will use the solution or is affected by it and must be consulted during the requirements discovery process.