0 Comments

If you’re building some sort of software that you intend to be used by real people, you should probably talk to those people as soon as possible. Preferably before you start building the software.

You might be pretty confident about your plans and direction, but in my mind its far more sane to validate your assumptions before you spend hundreds of thousands of dollars building something that nobody wants. Or even worse, that they only want a little bit.

Granted, engaging with customers directly is a different sort of challenge compared to software development, but I think its worth the effort.

I’m Kind Of A Big Deal, People Know Me

I’ve alluded to it in at least two relatively recent blog posts, but one of my teams is engaged in a project whose goal is to give existing customers the ability to use some of our new and shiny cloud features while continuing to use their older, more mature desktop software for everyone else on a day-to-day basis.

For me, the obvious first step is to talk to some of our existing customers and see if they are interested. Granted, some of them already use an equivalent third party product to do basically the same thing, but that’s no guarantee that they would accept our offering.

Now, I’m not sure whether or not this kind of early consultative customer has a specific name in the industry, but internally we’ve taken to calling them anchor/validation customers.

The core idea behind validation customers is simple; find a small set of customers that represent your wider audience and engage with them around the situation you are trying to improve. Once that representative sample of customers is happy with the new thing and are actively using it, then you’re probably in a good position to roll it out to a wider audience.

Luckily for us (and for this project) our legacy product has quote a large installed user base and we’re planning to offer an incremental improvement to the way they already work, so locating potential validation customer candidates isn’t too hard.

I imagine it would be a completely different story in a different situation.

60% Of The Time It Works Every Time

Actually gathering feedback from the validation customers is possibly the most interesting part.

Early engagements can be all words if necessary, but eventually you’ll want the customer to actually perform the workflow that you’re trying to improve for real. This can be a hard sell if you’re expecting them to do double the work for no immediate gain (for example, asking them to do all their normal work and then to do some of that work again in a different system), so be careful not to expect too much from the customer. Working prototypes help quite a lot here.

Having said that, even if you’re just shadowing them while they do their normal day-to-day activities, you’ll still learn an incredible amount.

There is one caveat that you should keep in mind though; don’t take what the customer says as gospel.

Most people when presented with a problem of some sort will start to solutionise it straight away. These customers may have been struggling with a particular workflow for a while and have probably given their chosen solution a lot of thought.

Its still incredibly useful information and you should definitely listen, but you need to focus on getting back down to what the actual problem is, rather than just focusing on the solution that they are presenting. Identify the problem or pain point and then let your team of smart people solve the problem.

And with that effortless topic transition, lets talk about the team.

I’m A Glass Case Of Emotion

Traditionally you’d probably have a product owner (or maybe a business analyst) doing all of the customer interaction, abstracting away the individual customers and providing a stream of curated feedback to the team.

To be honest, this is probably the most efficient structure in terms of pure time spent interacting with customers and gathering feedback, but you do accept a risk of having everything come through one person.

This time I wanted to try something a little different, and while each validation customer has a dedicated contact within the team (so they always have a familiar face), its not always the same person for every single customer. Additionally, and most importantly I think, that person is not the only one that visits or observes the customer to gather feedback.

At some point, every single member of the team will go visit a customer, probably multiple times.

This approach provides a wealth of qualitative benefits, but the main one is the generation of empathy with the end-user. Its hard not to empathise with someone when you’ve literally been out on the road with them while they are doing their job, and this affects everything you build from that point on.

The only downside that I’ve noticed is that the customer interaction can be quite mentally and emotionally exhausting, compared to the normal run of the mill software development process. Some people will take to it like a fish to water, but not everyone is the same, and you need to make sure that you leave enough space and downtime for them to recover, to prevent them from getting burnt out.

Conclusion

At the end of the day getting a team of software developers to interact with customers directly can be a scary thought for some, both from a leadership point of view and for the developers themselves.

I don’t think its as scary as anyone makes out though, assuming you trust your team to interact appropriately with the customers and you give them at least a modicum of coaching on good practices.

The only unfortunate thing about the whole process is that it is incredibly difficult to definitively measure the positive effect of customer interactions, as the benefits are almost all qualitative. Sure you’ll probably deliver a better, more successful outcome, but there are hundreds of factors that could have lead to that success. How can you pin any of it specifically back down to “we engaged with representative customers early and frequently”?

I think the the key part is getting that core set of validation customers to use whatever you’re building for real. If you manage to put something together and they pick it up, assuming they were a good representative sample, you can probably directly link the success of any subsequent rollout back down to those early engagements.

The whole empathy generation thing is just icing on the cake.