On Researchers and Product Discovery

Hello everyone! Welcome to another edition of the From Founders to Builders newsletter.

Today, I'm jotting down some thoughts on Product Discovery.

The Emerging Landscape of Product Discovery

Product Discovery has been on everyone's lips lately, especially in the product world. Conferences, events, and even there specialized coaches on the topic now.

Authors and content creators are writing about it, and courses are offered to dive deeper into the subject. But we, researchers, sometimes find ourselves watching this from the sidelines. The main reason isn't because researchers don't want to be involved, but often we are excluded or in some cases, pushed out.

There are plenty of product voices trying to vouch for researchers to be closely involved or oversee the process (thank you!) but I've also seen this being used as an argument for all the wrong stuff.

Product Discovery is inherently about understanding customers — something that research naturally excels at.

To me, there's no better place to discuss these developments than in a newsletter dedicated to research, which is why today I'm exploring how we as researchers can step up and become more involved.

Understanding Product Discovery

So, what exactly is Product Discovery? Also known as Continuous Discovery (as coined by Teresa Torres in her book), this framework is based on the idea that small teams — often called ‘trios’ or ‘squads’ — comprising product managers, designers, and engineers, should engage with customers on regular cadence.

Through this continuous engagement, they should start uncovering opportunities, identifying problems, and determining unmet needs or pain points.

Upon discovering these aspects, the next steps involve generating solutions, testing them, and then feeding these validated ideas into the product development process.

Sounds cool, right? Well, it can get tricky.

My initial thoughts on Product Discovery

As a researcher, I initially thought Product Discovery could pave the way for researchers in companies where talking to customers was minimal or non-existent.

When the topic started to get popular, some of the clients I was working with wanted me to help them out with the operational side of it, so we started discussing the matter.

I was glad to see that after some time running it, they eventually hired researchers after recognizing the value that discovery processes brought in.

However, the more companies I engaged with, this started to change and I started to notice that some companies perceived the implementation of PD as a replacement for researchers. Or as an excuse not to hire one.

"Why do we need research if we can have other roles talking to customers?". You know the drill.

This is not a critique of the theory itself, but of the people that try to hide behind a framework to justify crappy product culture.

The thing is, when you have people who don't know how to do research properly leading a discovery process, it can result in developing the wrong product, or worse, tarnishing the importance and reputation of research within an organization.

And then comes the ReOps bit.

Operational Challenges in Product Discovery

One of the main issues I've observed is the minimization of the operational aspects of Product Discovery, often assumed to be simple but are incredibly complex in reality.

Talking to customers every week?

PD theory states that teams should talk to customers frequently at a set cadence.

Some argue weekly, others biweekly, others even suggest other cadences. But it all comes down to the ability to digest and translate insights into actionable product decisions.

With a continuous inflow of customer feedback, can teams effectively implement these insights, or do they get overwhelmed?

The metaphor I like to use here is: do you eat even when you're not hungry?

Similarly, accumulating insights without the capacity to act on them can create data bloat without actual progress.

Plus, are you changing the script completely every week? Careful with the ol' "because one user said X".

Getting the right customers the right way

If you think getting customers to talk to is simply putting an intercept survey on your website or simply blasting emails like it's 2004, you're in for a surprise.

Identifying the right group of customers to engage with, adhering to strict regulations like GDPR and maintaining a consistent cadence of interactions is far from trivial.

Not only you need to get the right participants (otherwise, their feedback might not be relevant) but you also need to do it the right way.

Work with your legal team, put things in place, get the right consents, work on your incentivisation and reach out mindfully.

You need to properly set up your participant management if you want to gain momentum.

Managing the output

What happens after collecting feedback? How are insights managed? How are they stored? Or tracked? Are they documented properly? Do teams have an effective repository or just sporadic notes in various tools?

Oftentimes, teams don't think these operational details through, leading to inefficiencies and inconsistencies.

I've seen plenty of data lost along the way because there was no strategy in place.

Yes, the Opportunity/Solution tree should be a way to centralise this but from the sessions to the tree, sometimes there's a looong way.

Make sure you're tidy with your notes.

Quality and Consistency of Output

Another significant concern is the quality of the output gathered by non-research professionals.

If product managers or designers without research experience (or training, if you want) are conducting interviews, how reliable is the collected data?

There’s a risk of introducing bias, asking leading questions, and failing to reach data saturation.

I got tired of hearing questions like "Would you buy this for $10?" or "Do you like this feature?", which we know can lead to poor product decisions.

Triangulation, or validating data with multiple sources, is often insufficient, improperly executed or skipped altogether, which impedes the output to get "thick enough".

Not saying all PMs or PDs suck at research, but I've seen my fair share of people who haven't done this enough in the past, and all of a sudden they believe they can do it every week with 5 people and easily get good results.

The Myth of "Researchers Do Large Projects"

There's this conception that researchers slow down the process or are only suited for large projects that needs to be challenged.

As if PD went fast and in small bites and Researchers dived into the void to bring big revelations.

That's simply not true.

Researchers can tackle large projects, of course, but can also perform lightweight, rapid research without sacrificing quality, offering invaluable insights swiftly.

These are not antagonistic processes, they are complementary. "Sending researchers away" is not a very good idea.

The Way Forward

Overall, while I advocate for everyone in a company to be close to the customer, I believe researchers are the most suitable profile to lead or oversee any sort of discovery effort.

We don't need to be the only ones talking to customers, but instead, ensure we're doing things the right way and elevating the standards. We can even act as coaches or guides. The ReOps part is a blind side most teams have when doing this, there's so much potential there too.

If you are a researcher and your company is considering or implementing Product Discovery, get involved. Reach out and offer to collaborate, show the value that a researcher can bring to this process. Don't approach this with prejudice, but rather bring your best game.

Product trios, your willingness to engage with customers is great! However, take a moment to recognize the complexity of conducting meaningful research. Be humble enough to know when you need a researcher to ensure the insights you gather are actionable and reliable.

By collaborating effectively and recognizing each other's strengths, we can ensure that Product Discovery is implemented in a way that truly benefits the company and its customers.

It’s all about moving the needle together, making smarter decisions, and building better products.

Until next time!