This article was written collaboratively between Natasha Hampshire and David Spinks.
Like the words “product”, “value” and “MVP”, the term “product research” is often thrown around but means different things to different people. We have heard product research being described as:
- Something that only researchers do
- Something that requires scientific minds
- Something that is only done at the beginning of an initiative
- Something that happens separately from development
Let’s look at what each of these means for agile product development in a bit more detail.
Something that only researchers do
Research is about increasing knowledge, and so it shouldn’t really be regarded as a job title. Afterall, what good is acquired knowledge if it is only in just one person’s head? Gaining knowledge first-hand by seeing or experiencing something yourself is way more impactful than knowledge that is passed on second-hand. This is why the training classes that we run at Red Tangerine always include interactive activities for people to experience concepts for themselves.
When it comes to product development, we advocate involving as much of the product team as possible in research, whatever “specialism” they might have. This brings the benefit of sharing knowledge first-hand amongst the team and, not only that, we can leverage contributions from the diversity of perspectives, experiences and knowledge that the whole team has in carrying out the research.
A powerful example of this is when conducting a Design Sprint where a group of people with an array of skills and experiences come together to learn something by designing and testing a prototype in just a week. One of the reasons that Design Sprints can be so effective is because of the diversity and range of perspectives there is in the Design Sprint group as they collaborate, share ideas, and learn together.
Something that requires scientific minds
For many people, the word research conjures up an image of people in white coats working in a laboratory.
Research in product development certainly requires a systematic approach, some might say one that applies the scientific method. This is a means to the end of building understanding and evidence of things like our customers needs, their pain points and behaviours. Product development research very often involves learning about and empathising with other people, and as human-beings this is something that we should all be able to relate to, whether we are a trained scientist or not! When it comes to product development, emphasising the people-centricity of research and a culture of openness to the input from the whole team can help to dispel some of the anxieties that people have in getting more involved.
Something that is only done at the beginning of an initiative
In many product initiatives, research is seen as something that is done as an early phase to inform the actual development of the product.
Today, new technological innovations and changes in human behaviour happen in short amounts of time and the pace of change is only accelerating. In parallel, products have a lifetime, from when they are conceived, launched, to being enhanced and modified, all the way to their end of life.
Research to understand our product’s users and customers rapidly changing needs and behaviour should be continuous in order to carry out effective iterative development on the product throughout its life time. Otherwise, there is a risk that the product will soon go stale and reach its end of life faster than perhaps it should.
Something that happens separately from development
Very often, organisations have separate research teams and development teams. The research teams produce lots of content with really insightful information, only for these goldmines to go into a repository and be forgotten. A smooth transfer of information from the research to the development team rarely happens, with the development team often working off of their own assumptions and being unaware of the research findings. Or when information is shared across these teams, the development team ends up ignoring it due to time pressures to deliver.
Bringing research and delivery into one team with a shared goal makes things much more unified. It creates much better transparency of information, better collaboration and a higher likelihood of better products that meet customers needs.
Conclusion
When it comes to product development research, great product teams do not see it as something that dedicated or scientifically trained researchers do. They involve the whole team in the knowledge discovery process and make it a continual endeavour as they develop and sustain their products.
These ideas can feel idealistic and unrealistic for some teams and individuals who struggle to see how this can work in practice. That is why, together with our Red Tangerine colleague Glaudia Califano, we published the book Mastering Collaboration in a Product Team: 70 techniques to help teams build better products to showcase the many techniques that product teams can utilize collaboratively in product development.
Don’t just take our word for it though. Scrum.org launched the Professional Scrum with User Experience and the Professional Product Discovery and Validation classes to train people in the importance of treating research as something that is an ongoing activity in product development and as something that the whole team can get involved in. The agile approach to product development research is becoming more and more vital to organisations when it comes to developing and sustaining successful products.
Feature image by Pavel Danilyuk on Pexel