AI Employer Due Diligence: How to Evaluate a Company Before Joining as an AI PM

Why AI Roles Need More Due Diligence, Not Less

"AI PM" on a job title does not mean AI is actually central to the product. In 2026, approximately 40% of roles listed as AI product manager are for companies where AI is an adjacent feature, a marketing angle, or a planned capability that has not shipped. The variance in role quality is higher in AI than in any other PM specialty because the category is new enough that companies define it inconsistently.

The cost of a bad AI PM hire is also higher than average. Switching costs are real: AI PM reputation is built on shipped products, not headcount growth or roadmaps. A two-year stint at a company where the "AI" never went beyond a chatbot tab costs more career capital than a two-year stint at a non-AI company where you shipped cleanly.

Real AI role signal

The team includes ML engineers or model researchers, not just data engineers. The product has already shipped AI features to real users. The CTO or VP of Eng has a public track record in applied ML. The company has a defined eval and monitoring practice.

Wrapper-with-roadmap signal

The AI feature is described as a future differentiator, not a current one. The engineering team is primarily backend/frontend with no ML specialization. The competitive moat is described as data, but the team has no data labeling or feedback loop in place. The AI vendor relationship is undisclosed or described vaguely as 'OpenAI'.

Hype-cycle signal

Leadership pivoted to AI within the last 12 months after a different strategy. The product existed before AI and is now 'AI-powered.' The role was posted after a competitor announced an AI product. Headcount is growing faster than the product's user base.

Dimension 1: The Actual Technical Stack

The technical stack tells you two things: whether AI is deeply embedded or bolted on, and whether the company is investing in differentiated capability or renting commodity intelligence from a single vendor.

A product where AI is deeply embedded has model calls at the core of the user journey, a feedback loop that improves the model's performance over time (RLHF, fine-tuning, or at minimum a labeled eval set), and engineering decisions that reflect the operational reality of AI (latency budgets, cost per query, fallback behavior). A product where AI is bolted on has a chatbot or summarization feature built on an off-the-shelf API, with no differentiated data, no feedback loop, and no evaluation infrastructure.

Questions to ask the hiring manager

What model providers do you use in production today? What percentage of your engineering budget is AI infrastructure vs. the rest of the product? What is your evaluation setup for AI features? Have you had a model deprecation or API change affect a shipped feature?

Things to look up publicly

Check LinkedIn for ML engineers on the team (not just data engineers). Search for the company on Hugging Face or arXiv to see if they publish model research. Look for engineering blog posts about AI infrastructure decisions, not just product announcements.

Red flags in the conversation

Vague answers about which models are used ('we use the latest models'). No mention of latency, cost, or reliability challenges. AI described only in product marketing terms, not technical terms. No one on the interview panel who has shipped AI in production.

Green flags

Specific numbers: 'Our median inference latency is 380ms and we have a 500ms SLA.' Honest tradeoffs: 'We use Sonnet for most tasks and Opus for the edge cases that justify the cost.' Evidence of a feedback loop: 'Our eval set has grown to 4,000 labeled examples over 18 months.'

Dimension 2: Who Actually Controls the AI Roadmap

AI PM scope varies enormously. In some companies, the AI PM owns the model selection, eval strategy, and deployment decisions. In others, an AI research team or a central platform team makes those decisions and the PM is a feature requester. Neither is wrong, but the scope determines what skills you will build and what your career trajectory looks like.

PM-owned AI roadmap

What it means: The PM owns the full product loop: identifying the problem, defining the eval criteria, working with engineers to select the model and architecture, launching, and iterating based on production metrics.

PM implication: High scope, high exposure to what is working and what is not. You build deep technical judgment. You are also accountable for outcomes that depend on model behavior, which requires investing in evaluations and monitoring.

Platform-mediated AI

What it means: A central AI or ML platform team owns infrastructure decisions, model selection, and evaluation tooling. The PM specifies requirements for the platform team and implements features on top of the platform's abstractions.

PM implication: Lower technical depth for the PM, faster feature velocity, more constraint. Good for building feature PM skills quickly. Less suitable if your goal is to develop deep technical AI product expertise.

Research-driven AI

What it means: An ML research or applied science team drives the AI direction. The PM's job is to translate research outputs into product requirements and manage the research-to-production pipeline.

PM implication: High learning opportunity in a well-funded research org. Risk: research timelines are uncertain and the PM may be blocked on shipping if research misses milestones. Excellent if you want exposure to frontier capabilities; frustrating if you want shipping velocity.

Build the Skills That Make You a Strong Candidate

The AI PM Masterclass is designed for product managers who want to move into AI PM roles or advance within them. Taught live by a Salesforce Sr. Director PM.

Dimension 3 and 4: AI Maturity Curve and Failure Culture

Where a product sits in its AI maturity curve determines the type of work you will do. How a company handles AI failures determines whether you will be supported or exposed when something goes wrong.

AI maturity signals: A pre-AI-launch company has high risk and high upside; your job is to get the first AI feature into production, which is primarily a build-and-ship problem. A post-launch company with low user adoption is a product-market-fit problem; your job is to find the use case that actually gets used. A post-launch company with high adoption is a scale, reliability, and expansion problem. Each stage requires different skills, and the honest answer about where the product is determines whether your strengths match the actual role.

Failure culture: green flags

The team can describe a specific AI incident (a hallucination that reached users, a model regression, a prompt injection vulnerability) and what they learned from it. Postmortems are blameless and public internally. The engineering team invested in eval infrastructure after a failure, not before.

Failure culture: red flags

'Our AI has never had a significant issue.' Either the product is not in wide production, or failures are not visible internally. No postmortem culture. Failure is framed as a rare exception rather than an expected part of AI product development.

AI maturity: questions to ask

What percentage of your users actively use the AI features vs. the non-AI parts of the product? What is the AI feature's retention rate at 30 days? What does your feedback loop look like for improving AI quality over time?

AI maturity: what to infer

If the company cannot answer the retention question, the AI feature probably launched without instrumentation. If the feedback loop is 'we read user reviews,' there is no systematic improvement process. Both are common at Series A and early Series B.

Dimension 5: The Contract and Equity Reality

AI PM compensation in 2026 skews high because demand outstrips supply, but the distribution is wide. Total compensation at a well-funded Series B with a real AI product differs from total compensation at a late-stage company doing an AI rebrand. Stock in the latter may be worth significantly less than it appears on paper.

AI-specific contract terms to review: IP assignment clauses that claim your AI-related side projects. Non-compete clauses that use "artificial intelligence" as a prohibited industry, potentially blocking you from the entire AI labor market for 12-24 months. Confidentiality provisions that extend to model behavior you observed in your work, limiting what you can discuss publicly. These are not boilerplate, and they are becoming more common in AI PM offers as companies try to protect competitive information about their AI stack.

IP assignment: confirm it is scoped to work performed during employment, not AI work performed outside work hours

Non-compete: check whether 'artificial intelligence' appears as a prohibited industry or category (versus a narrower customer or product restriction)

Confidentiality: look for provisions that extend to 'model behavior,' 'system prompts,' or 'AI performance data' beyond the standard trade secret scope

Equity: request a cap table summary and liquidation preferences before evaluating the equity offer at face value

Performance review: ask explicitly how AI PM performance is measured — if no one can answer, accountability structures do not yet exist

20 Reverse-Interview Questions That Reveal Reality

These questions are designed to surface the answers that do not appear in job descriptions. Ask them across multiple interviewers: the hiring manager, a potential peer engineer, and a skip-level if you can get one. Consistency across answers is a signal; vagueness or inconsistency is data.

1. What AI features have you shipped in the last 12 months, and which one are you least proud of?

2. What is your median inference latency in production today, and what is your target?

3. Walk me through the last AI incident you had and how it was resolved.

4. How do you decide which model to use for a given feature, and who makes that call?

5. What does your eval set look like today? How many examples, and who labels them?

6. What percentage of active users engage with the AI features in a given week?

7. Who owns the AI PM roadmap: the PM, the research team, or the platform team?

8. What AI features are on the roadmap that haven't shipped yet, and what is blocking them?

9. How does this role interact with the ML or data science team day to day?

10. What does success look like for this role in 6 months, in concrete measurable terms?

11. What is the model cost per monthly active user, and is it growing faster or slower than revenue?

12. Have you had a model deprecation or provider API change affect a shipped feature? What happened?

13. How do you handle hallucinations that reach users in production?

14. What does the on-call rotation look like for AI features?

15. What AI capabilities are you most concerned about competitors shipping before you?

16. What is the most technically hard problem the AI PM in this role will face in year one?

17. How does engineering weigh AI feature requests vs. reliability and infrastructure work?

18. What AI conferences or research does the team actively follow?

19. Have you done any fine-tuning or RLHF, or is the stack entirely prompt-based?

20. What would make this role fail, in your honest view?