Goal-based requirements

A new way of talking with users

“If I had asked people what they wanted, they would have said ‘faster horses’.”

– Henry Ford

The dialog around requirements in the software industry today is broken. Generations upon generations of developers are brought up to ask the question “what do customers want?”. The question is so problematic it should better have not been asked in the first place.

What is wrong you are asking? Well, for starters customers (or, better, users) more often than not do not know what they need. Notice, I did not say “do not know what they want” but “what they need”. They might often know exactly what they want, but this knowledge is almost never detailed enough at best and very often downright wrong. Learning the needs of users is an incremental process experienced both by users and solution providers. Users gain insights into what they really need only after laying their hands on a working solution and playing with it for some time. The requirements that come based on that real-life usage experience are much more valid. After these are in place, another learning cycle is happening with the new features implemented and so on.

The second problem is that often implementations of requirements, particularly if those are well-defined, turn out to be effort-intensive and yield to a 80-20 (or even 90-10) principle. This principle implies that if only the requirements could be changed slightly a major effort (and risk) could be shaved off. However, more often than not the delivery teams take the requirements word for word. Some teams do have a negotiation phase with their customers, which is a good step forward. In agile this often happens at an iteration planning meeting where a customer or a PO are present and can make these decisions.

The third problem stems from the fact that a requirement is no more than an approximation of a solution to a customer’s need. And the need (or even the goal) is what we are after. Scrum took a first shot at this with its “As a <> I want <> so that <>” User Story template. It is precisely this “so that” clause that tries to address the initial user’s goal. Teams need to go even further and ask “what problem a user is struggling with that this requirement is trying to solve” – then propose a solution.

As a direct conclusion from these points we could think of something we can call a “Division of Problem Ownership”. In this divide users only own goals they are trying to achieve and difficulties they are struggling with, while delivery teams own the requirements themselves. In this way the delivery teams can be flexible enough to make right economic choices, where cost-effective requirements are formulated while still addressing user’s goals and pains.

By the way, another huge benefit of this mode of work is that delivery teams have a lots of room for innovation when generating the requirements.

Leave a Reply

Your email address will not be published. Required fields are marked *