Why won't you drink this wine?

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.

Becoming a ThoughtWorker

Back in April I left the company I'd been working for after 9 (mostly) happy years. Not entirely through my own choice, although redundancy ultimately didn't treat me too badly. After spending Easter with my two girls, running some races and doing some of the long overdue work around the house and garden (though not nearly as much as Josie wanted me to do), I finally got round to looking for a new job by going to the Silicon Milk Roundabout in May.

While trimming the firethorn I shouldn't have cut this brown "twig"

Like most people who work in the technology industry I had heard of ThoughtWorks. I knew they hosted a lot of community events, I knew they published the technical radar and I knew that they have a kind of elevated, almost mystical cult like status. I also was aware of a man called Martin Fowler who is "chief scientist" at ThoughtWorks and is considered a world authority on many technology subjects. Oddly, I had never really thought about how ThoughtWorks make money. So when I saw the ThoughtWorks stand at Silicon Milk Roundabout I initially walked past it reasoning that there is no way ThoughtWorks could consider employing me. After a circuit or two of the venue and with a much depleted stock of CVs (I was down to one) and a couple of beers to both deal with my hangover and give me some Dutch courage, I finally approached the ThoughtWorks stand and spoke to a charming lady called Amy. Thankfully, she was extremely helpful and human (although she did explain she was a recruiter, not a technologist) and after a chat about my experience, what ThoughtWorks do (we are consultants obviously) and some dire warnings about the possibility of having to travel for work she assured me that somebody from the London office would contact me shortly.

Many people have written at length about the ThoughtWorks recruitment process in blogs and on Glassdoor so I don't propose to add greatly to that canon. In short, I thought the process was challenging but very enjoyable and above all was superbly managed by the team here in London. I guess I would say that because it ultimately ended with me being offered a job but I genuinely got the impression that I would have been impressed with the process had that not been the result. Of course there is no chance of any kind of confirmation bias going on here contrasting ThoughtWorks recruitment with those rubbish recruitment processes that didn't offer me a job. Another well known consultant threatened to sabotage the whole process by offering me a job for a much higher salary the day after ThoughtWorks had confirmed an offer to me. I made what I considered to be the only sensible decision (and I've subsequently found out, the far from unique decision) to take the less well paid job.

When I started here I suffered from a strange and debilitating loss of confidence in my own ability compared to those around me. That also turned out to be far from unique and I quickly found out that this phenomenon is known as "imposter syndrome" and afflicts almost all ThoughtWorkers in their early time here. After a few weeks I realised that whilst I was far from the cleverest man in the room, there is always something that I know more about than the other people to whom I may be talking. Thus, whilst I may never aspire to the technical ability of some of my colleagues, I can point to a solid decade of experience in a company that grew from a startup into a large organisation and went through a complete Agile transformation.

So 3 months on from joining ThoughtWorks I'm over the imposter syndrome, I've made some great new friends, I've had loads of interesting and truly stimulating conversations, I've learnt stacks of stuff about technology and business, I've become integrated in the ThoughtWorks hivemind, I've been involved with some of our clients but I'm yet to write any code in anger. Definitely the most enjoyable and mentally invigorating three months of my working career to date. I'm hoping it only gets better.