You’ve read The Lean Startup and you know about the concept of the Minimum Viable Product. You practice customer or user-centered design in your team, and the organization you work for has a strong design culture. Sound good so far?
But what about the impact of research on the product itself? Does what you discover change the path of the products your organization builds? Does it influence strategy?
If not, it’s time to take stock.
Let’s take a look at what sometimes goes wrong:
None of these are disasters, but they result in spending too much time doing research that might produce useful insights, but not the most useful insights. And the relationship between research, product and engineering starts to suffer.
Let’s look at each of these in turn.
Imagine a scenario:
Research uncovers new information or insight about customers.
This insight might:
In these situations, the research plan itself should also be questioned.
If we continue with this research as planned, will it help us resolve the biggest areas of risk or uncertainty? Or – have we discovered a bigger area of risk or uncertainty that we now need to turn our attention towards? If the latter, we should stop and take time to re-plan our research.
But that so rarely happens, and so time is wasted on research that might produce useful insights, but not the most useful insights.
In many situations, it’s easy to want to do more research – to avoid making a tough decision, or because the previous research didn’t yield conclusive results. Or perhaps there was a question that came up that you didn’t quite have time to explore fully. Doing more research means that you learn more, which is always a good thing, right?
If you’ve already learned enough about your big assumptions, further research in adjacent areas may not help much. And if you’re delaying researching Assumption 2 because you’re working around the periphery of Assumption 1, this can be dangerous. Again, you might be producing useful insights, but not the most useful insights.
This situation typically either as a function of team structure, or the value that the organization as a whole, places on research. Neither of these are particularly easy to change.
If research is focused too much on tactical concerns, there’s a risk that it simply isn’t answering bigger questions. This is probably okay with relatively mature products or services, but is likely to cause problems otherwise – and even in the former category, who can predict an externality like a competitor launch or regulatory shift?
Make sure you’re at the right ‘zoom level’, and that you and your user research team are spending enough time ‘zoomed out’.
Sometimes this is difficult if product leadership keeps pushing you back to the detail, and so you might have to break out on your own to demonstrate the potential of looking at the bigger picture. But beware of the fourth scenario:
This, thankfully, is increasingly rare. Product, engineering and research teams are often very closely connected.
As a researcher, remember that your role is in service of the product. Or to put it another way – if your research isn’t having an impact on product decisions, unfortunately something is wrong.
If this loop is broken, fixing it often requires intervention from leadership. It might point to a broader cultural problem with research in your organization.
But it can also be re-kindled by bringing product and engineering decision makers closer to the research itself — closer to the user.
If you can restore empathy and proximity to users among that group, you’re more likely to be able to land your key insights in an impactful way. If this succeeds, the quality of product and engineering decision making will improve.
These scenarios are, unfortunately, hard to detect. That’s partly because doing research itself feels like the right thing to do. In none of these scenarios does research stop. It just isn’t as impactful as it could be.