I've recently spent an intense 5 weeks doing a programme discovery with a new client, my first "real" engagement as a consultant followed by an intense week of creating a prototype for an application that we might make for them. We then had a week of slightly less intense preparation for the delivery phase (I was officially on the beach that week) during which I had some interesting conversations with our BA and the client's product owner.
The main problem with our client's business seems to be that there is a difference between the value that is billed for and the value that the clients actually gain from the service. This difference is understood internally but what isn't understood is how best to articulate this value to the customer in a way that won't jeopardise the existing very lucrative revenue streams. Fortunately, the client is still very profitable and has therefore involved us early enough to make a difference. Our challenge now is to effect the digital transformation that reconnects the selling process, the buying process, the client's customers and the value stream in a way that is clearly understood and articulated.
This leads me to the discussion of the first MVP that we are looking at and the value hypothesis that we were creating together with the product owner. The initial stab at it essentially postulated that the customers did not understand the value in a tool that they are currently offered so we should make the tool easier for them to use. My immediate reaction was to suggest that the proposed solution in this hypothesis did not address the specified problem. Surely, I argued, if the issue is that customers do not understand the value of a product or feature, the solution is to articulate the value better, not to make the feature easier to use.
One of the things I've learned so far as a consultant is that it can be very useful to simplify complex things into simply understood dimensions or a couple of simple parameters. This enables us to frame a discussion in terms that everybody understands and helps focus decision making on what is really important. Obviously this isn't perfect every time and obviously deeper analysis can be required to differentiate things that end up looking similar but it certainly helps refine choice. We are all very fond of quadrants and simple diagrams to help focus on a part of some larger, more complex, picture.
We are also very fond of an analogy. Or at least the group of people that I work with are, I can't say if this is a standard trait of consultants. In any case, the conversation we were having got twisted round to a discussion of why somebody may choose not to drink a particular bottle of wine. This got me wondering whether there was an easy answer to the question of why people won't use a feature of a product. So why won't you drink this wine?
I prefer to drink beer. In this scenario, I understand the value wine delivers (it goes well with certain foods, it can help me get drunk) but I prefer to use an alternative product, beer, to get at that value.
I don't understand how the corkscrew works. I understand the value that wine delivers but the product is unusable to me because it is too complex.
I don't want to drink alcohol or get drunk. I don't see this product as valuable, I have no desire to drink wine or any other alcoholic product because I don't (and probably will never) value the features of this product.
I have never heard of wine or I've never tried it. I may understand the value of the product if it was explained to me or offered to me. At the moment I'm unaware of the existence of the product.
(I'm assuming you can afford the wine because we were considering free software).
Framing the discussion in this way helped us on the way to getting to a more coherent value hypothesis for our MVP. I'm not suggesting that these are an exhaustive list of reasons for people not using a feature and there are obviously nuances for each. It helped with our discussion anyway.
I found this post interesting while I was writing this.
Post a Comment