At Qualdesk, the question we ask the question ‘what is a user insight?’ a lot. In a previous post, I touched on one aspect of that question: what makes an insight ‘big enough’ to be a real insight, and the spectrum of strategic and tactical insights.
In this post, we’re going to look at another dimension. What else is it that makes an insight an insight? At Qualdesk, we think that every insight must be:
Let’s look at each of these in turn.
An insight must be actionable forwards. Given that the reason for developing insights is primarily to take action or make decisions, an insight should encapsulate enough information to enable someone to do so.
This doesn’t necessarily mean that an insight should be accompanied by a recommendation or instruction – though in some situations that might be appropriate – but simply that the ‘consumer’ of the insight receives unambiguous and clear information, as part of the insight, to guide what they should do next.
For example, at the more strategic end of the spectrum:
and at the more tactical end:
As you can see, the scope, scale and implementation time for these actions might vary immensely from one insight to another.
Most teams do a pretty good job of making insights actionable. It’s also pretty easy to tell at a glance when looking at an insight that’s been sent to you – perhaps in an email or deck – whether or not it’s actionable. We believe that it’s the responsibility of the researcher or researchers to make sure that the insights they develop are actionable at an appropriate level.
But why does the insight molecule need to be actionable? Why couldn’t the person on the product team responsible for taking action simply have a conversation with the researcher to figure out what to do next?
The simple reason is speed of execution: the shorter the time between insight generation, insight consumption and action, the quicker the team as a whole can learn and experiment. If insights aren’t themselves actionable, this introduces a delay between insight consumption and action – there needs to be a loop back to the insight generator first.
Why do we need insights to be traceable backwards? And what do we mean by traceability? Think about tracing an insight all the way back to the raw data that you used to generate it.
All of this allows someone viewing an insight molecule to see – or check – where it came from. This provides your team and the rest of the organisation either to reaffirm their belief that the insight is correct (hopefully) or to understand where it might have started to fail.
For example, some of the evidence backing up the insight may no longer be relevant or true, or some of the interpretation based on a set of assumptions you no longer believe to be true.
This isn’t a problem – in fact, it’s ultimately hugely helpful. By packaging insight and evidence together in the same molecule, you make the lives of those looking back at the insight in future a lot easier. Caroline Jannett at Effortmark has written about this in more detail in her post about research debt.
To return to our original question: what is an insight? — among other things, an insight should be both actionable forwards and traceable backwards. This increases the likelihood that:
In a future post we’ll examine the second point in more detail and look at insight expiry. For now, making sure that your insights have both of these attributes will help you and your team to work productively with the people who depend on the insights you generate.