Business Analysts can Enable Innovation

“If I had asked my clients what they wanted, they probably would have said a faster horse.” — Henry Ford, Founder of the Ford Motor Company

This infamous Henry Ford quote is often mistakenly used to justify that we do not need to talk to our customers, because they do not know what they want or because they do not know what is best for them.

This thinking is essentially flawed.

If Henry Ford had had access to a Business Analyst at that time, he might have arrived at a better statement of the ‘real’ requirement, namely:- ​ ​

A medium of transport capable of carrying 100 kg of persons and goods a distance of 10km within 1 hour, without stopping for ‘food’.

Now, if you give such a statement to your engineering department, they will need to think outside of the box to reinvent the concept of a ‘horse and carriage’ that can meet those requirements.

It is this very thought process that may force them to create the concept of a ‘mechanical horse’. This is the basis of innovation.

The Business Analyst contributes to innovation by defining the requirements in an abstract way that focuses on the end-result, without specifying how the design or implementation is to achieve it.

Here is another example:

The bad requirement specifies how to implement the idea, whereas the good requirement abstracts away from the implementation details to focus on what we are trying to achieve, namely ‘to search’.

If we take the ‘good requirement’ to our IT department, they will be obliged to find a mechanism that can search effectively through an ‘infinite’ list of media items. Given some thought, they may come up the idea of a circle.

It is possible that this was the basis of creating what we know today as one of the most revolutionary changes in digital user interface design – the Apple iPod, which was one of the first digital products to introduce the concept of scrolling using a circular search mechanism. ​

On the other hand, if we had given the ‘bad requirement’ to our IT department, we would have stifled any attempts at innovation because the engineers would have been forced to work with a drop down listbox, which may not be as effective at allowing rapid search within a very large group of items. ​

Instead of an innovative product, we would have ended up with a real turkey of a product..! ​

Comparing Patent Claims to Requirements

So, even if you are convinced that writing requirements in an abstract way can facilitate innovation, how far should we go? Well, patent claims take an approach which is somewhat similar to writing requirements (although the end-result is protection of intellectual property, rather than solution development).

Let’s look at some similarities:-

So, do Business Analysts need training in how to write patent claims before being set loose on requirements definition? Not at all.

However I do believe that Business Analysts can learn from how patent attorneys build abstract and legally binding descriptions of products as patent claims in order to allow breadth (and therefore value) to the patent.

If only Business Analysts could write requirements in the same way. After all, when is the last time you saw a requirements document that would stand up in a court of law?

Conclusion

If Business Analysts are to enable innovation, we must learn to decode the wishes of our customers into abstract requirements that focus on what the solution must achieve but in a way which allows for multiple possible implementations.

This opens up the design space to ideas which may not have existed previously and hence fosters innovation, both within the multinational as well as for small enterprises.