Once you put a piece of software out there in the market, its only a matter of time until a real paying customer finds an issue of some sort.

Obviously it would be fantastic if they didn’t find any issues at all, and the software was perfect in every way, but lets be honest, most software is unlikely to ever be constructed with the amount of rigour and quality checks required to ensure it never has a single issue.

Its just not cost effective.

So, the reality is that paying customers will probably find some issues.

How you handle those interactions can make a huge difference to how your customers feel about them.

A Loop Has To Start Somewhere, Right?

The best you can hope for when a customer discovers an issue is that they let you know.

This sort of behaviour should be heavily encouraged; that customer cared enough about the situation to let you know, and you want your customers to care. That’s a good emotion.

The first thing you need to do is acknowledge their contribution in some way; perhaps an email or a phone call to thank them for their time and effort. Anything will do really, but if its got a personal touch, all the better. If the issue was discovered during a support case then you’re probably already covered, but it can still help to send out some sort of summary stating that the root cause of their call was an issue in the software and that you really appreciate that they brought it to your attention.

Once an issue has been acknowledged it probably goes into your backlog.

This is an incredibly dangerous place, because its easy for things to disappear, and for the customer to lose sight of them. Its here that there is a real danger that the customer can become disengaged; they spent some amount of time and effort on the issue and they are probably personally invested in it, so if it disappears for some amount of time without any updates, they are going to feel disheartened.

So, even when an issue is sitting in your backlog its worthwhile to still keep customers informed. Granted, its pretty difficult to do this, especially if you’re not actively working on their issue (limited time and energy, hard decisions have to be made), but I prefer an honest and open discussion to just going dark.

Speaking of going dark…

Or Maybe It Doesn’t

Historically, for our legacy product, we’ve haven’t had much of a system, or perhaps whatever system we had was completely invisible to the development team, I’m not sure.

As far as I know, customers would lodge support cases and those cases would result in a stream of bugs being logged into system. The prioritization process was pretty ad-hoc, unless a particular customer made a bunch of noise, or something happened repeatedly and we twigged onto a greater pattern.

That’s not to say that we didn’t care, because we did. We just didn’t have a particularly good process that kept our customers in the loop.

In the last few months, along with the formation of a dedicated maintenance team for that particular piece of software, we’ve taken the process that we did have and improved it. Its early days, and we’re still tweaking the improvements, but we’re hopeful that it will make a difference.

We now have a much better triaging processes for support cases to classify them as a result of an existing bug or a new bug (or something else, like user error). This happens mostly as a result of a daily standup we put in place connecting the support team with the maintenance team. Additionally, whenever we identify that a case was related to a bug, we link it in our tracking systems and we also contact the customer directly and thank them for helping us identify a problem.

This ties in nicely with what I think is the most important improvement that we’ve made, which is that whenever we make a release (monthly), we identify any customers that were affected by bugs we just fixed and contact them directly, letting them know that their issue has been fixed and thanking them again for helping us identify and resolve the problem.

Some nice improvements to be sure, but its all a bit manual right now, and the engineer in me is uncomfortable with that sort of overhead.

I think we can do even better.

Time Travel Is Hard Like That

I want to expose our internal bug tracking system to our customers, ideally completely publicly. Failing that, a system that is equivalent and feeds back automatically into the internal system, I don’t really mind how its done.

Mostly, I just want to reduce the overhead in communicating issues to customers and to give them a nice view into not only their issue, but all of the issues that we are aware of and how they are organised. For me, its all part of being completely open and honest about the whole thing.

Its not entirely altruistic though, as I do have something of an ulterior motive.

One of the hardest problems that we face is really understanding how many customers are being negatively affected by an issue. Sure, we have a bunch of business intelligence that we can use, but nothing is quite as good as a customer themselves identifying that X is hurting their ability to do their job. Our support system and the cases that it creates helps with this, but its not enough for me.

I want our customers to be able to vote for their issues themselves, and then use that information to help make decisions.

Of course, I’m assuming customers care enough to participate, which might be a bad assumption, but I won’t know for sure until I try.

There are a bunch of things to be careful about, obviously, like exposing customer information. We often attach customer reports and other pieces of information to bugs in order to help diagnose them, so that could lead us to a world of hurt if we don’t handle it properly. There’s also the slightly lesser risk of making comments or changing the words in the ticket to not be “customer friendly”, which is a nice way of saying we would have to be constantly and intensely aware of how we present ourselves, even in an apparently internal system.

We’re pretty good, but lets be honest, sometimes people can be very frustrating.

Conclusion

The root point here, ignoring the potentially insane dream of exposing all of our internal bug tracking to our customers directly, is to ensure that your customers know what is going on.

This shouldn’t be a hard position to take, but it can be difficult and time consuming to actually accomplish. As always, a legacy product containing a bunch of known and unknown issues makes everything harder than it otherwise should be, but its still a tenable situation all the same.

At the very least the one thing you should keep in mind is that there is nothing more dangerous than complete radio silence.

That silence is very easily filled up with all sorts of terrible things, so you might as well fill it up with facts instead, even if they might not be the facts that your customers want.

Like that the only thing that you know is that their issue mightbe fixed sometime between now and the heat death of the universe.

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.