Most PMs work well with engineers and designers because the collaboration patterns are well-worn. We've written about both (engineers, designers). But drop a data scientist into the mix and things get awkward fast.
The failure modes are predictable. The PM treats the data scientist as a SQL vending machine: "pull me this number by Friday." Or as an oracle: "the model says X, so X is true." Or the opposite, ignoring them entirely until a launch needs a chart. Meanwhile the data scientist sits on insights nobody asked for, doing dashboard janitor work, quietly updating their resume.
It doesn't have to be like this. Data science, well-partnered, is the closest thing product teams have to a truth-finding function. Here's how to build the relationship.
First, Know Who You're Working With
"Data scientist" covers at least three fairly different jobs, and confusing them causes real damage:
- •Analysts / product data scientists: answer questions about users and the business. Funnels, cohorts, experiment analysis, metric design. Your most frequent collaborator.
- •Machine learning engineers / modelers: build models that live in the product: ranking, recommendations, fraud detection, forecasting. Collaboration looks more like working with engineering, with extra uncertainty.
- •Data engineers: build the pipelines everything else stands on. When your tracking is broken or your tables are wrong, this is who suffers.
Ask your data partner which work they do and enjoy. Asking an ML researcher for weekly dashboard updates, or expecting an analyst to ship a production model, misuses the person and poisons the well.
Bring Questions, Not Ticket Requests
Here's the single biggest upgrade available: change what you hand them.
The vending machine version: "Can you pull weekly active users by plan for the last 6 months?"
The partner version: "I'm trying to figure out whether our enterprise push is working. My hypothesis is that enterprise users activate slower but retain better. What's the best way to look at this?"
The second version does several things at once. It gives the data scientist the decision context, which lets them choose the right analysis instead of executing your possibly-wrong one. It invites their expertise, which is the whole point of having them. And it produces better answers, because "the number you asked for" and "the answer to your actual question" are frequently different things.
A good habit: for any meaningful request, include the decision this informs, your current hypothesis, and what you'd do differently depending on the answer. If you can't fill in that last part, the request might be curiosity rather than work, which is fine occasionally, but say so.
Involve Them Early, Not Forensically
Data scientists get pulled in at two bad times: after the feature is built ("can you add tracking?") and after the launch ("can you prove this worked?"). Both are too late.
Involve them when the work is being shaped:
- •At discovery time: they know where the bodies are buried in the data. "Before you interview churned users, look at this: 60% of churn comes from one segment" is the kind of thing they can tell you in week one instead of week ten.
- •At spec time: instrumentation is a requirement, not an afterthought. Deciding what events to track, with what properties, is much cheaper before the code exists. A PRD with a "how we'll measure this" section co-written with data science is a different class of document.
- •At experiment design time: sample size, metric choice, and test duration decided before launch. A data scientist consulted before the test can save it; consulted after, they can only perform the autopsy.
Respect the Uncertainty (It's the Product)
The most common friction point: PMs want clean answers, data science produces caveats. "It depends," "the confidence interval is wide," "we can't distinguish this from seasonality."
Here's the reframe: the caveats are the expertise. Anyone can produce a confident number; knowing how much to trust it is the skill you're paying for. A PM who pressures for certainty gets one of two outcomes: a data scientist who stops sharing doubts (dangerous) or one who stops engaging (worse).
Practical implications:
- •Ask "how confident are we, and what would make us more confident?" instead of "so is it true or not?"
- •When a finding kills your favored feature, thank the messenger, visibly and in public. The first time you shoot the messenger is the last time you get an honest message.
- •Don't shop for analyses. Rerunning the question until someone produces the answer you wanted is the data equivalent of reopening a decision until you win.
And on ML specifically: model work is research, not construction. "How long until the model works?" sometimes has no honest answer. Scope ML projects with checkpoints ("two weeks to know if this approach is viable") rather than delivery dates, and always ask the question that saves quarters of pain: "what would a dumb heuristic get us?" If a simple rule captures 80% of the value, ship the rule first.
Give Impact, Get Retention
A quiet truth from the data side: data scientists leave product teams mostly for one reason. Not pay, not tooling. It's doing work that never affects anything. Analyses that get skimmed and shelved. Dashboards nobody opens. Recommendations that lose to a HiPPO in every meeting.
The PM controls most of the fix:
- •Act on findings, or explain why not. "We're not doing what your analysis suggests, because X" is respectful. Silence is corrosive.
- •Credit them where decisions get made. "This roadmap change comes from Maria's churn analysis" costs you nothing and buys you a motivated partner.
- •Bring them to the decision, not just the prep. A data scientist in the roadmap meeting can answer the follow-up questions their document can't.
- •Close the loop on outcomes. When the experiment they analyzed leads to a shipped win, tell them what happened. Impact visibility is oxygen.
Do this for two quarters and you'll notice the difference: proactive insights start arriving before you ask, because sharing them with you demonstrably matters.
A Working Rhythm That Holds Up
You don't need heavy process. Teams that do this well typically have:
- •A standing sync (weekly or biweekly, 30 minutes) covering active questions, upcoming launches needing instrumentation, and anything interesting they've found
- •A shared questions doc: the running list of what the team wants to know, prioritized together, so the work queue is visible and negotiable
- •Data science at sprint planning and roadmap reviews, as participants, not spectators
- •PM self-serve for the basics. Learn enough SQL or your analytics tool to answer simple questions yourself. It respects their time and sharpens your questions. (It also makes you noticeably stronger in metrics conversations everywhere else.)
The Bottom Line
Know which kind of data person you have. Hand them decisions and hypotheses, not ticket requests. Pull them in when work is being shaped, treat their uncertainty as expertise, and make sure their work visibly moves decisions. The teams that operate this way compound learning faster than their competitors, and it shows up in the product within a couple of quarters.
Collaboration questions like "tell me about working with a data scientist" are increasingly common in PM interviews, especially for growth and ML-adjacent roles. Now you have a real answer.
Find product roles on data-serious teams at productmanagerjobboard.com.