How AI PMs Work with Applied Scientists: The Collaboration Guide That Actually Works
TL;DR
Applied scientists and ML researchers are among the highest-leverage people you will partner with as an AI PM. They are also the most likely to feel like they are building something different from what you are building, until you learn to speak each other's language. This guide covers the structural tensions that make this relationship hard, how to translate product goals into research questions scientists can actually act on, how to evaluate prototypes for product viability, and what the best AI PM and scientist partnerships have in common.
The AI PM Minute
One tactic to make you a sharper AI PM, twice a week. 60 seconds to read. Free.
No fluff. Unsubscribe anytime.
The Fundamental Tension (and Why It Is Productive)
Applied scientists are trained to find the most rigorous answer to a well-defined question. Product managers are trained to find the most useful answer to an often poorly-defined one, fast. These are different intellectual orientations, and neither is wrong. The problem is when each side assumes the other has the same priority ordering.
Scientists often experience PM requests as vague, under-constrained, or dismissive of real technical complexity. PMs often experience research cycles as slow, over-engineered, and disconnected from user needs. Both perceptions are often accurate descriptions of a collaboration that has not yet found its working rhythm.
A well-posed question. One that has a clear success criterion, a defined evaluation methodology, and a bounded scope. Ambiguous requests ('make the model better at summarization') are not researchable without clarification.
Actionable output on a timeline that fits product development cycles. A research result that arrives after the engineering decision has already been made is not useful, regardless of its technical quality.
A shared understanding of what 'good enough' looks like. Research that could achieve 95% accuracy in six months versus research that could achieve 80% accuracy in six weeks is a product decision, not a science decision.
A structured collaboration protocol. Not a single conversation about 'working better together,' but a repeatable process for how research requests are scoped, how progress is communicated, and how prototype outputs are evaluated.
How to Scope Research Experiments as a PM
The most common PM mistake when working with applied scientists is handing over an outcome and calling it a research brief. "We need better intent classification" is not a research scope. It is a hope. A proper research scope is a document that defines the question, the evaluation methodology, the acceptable performance envelope, the constraints, and the decision it will inform.
Element: The question
AVOID
"Can we improve intent classification?"
BETTER
"Can a fine-tuned model distinguish between 'billing inquiry' and 'cancellation intent' with at least 90% precision at 80% recall on the Q3 support ticket test set?"
The good version is answerable. The scientist knows exactly what success looks like and what data to use.
Element: The constraints
AVOID
"Don't use a model that's too slow."
BETTER
"Latency budget: p50 under 200ms, p99 under 800ms, measured at inference on the production instance size. Cost budget: under $0.003 per inference at production volume."
Constraints are not restrictions on creativity. They are the parameters that make a solution deployable. Scientists without constraints optimize for performance, which is the wrong objective.
Element: The decision it informs
AVOID
"This will help us understand our users better."
BETTER
"If precision is above 90% at 80% recall, we will route cancellation-intent tickets to a dedicated retention team. If precision is below 85%, we will use a lower-confidence routing model with human review. We need results by Sprint 14 to make the routing architecture decision."
Connecting research to a specific decision creates a natural deadline and tells the scientist exactly which direction the uncertainty matters more in.
Translating Product Goals Into Research Questions
Product goals and research questions are not the same thing, and the translation between them is work the PM must do, not hand off to the scientist. A goal like "reduce churn by 10% in the next quarter" must be decomposed into the specific prediction, generation, or classification problem that, if solved, would make that outcome achievable. This decomposition is the most important contribution an AI PM makes to the research relationship.
Start with the mechanism
Ask: if we had a perfect solution to this research problem, what would users do differently? If the answer is 'nothing in particular' or 'we'd know more,' the research question is not tied to user behavior and probably should not be prioritized.
Identify the prediction target
Most applied research for product ends in a prediction: a probability score, a classification label, a generated response. Identify the prediction target explicitly. 'We need to predict whether a user will cancel in the next 7 days' is a classification problem with a clear label definition.
Define the ground truth source
Research requires labeled data to measure against. Where will the ground truth come from? Human annotation, behavioral outcomes, historical records? The answer affects the timeline, the data infrastructure needed, and the quality ceiling of the solution.
Map the uncertainty
Which parts of the problem are genuinely uncertain (the scientist needs to explore them) and which parts are already decided (constraints the engineer will implement)? Scientists work best when the uncertain part is bounded and the certain parts are specified.
Translation exercise
Take a product goal and run it through these three questions before briefing the scientist: (1) What is the specific AI prediction, generation, or classification that makes this goal achievable? (2) How will we measure whether the solution is good enough for production? (3) What is the earliest point in the product development cycle at which we actually need the research result?
Build the Cross-Functional Muscle
The AI PM Masterclass teaches you how to collaborate with technical teams, scope research, and make the calls that turn research into shipped product. Taught live by a Salesforce Sr. Director PM.
Evaluating Research Prototypes for Product Viability
A research prototype that performs well in the lab often underperforms in the product, or reveals new product questions the lab setup did not anticipate. Evaluating prototypes for product viability is a distinct skill from evaluating them for research quality. The scientist optimizes for the benchmark. You optimize for what happens when real users encounter it in a real context.
Does it generalize to the actual user distribution?
Research prototypes are often trained and evaluated on a curated dataset that does not represent the full range of inputs your users will provide. Ask the scientist to characterize the evaluation set and compare it explicitly to your production traffic distribution. The gap between the two is your deployment risk.
What does failure look like?
Beyond the aggregate performance metric, ask the scientist to pull examples of failure cases and categorize them. Are the failures random or systematic? A model that fails randomly is easier to deploy with a fallback than one that fails consistently on a specific user segment or input type.
What is the confidence distribution?
High-confidence wrong answers are worse than low-confidence wrong answers for most product applications. Ask for the confidence score distribution on both correct and incorrect predictions. A model with well-calibrated uncertainty is much easier to integrate safely than one that is always confidently wrong.
What does 'good enough' actually require?
There is often a wide range of technically achievable performance. A 92% solution might require 6 weeks of additional work over an 85% solution. Ask the scientist to sketch the performance-to-effort curve. You make the call on where in that curve is the right trade-off. Do not let the scientist make this decision by default.
What are the latency and cost projections at production volume?
Lab benchmarks are run on single examples or small batches. Production runs at scale with concurrent users and latency SLAs. Ask for projections at your expected p50 and p99 traffic load before declaring a prototype product-ready.
Communicating Constraints Without Killing Creativity
Scientists are accustomed to working within technical constraints. What they are less accustomed to is the product constraints: the timeline, the budget, the UX surface, the user mental model. These constraints often feel arbitrary from the outside, and without context, they can feel like someone is preventing a scientist from doing the best work. The fix is not to soften the constraints. It is to explain the why behind each one.
Explain the timeline constraint
Not 'we need this by Sprint 14' but 'the engineering team makes the routing architecture decision in Sprint 14 and a later research result cannot change it. That is why Sprint 14 is the hard deadline for a directional result, not a publication-quality one.'
Explain the latency constraint
Not '200ms maximum' but 'the research team's usability testing showed users begin to attribute slowness to the product itself at latencies above 300ms, and our SLA on the larger product surface is 200ms. The latency limit is a user experience requirement.'
Explain the accuracy threshold
Not '85% precision is fine' but 'at below 85% precision, the false positive rate would generate enough erroneous routing decisions to create a worse experience than not routing at all. 85% is the floor where the feature creates value rather than destroys it.'
Invite the scientist to challenge constraints
Constraints should be firm on the dimension that matters (timeline tied to a real decision, latency tied to user research) and negotiable on the dimension that does not (a benchmark dataset that is a proxy for the real metric). Make the distinction explicit and invite challenge on the negotiable ones.
What the Best PM and Scientist Partnerships Have in Common
The highest-performing AI product teams tend to have PM and scientist partnerships that share a specific set of structural habits. These are not personality traits or luck. They are practices that can be adopted deliberately.
A weekly research sync with a shared agenda format
Not a status meeting. A 30-minute conversation with a consistent agenda: current research status and blockers, any product context changes that affect the research direction, and one decision to make together. The shared agenda format prevents it from becoming a report-out.
Shared ownership of the evaluation framework
The scientist defines the technical evaluation methodology. The PM defines what 'good enough for the product' means. The evaluation framework is jointly written and jointly updated when product requirements change. Neither party unilaterally changes the success criteria without informing the other.
PM presence at research review
The PM attends the scientist's internal research review, not as an approver but as a source of context and a consumer of results. This positions the PM to ask the right questions and prevents the research review from producing outputs that are technically sound but productively useless.
A documented research backlog with priorities
A shared list of the open research questions that could improve the product, roughly prioritized by product impact and rough research difficulty. This gives scientists visibility into what is coming and reduces context-switch cost when product priorities shift. It also makes the research org more defensible when asked what they are working on.
Explicit post-mortems on research that did not ship
When a research result does not lead to a product change, the PM should run a brief post-mortem with the scientist: was the question wrong, was the result not good enough, or did the product context change? This closes the feedback loop and prevents the scientist from investing in the same type of question again.
Learn to Lead Across Technical Disciplines
The AI PM Masterclass covers how to work with applied scientists, run research-to-product loops, and develop the technical credibility that makes cross-functional partnerships work.
Related Articles
Before you go: get the AI PM Minute
One tactic to make you a sharper AI PM, twice a week. 60 seconds to read. Free.
No fluff. Unsubscribe anytime.