Applied Research 101

In the last year, AI has come to the fore with incredible capabilities that are starting to find product use cases. From image generation to summarization, question & answering to code generation, billions of users around the world are starting to see the benefits of AI. However,? more application-driven research is required to build mature, safe and responsible products. This post is intended to provide a perspective on how to do applied research that can help accelerate the impact and benefits of these transformational AI systems.

Over the past 5 years, I have been involved in a variety of exciting research and product collaborations that include improving recommendations for Google Search, saving bandwidth for YouTube’s videos, discovering faster sorting and hashing algorithms, improving compiler optimizations, designing chips using AI and improving heating, ventilation and air-conditioning in industrial buildings.?

What is Applied Research?

As research scientists, our job is to develop novel research solutions to enable and accelerate progress in achieving a typically long term and ambitious goal. However, sometimes our job is to develop shorter term research solutions that enable or improve a product or a product feature. In the industry, we call this 'applied research’. However, this term can be confusing and means different things to different people.?

Through my experiences, I have come up with some rules-of-thumb ranging from how to interact with product teams to the do's and don'ts of Applied Research. I have come across many researchers that want to have real-world impact on products and I hope that this post can provide some insights that up-and-coming researchers can take with them on their applied research journey.?

I am also sure there are many different opinions on what it means to do "Applied Research", and I would love to hear anecdotes and ideas from the community. So please don't take this as my way or the highway :) This is a work in progress and by sharing learnings and ideas as a community, the hope is that we can accelerate progress and impact. In addition, this opinion applies to working in big tech, and I fully appreciate that this model may change when you consider startups, contract work and consulting, but hopefully there is some meaningful overlap.?

So let's begin this journey! I'd first like to share with you an incredibly important concept that I like to term the Research-Product fit.

The research-product fit:

What does this mean exactly? Well, let's start by thinking about startups. We often hear the term "Product-Market fit" where the general idea is to develop a product that is solving a pain-point or a need in a large addressable market. Well, the research-product fit is quite similar in that you want to find or develop a research technology that is capable of solving a pain-point or need in a particular product, leading to real-world impact.?

This can however have many different interpretations. For example, this could be improving the product's key performance metrics using a new research solution, adding a new capability to a product or enabling the development of an entirely new product.

But there is a lot more to the research-product fit than meets the eye. There are, in my experience, three key stages to establishing a research product fit. These include (1) identifying a product need or pain point, (2) establishing whether your existing research technology or idea can address this and (3) building a research roadmap to achieve this goal.?

So let's now break this down.

1. Identifying a Product Need or Pain-Point:

This is probably one of the most challenging parts of the project as there are two key points to establish. The first is to determine whether there is an actual product need or pain-point. The second, and most critical, is to ensure that this is of significant importance to the product team. There are a number of ways to go about this. One approach that is very effective is to ask the product team for their quarterly/yearly goals and objectives document. Different companies may use different names for this document. This contains a prioritized list of their goals for a given time period (e.g., next quarter, year etc). From this document, you can gauge both what is important to the team, and what their pain points are. The hope is that you can identify OKRs that can benefit from applying your research technology or idea.

Often there won't be an immediately clear fit, but if you have enough intuition or understanding of the research technology or ideas that you want to apply, you can usually find a key metric in a team's OKRs that you can hopefully improve upon. If you can't find a match, then it's often better to take your bags and run.... to the next product of course :)

2. Establishing whether the research fits

If you do establish that your research can solve a particular product pain-point, then you can move to the second phase which is establishing "head room" - no, not the amount of space below a roof, ceiling or bridge (an official Cambridge English Dictionary definition)! Rather, a means to gauge whether your research technology can improve upon the product's key metrics. This can be a very challenging endeavour for a number of reasons.

• Your research technology might not yet be developed
• Your research technology exists, but needs additional work to be applied to the product
• The product might require many approvals to be tested on a new idea
• The product infrastructure doesn't support your research technology

A very powerful way to determine whether there is “headroom” is to run a hackathon. That is, a dedicated amount of time whereby you can establish whether it makes sense to apply your research technology or idea to the given product. As listed in the bullets above, it is not always possible to implement your research solution/idea in this timeframe. In that case, it is often useful to try and identify sub-optimalities in the product which can give you more confidence that the headroom is there.

3. Building a research roadmap?

If you have identified a key metric you can improve upon from a product team’s key objectives/goals, have validated that there is headroom, then you are in a very good position! The next step is to build an applied research roadmap. This roadmap should have a vision, e.g., We aim to improve metric X by K% by the end of the year. Leading up to achieving this vision, there should be clear, well-defined milestones that you want to achieve. These milestones should ideally be 2-3 months long and the first milestone should be the most concrete. It is very common, even in applied research, for the research ideas/direction to change. That is why the first milestone should be most clear and concrete and the follow-up milestones should be high-level and flexible.

Now you have a research roadmap, you are on your way! In embarking on this journey, you are very likely to encounter individuals working in many different roles which include research engineers, software engineers, product managers, directors etc. It is here that the Do’s and Don’t become particularly important.

The Do’s:

• Understand the product deeply: It is very important to have a strong understanding and intuition for the product and how it behaves. Devote a lot of initial time to experimenting with the product, understanding the product codebase, analyzing the data, reading relevant design documents, understanding what has been done previously etc.

• Overcommunicate (especially in the beginning): Ensure that everyone is on the same page. This might mean meeting at more frequent cadences (maybe even multiple times per week initially), and ensuring that everyone is aligned. This is especially critical at the start of a project where many dynamics come into play

• Ensure you are aligned with the product manager: The product manager is responsible, among many other things, for ensuring that the product key objectives are being executed as planned. It is critical that the product manager has buy-in for your project, so make sure that you have sorted this out prior to starting the project. Touch bases frequently with the product manager to ensure that priorities haven’t changed.

The Don’ts:

• Don’t be too opinionated about a particular direction: When interacting with product teams, it is often the case that your research technology/direction needs to change/adapt to different product needs/requirements. Don’t plant your feet in the ground and refuse to budge. Rather embrace flexibility, which will make your interactions with product teams that much more organic and enjoyable.

• Don’t ignore engineering challenges: Whilst it might not be your job to solve engineering challenges, product teams often greatly appreciate any help you can provide here. Providing suggestions for solutions to these challenges, or even spending a little bit of time doing some engineering can build rapport and trust which can be critical down the line.

Well, that brings an end to your 101 on some best practices I have found to translating research into product impact! I hope this is useful and, at the very least, causes you to critically think about your ‘Applied Research’ collaborations. Please leave any feedback or thoughts. I would love to hear from you all!?