Influencing Without Authority as an AI Product Manager
TL;DR
AI product managers are accountable for outcomes they cannot mandate. You do not hire or fire the ML engineer. You do not set the data scientist's sprint priorities. You cannot tell the research team what to study. But the product lives or dies on their work. This is not a bug in the AI PM role. It is the defining feature. The AI PMs who move fastest are not the ones with the most authority. They are the ones who have learned that influence is a skill with specific components: building technical credibility before you need it, framing work in terms that each function cares about, and creating the conditions where the people you depend on want to prioritize your product. This guide covers the specific frameworks and tactics that make AI PMs effective without a reporting line.
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.
Why AI PMs Have Less Authority Than They Think
Traditional product management operates on a fiction that product managers lead through authority. They do not. They have always led through influence. But AI product management makes the authority gap more visible because the people you depend on most, ML engineers, data scientists, AI researchers, and MLOps engineers, typically report into engineering or research organizations with their own roadmaps, their own metrics, and their own ideas about what is worth building.
At large companies, this gap is structural. The ML platform team is funded to build infrastructure, not product features. The data science team is measured on model quality, not user outcomes. The research organization is evaluated on publications and breakthroughs, not ship dates. You are asking each of these groups to prioritize work that serves your product's metrics, but none of their incentive structures directly rewards doing that.
At startups, the gap looks different but is still real. The ML engineer who built the core model has opinions about the right architecture, and those opinions may conflict with the product direction you want to take. You do not have the authority to override the architectural decision. You need to win the argument on the merits or find a way to make both paths work.
ML engineering prioritization
ML engineers typically have their own sprint capacity negotiations. Your feature competes with infrastructure work, technical debt, and other product teams. Even when you are formally aligned, capacity slips happen and the PM cannot mandate otherwise.
Data access and labeling
Data scientists and data engineers control the pipelines. When you need a new data signal or a labeled dataset for a new model, you are requesting work from a team that has its own backlog. Urgency for you is not automatically urgency for them.
Model architecture decisions
Architectural decisions for AI features involve tradeoffs that the PM cannot fully evaluate without domain expertise. The ML team makes these calls. Your influence is in shaping the decision criteria and ensuring product constraints are understood, not in making the architectural choice yourself.
Research timelines
If your product roadmap depends on a research breakthrough, you do not control the timeline. Research is not a sprint. Influence here means ensuring research is oriented toward product-relevant problems, not that you can move the date.
The Trust Stack: How Influence Actually Works With Technical Teams
Influence is not persuasion. Persuasion is what you do once. Influence is what determines whether your requests get prioritized before you ask. With technical teams specifically, influence operates through a trust stack that takes time to build and can be destroyed quickly by specific behaviors. The stack has three levels: technical credibility, problem clarity, and relationship capital.
Level 1: Technical credibility
ML engineers and data scientists respect PMs who understand the work. Not deeply enough to do it themselves, but deeply enough to ask the right questions, understand the constraints, and not waste time explaining fundamentals. Build this by reading the papers that matter to your team, by understanding what your model actually does, and by demonstrating in meetings that you understand the tradeoff being discussed. You do not need to be an ML engineer. You need to not seem like you are guessing.
Level 2: Problem clarity
Technical teams prioritize PMs who define the problem well enough that the technical solution is obvious. Vague requests, 'make the model better,' do not get prioritized because they cannot be scoped. Specific requests with clear success criteria and well-defined failure cases do. The PM who brings a clear problem statement earns influence because they reduce the team's uncertainty cost. The PM who brings a vague direction increases it.
Level 3: Relationship capital
At the individual level, influence flows through relationships. The ML engineer who trusts you responds to your Slack message within an hour. The one who does not trust you deprioritizes your ticket. Relationship capital is built through consistency, through following through on commitments, through not throwing the team under the bus when a feature ships poorly, and through giving credit publicly when things go well.
The destroyer: borrowed urgency
Borrowed urgency is when a PM escalates to their manager to create pressure on a team they cannot influence directly. It works once, sometimes twice. After that, the team learns that your requests come with a threat implicit in them, and they route around you whenever possible. Borrowed urgency is the most common mistake PMs make when they feel they are losing influence, and it is the fastest way to permanently reduce it.
Five Influence Tactics That Work With AI Teams
The following tactics are specific to working with ML engineers, data scientists, and AI researchers. They differ from the generic influence advice because technical teams respond to different signals than non-technical stakeholders. Generic PM influence frameworks focus on storytelling and executive alignment. Those matter, but they are not what moves technical teams.
Translate product goals into evaluation criteria, not feature requests
How: Do not tell the ML team what feature to build. Tell them what outcome to optimize for, then help them define the eval that measures it. 'Users want the AI to sound more natural' is hard to build against. 'Conversations where the AI response is interrupted by the user within 5 seconds are our primary failure mode' is something an ML engineer can write an eval for. Giving the team an eval criterion rather than a feature spec puts them in the driver seat for the solution while keeping you in control of the success definition.
Why it works: ML engineers are motivated by solvable problems. An eval criterion is a solvable problem. A vague feature request is not.
Share user evidence, not your opinion
How: When you want to influence a prioritization decision, bring user evidence rather than your judgment. Session recordings, support tickets, NPS verbatims, and user interview clips are more persuasive with technical teams than a PM's assessment of what matters. Technical people are trained to trust data over assertion. Use that. When you come to a prioritization meeting with three user recordings showing the same failure mode, you are not making an argument. You are presenting evidence.
Why it works: Opinion is debatable. Evidence is not. The goal is to make prioritizing your work feel like the rational response to data, not a favor to you.
Create low-cost ways for the team to learn your domain
How: AI PMs often have domain knowledge that ML engineers lack: customer behavior, industry context, regulatory constraints, competitive landscape. Share this context proactively, not in the moment when you need something. A five-minute segment in the monthly team meeting where you share one customer insight you found interesting, not in service of a specific ask, builds the team's understanding of why their work matters and creates goodwill you can draw on when you do need something.
Why it works: People prioritize work when they understand its impact. Making it easy for the team to understand the customer increases the natural pull toward product-valuable work without any single request on your part.
Give technical input before decisions, not feedback after
How: Getting involved early in technical design decisions, even when you cannot evaluate the technical tradeoffs, signals that you are a partner in the work rather than a consumer of it. Attend architecture reviews. Ask questions that clarify product constraints: 'What does this architecture choice mean for our latency on mobile?' You are not there to make the technical call. You are there to ensure product constraints are in the room during the decision.
Why it works: Technical decisions made without product input create rework. When engineers know you will catch product-constraint gaps early, they proactively include you. That inclusion is influence.
Document and publicize technical work that the team does not get credit for
How: ML engineers and data scientists often do significant work that is invisible to the organization: model quality improvements that prevent degradation, infrastructure work that enables future features, data cleaning that unblocks downstream tasks. PMs who surface this work in stakeholder communications, sprint reviews, and all-hands meetings earn loyalty that translates into prioritization. Credit given publicly compounds.
Why it works: Reciprocity is real. When you systematically make the team's work visible, they systematically make your product needs a priority. This is not manipulation. It is the honest observation that recognition and prioritization are connected.
Learn the AI PM Skills That Actually Move Teams
The AI PM Masterclass covers cross-functional leadership, technical communication, and how to build the influence that gets AI products shipped, taught live by a former Apple and Salesforce Sr. Director PM.
Influence Patterns for Each Technical Function
Different technical functions respond to different influence patterns. The approach that works with ML engineers does not automatically work with data scientists or AI researchers. Here is the map.
ML Engineers
Influence currency: Concrete evals and clear failure modes
Avoid: Vague quality requests and changing requirements mid-sprint. ML engineers lose trust fast when the success definition moves after they have started building.
Build trust by: Spend time with them in debugging sessions. When they are investigating a model issue, being present and engaged builds more influence than any meeting.
Data Scientists
Influence currency: Business questions that need their analytical skill to answer
Avoid: Treating them as query executors. Data scientists want to do analysis that shapes product strategy. When you bring them strategy questions rather than just dashboards to build, they engage at a different level.
Build trust by: Co-present their analysis findings to leadership. Give them visibility into the business impact of their work. Data scientists are often invisible to the business; PMs who change that earn deep loyalty.
AI/ML Researchers
Influence currency: Product problems that are also intellectually interesting
Avoid: Feature requests. Researchers do not respond to feature requests. They respond to problems that are both important and technically interesting. If your product problem has an interesting technical angle, lead with that.
Build trust by: Connect their research outputs to real user impact. Researchers often do not see the user facing end. When you make that connection visible, you shift their intuition about which research directions are most worth pursuing.
MLOps and AI Infrastructure Engineers
Influence currency: Clear deployment requirements and advance notice of launch plans
Avoid: Surprise launch dates and last-minute infrastructure asks. MLOps teams run on planning. Surprises create technical risk and make them unlikely to prioritize your next ask.
Build trust by: Advocate for MLOps investment in your roadmap planning. When you include infrastructure reliability as a product priority rather than a tax on engineering time, you signal that you understand their work.
The Long Game: Building Influence That Compounds
Influence that works tactically for one project is not the same as influence that compounds over time. The difference is reputation. Tactical influence wins a sprint. Reputation-based influence means that when the organization has a hard decision about where to invest, the people who matter are already predisposed to your agenda.
Be right about what matters
The single highest-leverage influence move is having a track record of calling the right product bets. When you have been right about what users need and what the model can deliver, your judgment earns credibility that extends to future bets before the evidence is in. Being right is not about luck. It is about doing the customer work that generates better signal than your peers have.
Protect the team from bad asks
One of the most powerful influence builders with technical teams is running interference on low-value requests from other parts of the organization. When the ML team knows you will push back on requests that would waste their time, they trust you to bring requests worth their time. Gatekeeping earns influence with the people behind the gate.
Create rituals that make the work visible
Regular demos, monthly impact reviews, and sprint-end showcases create recurring moments where the team's work is seen. PMs who create these rituals build loyalty because they are solving a problem the team has. Most technical teams feel invisible. Being seen matters.
Build the external narrative that makes their work matter
AI PMs who can articulate the product vision in terms that make external stakeholders, customers, press, and leadership, understand why the technical work matters are influencing the team's context. When the team can see their work reflected in a story the organization tells about itself, they are more invested in the outcome. That investment translates to prioritization.
Build the Influence Skills That AI PMs Need
The AI PM Masterclass is taught live, cohort-style. That means you practice these skills with ML engineers, data scientists, and product leaders in real time, not just read about them.
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.