advantage

A product rarely sells itself.  What sells a product is the advantage it brings and the benefits it delivers to the customer.  It is the benefit of the product that sells rather than the product itself. What is the advantage of the requirement you are stating, and what is the benefit it will bring the customer?

Let’s start with a product.  Think broadband.  It’s dull.  Put 10MB in front of it and it is still dull.

Now think about the advantage that 10MB broadband brings.  The advantage is that it is fast.  Lightning fast.

Now think about the benefit which that advantage brings.  The benefit is that you can download an MP3 tune in seconds rather than minutes with your old dial up connection.  You are no longer selling broadband, but the experience that it brings.

Let’s consider IT requirements to be products.  A dull list, a thick document gathering dust. How do you prioritise one requirement over another?  What is more important?

Agile introduces ‘stories’ as the requirement product.  They are written in the format ‘As a <role>, I want <a feature>, so that <some benefit is achieved>’.  It is the ‘So that’ which is usually the hardest part to articulate, yet it is the most important part of the story.

Liz Keogh describes how prompted by Chris Matts her preferred narative reads:

In order to <achieve some value>
As a <role>
I want <some feature>.

Applying the marketing thinking to how the story will “achieve some value”, don’t just define that value in the advantage it will bring, rather also consider the benefit it will deliver to the user.  The two are different.  There maybe a business advantage to delivering some feature, but if the benefit to the end user can’t be articulated, it’s real value must be questioned.