The product you built – after careful market and user considerations needs to grow and evolve over time this can and should be done in a bunch of ways, through different systems, and frequently. It is not enough to just monitor the complaints you get on your helpdesk and address them – do that – but you need to also get at the data that’s produced from what users are NOT doing, are NOT saying, and are NOT complaining about. Lastly, you need to understand the foot traffic – specifically those who are voting with their feet via attrition.
First thing – this is a lot; a lot of data, a lot of looking, a lot of considering where improvement is needed and why. This isn’t always a pleasant exercise but if you embrace it and lean into it, so to speak, you’ll gain a lot and keep more users for longer and that, afterall, is the point of this exercise.
Configuration meta data analysis.
If you can see what people have gone and set-up or implemented in their own accounts – whether they use it or not – you can get an idea of what their aspirations were, a sense of adoption drivers, and potentially where the product falls short. This is how the customer would like to use your stuff. Reality doesn’t always match up but it’s a valuable set of data that can drive your product, documentation and support. (Side note: the concept of configuration data should tip you off; collect configuration data!).
The issues that customers report relate to the features they are using, struggling with or would like improved. The more of this you can get, the better, but keep in mind – it is not the complete picture. The customers willing to write in represent a whole host of people that might just as soon abandon your service, workaround some annoyance or just give up. Look at both the complaints and the solutions your team provides (if they do). Eventually squeaky wheels need grease or it becomes distracting for everyone. (End to end support can also help mitigate a lot of these issues over time and smooth out the lifecycle of a user from adoption through implementation and configuration to user).
Functional data analysis.
What cutomers are actually using – activities, transactions … this will give you a reasonably good indication of what is actually being used. This is just an approximation though, so keep that in mind. Not everything results in a transaction/data event and failed features, frustrated customers, or opaque interfaces wont show up in the data. For that other stuff – you’ll have to ask them. Then take their answers seriously. Then with a grain of salt. Then put requests and complaints into a product feature priority matrix … etc. etc. If that sounds painful it’s because it can be. But users – they are your reason for living.
Looking at the reports customers set up and how often they are run will tell you what the customer thinks is important. Ad hoc reporting is also a valuable place to look for enhancements and usability improvements. You’ll gain valuable insights from seeing what customers bother to report on.
Make it a habit to ask your users about features – those they use, those they may or may not be aware of. Make sure you query all constituencies about what they use, why, how often. Don’t be disappointed by low return rates for surveys. Make it worth their while if it’s worth yours – a small incentive may be in order to enhance enthusiasm. If nothing else let them in on the results – there’s nothing more annoying than being asked your opinion and still feeling unheard.