In the field of customer or user research, when trying to answer the question “what is an insight?”, teams often end up debating whether something is ‘big enough’ or ‘significant enough’ to be an insight.
It’s often tempting to set some sort of significance threshold for all insights. That way your team and your organisation will always know what sort of information they need to gather to define an insight, and that the information recorded in your insight repository will be substantive.
Sounds good, right? Intuitively the right thing to do, but ultimately counterproductive, as it ignores the fundamental reality:
Not all insights are the same size.
What do we mean by ‘size’? At Qualdesk, we think that it’s helpful to see insights on a spectrum from tactical to strategic.
At the tactical end of the spectrum, we’re talking about insights that help us make decisions over a relatively small domain, in a relatively short time.
Tactical insights might include:
At the strategic end, we’re talking about insights that help us make decisions over a large domain and that take much longer to put into action.
Strategic insights might include:
You could think about these in terms of ‘size’ – tactical insights are ‘small’ and strategic insights are ‘big’ – but it’s helpful to look in some specific parameters in more detail:
If you think that the insight is going to lead to significant changes, you should invest more time in making sure it’s correct.
If the insight has relatively small scope or prompts action in a space where it’s easy to experiment, you’re okay with the fact that you might be wrong on the basis that corrections are easy to make.
By way of a trivial example, if you have a web app, and you make a button on a screen blue, it’s probably going to be fairly easy to make it green if blue proves to be the wrong colour.
On the other hand, if taking action on the insight is time consuming, expensive or reputationally challenging (e.g. pivoting a feature or product significantly), then you’re going to want to do more work to make sure the insight is correct before taking action. For example, if you decide to change pricing strategy and model for an entire customer segment, this is going to require both lengthy planning and implementation, as well as having pretty significant consequences if you get it wrong.
This determines how we might expect to develop the insight. This isn’t necessarily where the insight might be discovered, as the seed of a strategic insight might very well be from a single research session – but in order to build confidence in the insight you’d want to validate it over a longer period of time. Tactical insights can be picked up quickly; strategic insights take longer.
This determines how long we might expect the insight to remain relevant – a tactical insight is likely to expire more quickly due to its narrower scope, as once the action that it prompts is taken, it doesn’t bear relevance outside its original domain.
For example, if you discover that a particular screen layout is confusing to users of your mobile app, and then completely redesign the screen, the original insight has served its purpose and is now redundant.
A strategic insight on the other hand, may continue to be relevant for a considerable time, potentially for the life of the product or company. As a consequence, some strategic insights may be captured in design principles or brand values.
This distinction between different types of insights is fully supported by the molecular insights approach, where strategic and tactical insight molecules will likely consist of different types and numbers of atoms.
For example, you might expect a tactical insight to require a recommendation atom – a tactical insight may not be that useful unless accompanied by a clear recommendation for further action. On the other hand, a strategic insight might not require a recommendation, particularly in the early stages of its development, as there may simply be no clear further course of action to take.
The table below summarises this model. Remember that this is a spectrum rather than a binary definition, and that you and your organisation might want to define other types of between the two extremes.
|Tactical insight||Strategic insight|
|Domain||Specific – e.g. position of button on screen||Broad – e.g. cultural preferences of specific group of users|
|Validation process||Picked up in a small number of tests/experiments/sessions||Recurring theme over the course of a detailed study|
|Time/effort required to take action||Within the same or next sprint in a Scrum environment||Input into quarterly planning process|
To put this model into action, there are three steps:
Take a look at what you have already, both the things you formally define as insights as well as things on the fringes.
Remember that part of the purpose of implementing this model is to allow you to form a more holistic and inclusive view of what ‘counts’ as an insight.
Spec out their parameters, bearing in mind that commonality is probably a good thing here: you don’t want to be to end up with too many definitions.
This is where the molecular insights approach helps, as it gives you a set of atomic building blocks that can be re-used across multiple insight molecule types.
In your insight repository, classify the insights you have, noting any which fall short of your new requirements.
You might not want to discard insights that don’t make the grade – for example, a strategic insight that doesn’t have enough evidence to back it up – instead, you might want to turn that into an item in your research backlog.
Finally, we’ll talk more about insight lifetimes and expiry in a future post, but for now, we hope this model helps you define insights and manage your insight repository in a productive way.