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:

Example 1 (External Customer) - Software for Filing Tax Returns

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.

Example 2 (Internal Customer) - Software for Gathering Market Insight

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.

A checklist to help you stay on the right track

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.

Author: Adriana Beal has developed a successful career in business analysis and product management, having conducted investigation of business problems, defined winning solutions, and written requirements documents for a large number complex software projects. Her most recent ebook, Tested Stakeholder Interviewing Methods, was designed to help BAs get the critical information they need to specify high-quality solutions. She is also the coach of Crafting Better Requirements, a program that has helped hundreds of business analysts improve their requirements documentation and communication skills, and the author of Measuring the Performance of Business Analysts, an ebook that has been adopted by dozens of BA managers interested in improving the performance measurement systems in their organizations.


(*) 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.

Like this article:
  27 members liked this article


Putcha posted on Wednesday, March 16, 2016 11:41 PM
Adrian: The title of your article attracted me, then I got to know you wrote it. I was irked by the phrase "solution requirement" which means "what solution requires".

The content of your article rightly talks of "Business Requirement" which is a statement, in business vocabulary, of what the customer wants (needs) and also what the customer wants or has to avoid.
I am glad to find that your article rightly avoids taking about solution.

Solution is something that will evolve later with the joint participation of domain specialist and technologists.

By the way this is precisely what the Quality Gurus Deming and Juran advocated and refined through Quality Improvement Tools and Methods (their exact phrases are different). I am trying to figure out what is new in your proposal.

New or NOT what you wrote is worth practicing using some of the details of Quality Gurus.

Best wishes,

the implication that the BA would
Adriana Beal posted on Saturday, April 23, 2016 8:01 PM
@Putchavn: Good to see you here!

The disagreement about terminology around "business requirement", "solution requirement", etc. is old and doesn't look like will be resolved any time soon :-).

I think I'm in a different camp than yours regarding "solution requirements". A BA has to navigate the 2 spaces: the problem space, and the solution space. Business requirements are meant to clarify the need, whereas solution requirements is about communicating what capabilities the solution needs to have in order to meet the identified business need.

This is different from design (functional design, user interface design, technical design) -- all aspects that I agree with you will help shape the solution and evolve with the participation of domain specialists as you describe.

Thanks for leaving your comment!
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC