Making Product Discovery Work in Small Teams

If part of your job includes customer research, chances are that you are spending a big chunk of your time convincing other people in the business that the research is important, or is as important as other areas of product development.

This normally happens in organisations that do not understand how research actually works or identify the budget constraint that forces them to prioritize more “tangible” activities.

On the one hand there are big expectations that some magical insight coming out of the research will drive the product forward, while on the other hand there is a fear that “doing too much research” may slow things down.

The tension between unrealistic expectations and lack of internal support makes product discovery harder than it should be.

The lack of understanding around research outcomes also pushes teams to work in “bursts of research activity” as opposed to executing continuous research.

In this context, research is done only when it is perceived as needed, which more often than not means justifying the decisions they have already made.

The need to validate our decisions as opposed to challenge them may be just another consequence of thinking that we know everything we need to know about our customers.

This notion that we are the experts is often the very first obstacle in the way of truly learning from them.

As Chris Jones explains in his article Product Discovery: Pitfalls and Anti-Patterns:

Discovery is about finding an effective solution to a problem. Unfortunately, many teams set it up as a mechanism to simply validate their pre-existing ideas.

Sometimes this is easy to spot, as when Discovery is used as a rubber-stamp to validate the ideas the team is already committed to. Here, the team pushing a solution through while at the same time appeasing those questioning whether the solution was informed by real customer needs.

One of the many problems with sporadic research activities is that we miss out on one of the biggest benefits of research work: incremental understanding.

We are more likely to develop deeper layers of knowledge as we continue to ask more and better questions about what we are trying to understand. In this case, our customer problems.

You can only connect the dots if you have enough dots to connect.

Understanding customers’ problems is about pattern recognition. Patterns are not created from a single data point.

Patterns, by definition, imply multiple data points over an extended period of time. One-off research projects very rarely lead to meaningful insights.

It is the continuity in the search that leads to real discovery. As Dan Brown, author of Practical Design Discovery puts it, it is the journey:

I call this discovery, because it’s as much about the journey as what you find along the way. And, ultimately, it’s about uncovering information, and understanding why that information is important.

Learning doesn’t follow a specific process, and the term discovery doesn’t imply a particular string of activities. It doesn’t imply that some information is more important than other information.

What we learn about the target audience is important, but no more or less important than what we learn about technical infrastructure, branding guidelines, or operational constraints…I realized something about discovery: it’s not a specific process or artifact.

It’s not a phase or methodology. It’s not a school of thought or design framework. Discovery is an attitude.

This attitude is one of constant learning, letting information marinate in our brains long enough to start making new connections, enough to start asking better questions.

Paradoxically, this deep sense of understanding is what can lead us to assume we know everything we need to know about customers.

The key here is to continue challenging what we know.

I’ve always found helpful to think about learning from a compound effect perspective. The more you learn, consistently over time, the higher the gains.

The question is how do we create and nurture an environment where product discovery done right can exist?

Every organisation has it own unique challenges, but in my experience there are three areas that can help build the trust and support research work needs to thrive, especially in small teams.

Reporting on and during the process not only on the outcomes

How we get to insights is as important as the insights themselves. I’ve personally worked in teams that will proudly announce what research they were planning to do, go radio silent for weeks, and then report on the results in a very concise summary of findings.

This puts the rest of the business in a passive position, you want to involve people as you are developing the research. That may mean generating small updates on Slack as you go, telling stories about your latest interview with a customer, sharing screen grabs of a testing session.

Exposing the team to the research activities in small chunks help them get involved with the research story and be more interested in the outcome. Help them follow the story, don’t just tell them how it ended.

Documenting the thought process

Being able to clearly show how the research work has affected the team’s thought process over time can be a powerful way to highlight the importance of continuous discovery.

For example, in our team at NomNom, we use Google Docs to record our thinking and rationale behind the ideas we are proposing.

Sometimes the documents are discussions about JTBD, sometimes we discuss ideas about features, or technical problems. We invite the dev and product teams to those docs and everybody engages in that discussion.

Those docs are messy and that’s okay. What is important is that we can look back at them and understand why we made certain decisions in the past and how our own understanding of the problem has evolved.

Looking back at those docs can be a cringe worthy experience. It may feel like reading your own journal from when you were a teenager, and that’s also a good thing. It shows you how the team has evolved in their thinking and execution.

Treat it as habit

Executing continuous research is hard.

You have to find candidates, get the resources, get access to data, try different tools, do the whole documentation process we discussed above, manage the team expectations and all the admin around analysing, validating, and sharing insights.

This can feel like a huge amount of work, especially when it is not your full time job. Being part of a small team, I find scheduling specific times during the week for research, helpful. Tuesday mornings are about customer interviews, Wednesday afternoon is about analytics, etc.

Creating small chunks of research that happen on an ongoing basis is a good way to not only build the consistency and resilience that you need, but to also keep an open mind to new insights.

At NomNom our process is far from perfect, but as we continue to implement new ways of capturing our discovery process and most importantly, collaborating on it with the engineering and product teams, we continue to capitalize on our understanding of customers and on the confidence that comes from making decisions on a well researched problem.

I would love to learn more about how you make product discovery work for you and your team. If you want to learn more about NomNom, please visit us at nomnom.it.