I'm the PM for a ML team... Now what?
As AI adoption increases, there seems to have been an uptick in product managers focused on machine learning science work. There doesn’t seem to be much content available on this subject, so wanted to put down some thoughts. I’ve been the product manager for three different ML science teams over the years. The first time I served in this role, there was a lot of trial and error, some of which could certainly be avoided.
ML/Science Teams are Different
The first big thing to know is that being a PM for a science team is very different than working with a feature team.
Their timelines can be very long and more open-ended. Some projects can last over a year without many agile-style deliverables.
Not every project works out. Sometimes there’s research with a hope to finding a particular approach or making a breakthrough, and it just doesn’t pan out. This is expected, but makes it different from feature teams, where finding that something is not doable at all usually doesn’t happen.
There’s an important translation layer across teams. The value of science exploration isn’t always immediately obvious, though the impact can be extremely high. This means that more communication legwork is needed to ensure that stakeholders across the organization understand the potential benefits and how they will be realized. Also, additional development work is often needed to productionize science work once the results have been achieved, so detailed involvement with the relevant feature teams is also important.
The upshot of all this is that the science PM plays a key role in ensuring the considerable value of science work is realized, and that their work doesn’t disappear into an expensive black hole.
How to Get Started
Get the Lay of the Land
If you're new to product managing science teams, here's where to start:
First, talk to your organization’s leaders, and understand what "valuable" looks like to them. In my experience, value is typically measured in two ways:
New products or features: Did the research result in a sellable new feature?
Improved quality: Did the work enhance the overall product quality or make it "smarter"?
Then, engage deeply with the science team. Learn what they're working on and why. You don’t need to be technical to do this, but you do need to ask good questions, be an active listener, and demonstrate the value of a non-technical perspective. For example, if someone explains an architecture to you, come back with a diagram of it. This will allow you to check your understanding, and you will have produced a valuable communication artifact for the rest of the team. Similarly, if someone explains something to you, produce documentation that benefits the team and the rest of the company. Make yourself indispensable to the team and their stakeholders.
Once you understand what is going on in the team, categorize the work into foundational research versus product-focused efforts. Understand, in a deep way, how the team feels their work will benefit the organization and what needs to happen in order to realize that value. For foundational work, this path might be long and the value less clear. For product-focused work, the path should be straighter. For every project, ask a lot of questions and try to really understand the value and how you can champion it across the company.
Once you know what all the projects are, you can start working through the roadmap…
Build a Research Roadmap
Once you have this information, you can start building the roadmap. Make it outcome-focused with clear milestones, rather than strictly time-boxed. Ask yourself: What's the desired outcome of each project? What process are they following? What are the critical decision points? What needs to happen for the work to land in the product or benefit the platform/team in some way?
For each project, create a research plan. This helps everyone understand the project's trajectory and goals. A good research plan includes:
A clear statement of the research goal
Breakdown of milestones (decision points, not deliverables)
For example, in a project aimed at improving unstructured data parsing, your plan might look like this:
Goal: Improve parsing of a special kind of unstructured data into tables
Milestone 1: Investigate parsing options - we will do experiments A, B, C, and D and then reassess.
Decision Point: If we can't find an approach meeting our criteria after these 4 experiments, reassess and possibly abandon. If successful, move to next phase.
Milestone 2: Develop streaming table population method for the parsed data... and so on.
Doing it this way will allow you to report on the overall plan and on the outcome of each experiments during your stakeholder update meetings. It will make the work more concrete and allow everyone involved to understand progress.
When balancing foundational and product-focused work, I aim for about 70% product-focused. It adds value more quickly and clearly. However, this can vary. For teams working with very new technologies, the percentage of foundational work might be higher.
For foundational research, it's crucial to map out clear milestones and benefits, and be very clear under what circumstances the project would be cut off, even if this isn’t easy to do. This prevents stakeholders from feeling like they're funding a black hole and helps the project from getting cut prematurely. Be prepared to explain the potential long-term value of this work and why it’s worth a more open-ended investigation.
Help Ensure Science Work Adds Value
One of the trickiest aspects of the science PM role is managing interfaces between the science team and the rest of the company. You need to maximize the chances of the outputs being useful. This might involve:
Coordinating early with other teams on how to incorporate the research into production software.
Educating others about the science team's work and its importance.
Telling great stories about the benefits and how they will transform the product or company to get stakeholders excited.
For example, I once worked with a science team that struggled to get their work into production. They'd complete research, pass it to feature teams, and nothing would happen. They were confused about this, because they knew their work was valuable and could have a meaningful impact to the bottom line. Talking with the rest of the team, it was clear that the understanding of what they were doing and how it would benefit was not widespread. Additionally, the code coming out of the science team was not production ready, it was in a different programming language, and it wasn’t clear enough how to productionize it. To address this, I first clarified the research objectives and provided more context to leadership and teams about what was being done. Then I worked with both sides to smooth the integration process by helping the science team write their code in a way that would be easier to move into the platform, and by helping the feature team plan the migration and build time into the schedule to get features into the platform. This reduced friction and accelerated the path to value.
If a project doesn't pan out as expected, communicate it promptly (you should be having bi-weekly or monthly check-in meetings with key stakeholders). As soon as you hit a failed milestone, inform stakeholders and either revise the research path or conclude the project. If you have set clear decision points and have been providing regular updates, this shouldn't come as a surprise.
Have Fun
Science PM work can be incredibly rewarding. You're not just shipping features; you're nurturing new ideas and bridging the gap between cutting-edge research and practical product applications. It's challenging, but when research successfully translates into product improvements or new features, it's extremely satisfying.
So, if you're stepping into this role, focus on clear communication, understand the value proposition of your research, and enjoy the process. Product
managing a science team offers a unique set of challenges, but it's also one of the most interesting jobs in product management.