Bridging the Product & Research gap – Part I: Demystifying Product for Researchers

February 04, 2025 Published by Henrik Lindström

About the author: Henrik Lindström is a Principal Product Manager, currently serving as the Product Lead for the Personalization Tech Research team. He began his Spotify career as a software engineer in 2011 but quickly transitioned into product management. Over the years, Henrik has taken on a variety of leadership roles, including several years at the helm of the Spotify Search team, where he played a key role in shaping user experiences and driving innovation.

Developing innovative products play an essential part of Spotify’s success. This is true for many companies in the tech industry, and as the term R&D indicates, it is about combining Research and Development or Product teams. There are many success stories of how Research has been transferred into product. To mention only a few recent ones from Spotify, we have leveraged graph based models to propel audiobook and podcast recommendations, auto-generated podcast chapters, and contextualized recommendations using fine-tuned LLMs. However, talking to folks in various organisations, finding an effective set-up for how to work across research and product teams remains a common challenge.

Last year I started a new chapter as Product Lead for the Personalization Tech Research team. We are organized as a central team of Research Scientists, aligning with a wide range of product teams to drive impact. In my previous role I was product lead for one of those teams. Having experience from “both sides” gives me a unique perspective on how to strengthen collaboration between product and research to achieve even greater outcomes.

This is the first of two blog posts where I will explore this topic, starting with demystifying Product development for Research Scientists. I’m also arguing that researchers should treat their research as a product with product teams as their customers.   

Product and Science Mindsets: More Similar than You Think

At its core, a product mindset has strong similarities to a scientific one. In fact, Product Management and development seen through a scientific lens – a common analogy for the role – is about continuous experimentation and hypothesis testing. Both involve a shared focus on solving complex problems, and reducing uncertainty. In addition, both require a foundation of curiosity, and grit to drive impactful outcomes. However, key distinctions exist in terms of how these mindsets are applied:

• Focus: Researchers often go deep into the “how” of a problem, seeking to understand its fundamental nature. Product teams, while valuing this understanding, prioritize the “why” and “what” – e.g. what solution will best meet user needs and business goals?
• Outcomes: Researchers strive for solutions that are technically sound and innovative. Product teams seek solutions that are desirable by consumers and viable for the business.
• Delivery: Research can culminate in technology transfer, sharing knowledge and findings sometime feeding into the future roadmap. Product development focuses on delivering products that customers can use and benefit from, where technology is one of many aspects.

Similarities and differences between a Product and Research mindset

To bridge the differences that do exist, I will next give a primer on two frameworks for product strategy and development: Good strategy/Bad strategy, and how to think about Risk in Product discovery. I choose these two because they are commonly known and used in the product community, and thus serve as good entry points. That said, there are many methods and frameworks, and what works best will depend on the team and situation. 

Product Strategy: Getting to the Why

In the realm of product strategy, Richard Rumelt’s book Good Strategy / Bad Strategy is considered a canonical text, widely adopted within the product community. Rumelt introduces the concept of the “kernel of a strategy”, which consists of three key elements: (1) a diagnosis, (2) a guiding policy, and (3) coherent action. The diagnosis serves as a problem statement, clearly defining the nature of the challenge at hand. The guiding policy acts as a hypothesis, outlining the approach to address the challenge. Finally, coherent action encompasses a set of solutions designed to execute the guiding policy effectively. Just as in research there is no exact formula, but Rumelt identifies these as essential ingredients of a “good strategy”.

What does this mean for research? Understanding the “kernel” of what Product is trying to achieve, will help make sure the research is addressing the underlying problem, and make it easier for Product to see the connection to “their” strategy.

Product Discovery: Unpacking the What

Another core aspect of Product Development is to articulate what product will help drive the strategy. This is called product discovery, and it’s about exploring and defining various solutions. I will not go into ideation techniques, and refer to design sprints and thoughtful execution as good places to start. Once we have a few potential solutions, how might we derisk building the “wrong thing”, or later realize it cannot be scaled? In his book Inspired, Marty Cagan articulates key types of risks that any new product being ideated and developed on should consider, making sure to tackle the biggest risks up front: 

• Value Risk: Will customers find the product valuable enough to buy or use?
• Usability Risk: Can users easily understand and interact with the product?
• Feasibility Risk: Can the product be built with available resources and technology?
• Business Viability Risk: Does the product align with the company’s overall business strategy and goals?

Tech Research at Spotify often plays a critical role derisking feasibility, contributing with expertise around existing technology and researching novel solutions. But what if we applied the dimensions of Value and Usability Risk to the research itself?

Looking through the lens of the Product team being the customer, we can reformulate the risks as follows:

• Value Risk: Will customers Product teams find the product research valuable enough to buy or use?
• Usability Risk: Can users Product teams easily understand and interact with the product research?
• Feasibility Risk: As mentioned, this is already at the core of what research at Spotify does.
• Business Viability Risk: The business risk remains the same.

In this sense, research is a product with Product teams as customers and users. Treating it as such might help increase the chances of getting the PMs attention, and ultimately to bring the research to benefit the users, creators, and the business.

Key tactics for Researcher-Product Collaboration

Finally, I’m leaving with six tips that can help researchers improve their collaboration with Product developers. These are based on my personal experience from many years of having worked across  research and product development.

• Start with the Why: Clearly articulate the problem the research addresses and why it matters to the business.
• Connect to Existing Problems: Align the research with the challenges the product team is currently facing.
• Speak their Language: Use terminology and metrics that resonate with the Product teams.
• Reduce Complexity: Present findings in a clear, concise, and actionable manner.
• Timing is Key: Be mindful of the product team’s priorities and timelines.
• Show, don’t Tell: Demonstrate the potential impact of the research through prototypes or demos.

Research continues to play an integral role in the success of Spotify, positively impacting users, creators, and the business. This is only possible through strong relationships and effective collaboration between Research and Product. We are constantly learning and evolving how to do this well. In this blog post, I explored an additional step in this process – by embracing a product mindset, Research Scientists can become more effective collaborators and increase the impact of their work. Remember, research is a product too!

Thanks for reading, and stay tuned for part II, demystifying Research for Product teams.