The Operating Shape of AI Product Management: Evidence from 100 Current Vacancies in 2026

The Operating Shape of AI Product Management: Evidence from 100 Current Vacancies in 2026

Author: MTF Institute Research Team
Research cut-off: 21 August 2026, Europe/Lisbon
Status: original website research draft; not published

Abstract

AI product management is often described through the novelty of models, assistants or agents. Current vacancy evidence presents a more operational picture. In a bounded sample of 100 public vacancies current on 21 August 2026, every accepted record combined AI product strategy with technical fluency, 99 were coded for delivery, 82 for responsible-delivery concerns and 81 for discovery. Sixty-six records contained all five research codes. The role shape visible in this sample is therefore not limited to choosing features or writing a roadmap. It joins outcome framing, customer and user understanding, technical translation, evaluation, cross-functional delivery, launch, monitoring and accountable decisions under uncertainty.

The sample is also senior-weighted. Sixty-nine records are explicitly classified as senior, lead or principal, director, executive or head roles. Fifteen titles refer to agents or agentic work, while seven refer to platforms. These signals show how the role can widen from one user-facing feature to reusable capability, internal enablement and longer action chains. They do not establish market growth or a universal career ladder.

This report explains the operating responsibilities visible in the corpus and their practical implications. It does not estimate the size of the labour market, forecast hiring, compare salaries or claim that a course guarantees employment. Its conclusion is narrower: effective AI product management is the discipline of making traceable product decisions when user value, model behaviour, data, cost and risk cannot be treated as independent questions.

The complete research archive — searchable PDF, evidence workbook and accepted-vacancy dataset — is openly available at Zenodo DOI 10.5281/zenodo.22044273.

Key findings

• The corpus contains 100 unique public vacancies from 67 employer labels, all current at the retrieval date.
• 90 records came from first-party employer ATS pages and 10 from public job boards that were individually revalidated.
• 71 vacancies are labelled North America, 11 Europe, 10 global remote, 4 Asia-Pacific, 2 MENA and 2 unspecified.
• Strategy and technical fluency are coded in 100 vacancies each; delivery in 99, responsible delivery in 82, and discovery in 81.
• 66 vacancies contain all five codes.
• 69 vacancies are explicitly senior, lead/principal, director or executive/head roles; only 2 are classified as associate.
• 15 titles use the whole-word forms agent, agents or agentic, and 7 use the word platform. These overlapping title signals show visible specialisms, not an exhaustive taxonomy.

Why use vacancy evidence?

A vacancy is not a complete description of a profession. It is written for a particular organization, product, hiring level and moment. Its language may combine aspirations with immediate needs, and a public page can disappear as soon as the position closes. Nevertheless, a set of current vacancies is useful for one bounded purpose: it shows the work that organizations choose to describe when they seek people for a role.

This matters for AI product management because the label can be interpreted too broadly. A generic product manager may use an AI assistant in personal work without owning an AI product. An engineer may build model infrastructure without owning product discovery or business outcomes. A project manager may coordinate an AI initiative without deciding product direction. To understand the operating shape of AI product management, the evidence has to distinguish material AI product ownership from these adjacent activities.

Vacancies are particularly informative through their combinations of duties. One isolated phrase about a roadmap says little. A repeated combination of strategy, technical translation, discovery, delivery and responsible operation suggests a role that must integrate different kinds of evidence. The combination also points to practical work products: a problem brief, decision record, evaluation plan, prioritized roadmap, release review and monitoring design.

The evidence still requires restraint. A count of public vacancies is not a count of hires. A source distribution is not a market-share estimate. A coded responsibility is not proof that every organization uses the same process. This report keeps those limits visible and treats the corpus as current operating evidence rather than a census.

Methodology

Research question

The study asked: what operating responsibilities are visible across a bounded international sample of current vacancies for AI product managers, and what do those responsibilities imply for practical preparation in strategy, discovery, responsible delivery and cross-functional execution?

Collection and eligibility

The MTF Institute Research Team inspected 506 public role candidates. One hundred were accepted and 406 were excluded or not selected. Each accepted record had to be individually addressable and current on 21 August 2026. It needed an employer label, exact title, location, public HTTPS URL, retrieval evidence and a short 8–20-word duty excerpt. No authentication, credentials, CAPTCHA bypass or access- control workaround was used.

Material AI product ownership had to be explicit in the title or, for one exact job-board title, clearly present in the role body. The role needed product responsibility connected to one or more of strategy, discovery, prioritization, delivery, evaluation, platform work, responsible operation or lifecycle management. AI mentioned only as a preferred personal tool or in general company boilerplate was insufficient.

Closed, expired and inaccessible pages were excluded. The same applied to generic product roles without material AI ownership, product marketing, design, sales, internships, project or programme management and engineering-only work. When a job board syndicated a requisition already accepted from a first-party ATS, the syndicated copy was rejected. Tracking parameters were removed for URL comparison. The deduplication key combined normalized employer, exact title, location or jurisdiction and the source-platform requisition identifier.

The accepted TSV contains 100 unique source IDs, 100 unique canonical URLs and 100 unique deduplication keys. It has no duplicate normalized employer-title- location group. First-party ATS records were capped at four per employer to reduce source concentration. The 67 distinct employer labels were calculated by trimming and case-folding the corpus field; this is not a verified legal-entity count.

Source mix

The source mix is deliberately disclosed because access patterns shape results. Greenhouse contributes 57 records, Ashby 24 and Lever 9. Those 90 first-party ATS records are complemented by seven Remote.com records, two We Work Remotely records and one AIJobs.net record. All ten job-board pages were individually revalidated.

This mix provides multiple source families, but it does not make the sample statistically representative. Organizations using other ATS products, private recruitment, local-language boards or closed networks are under-observed or absent. Public English-language availability influenced selection.

Coding

Each vacancy received one or more of five transparent codes:

1. Strategy (APM-STRAT): AI product vision, portfolio, roadmap, commercial or business-outcome ownership.
2. Discovery (APM-DISC): customer or user discovery, problem framing, validation or experimentation.
3. Delivery (APM-DELIV): requirements, prioritization, cross-functional delivery, launch or adoption.
4. Responsible delivery (APM-RESP): safety, trust, governance, risk, explainability, human oversight or related responsible-operation work.
5. Technical fluency (APM-TECH): AI or machine-learning platform, model, data, evaluation, agent, inference or lifecycle fluency.

The codes are research categories, not an employer taxonomy or an external standard. They overlap. One vacancy can contain all five. Their purpose is to describe combinations of responsibility without reproducing job descriptions.

For a secondary view, the study counted transparent terms in titles and the short evidence anchors. Fifteen titles contain the whole-word forms agent, agents or agentic; seven contain platform. Other disclosed expressions searched for strategy, discovery, evaluation, outcomes, delivery and responsible- operation vocabulary. These text signals are supporting observations only. The minimal excerpts were not designed to represent the entire vacancy, so an unmatched word cannot establish that a duty is absent.

Rights approach

The research record stores derived facts, public URLs, classifications and one short evidence anchor per vacancy. This website draft uses aggregate counts and original MTF Institute Research Team synthesis. It does not reproduce employer job descriptions, logos, screenshots, diagrams or branded methods. Employer and platform identifiers do not imply endorsement, partnership or review.

The sample at a glance

Geography

Region label	Vacancies	Share
North America	71	71%
Europe	11	11%
Global remote	10	10%
Asia-Pacific	4	4%
Middle East and North Africa	2	2%
Unspecified	2	2%
Total	100	100%

The North American concentration is a major limitation, not a minor footnote. The sample can reveal responsibility combinations across accessible roles, but it cannot support a statement that one region has more underlying demand than another. Global remote roles are kept separate because their permitted hiring locations were not consistently reducible to one jurisdiction.

Seniority

Seniority code	Vacancies	Share
Senior	37	37%
Lead or principal	29	29%
Manager, grade unspecified	29	29%
Director	2	2%
Associate	2	2%
Executive or head	1	1%
Total	100	100%

The seniority pattern supports a cautious conclusion: the accepted vacancies often assign substantial ownership to AI product work. It does not establish a universal career ladder. The word “manager” is especially ambiguous because a product-manager title may describe product responsibility rather than line management. The 29 manager-unspecified records are therefore not automatically treated as senior or as people-management roles.

Finding 1: strategy and technical fluency operate together

All 100 accepted vacancies were coded for strategy and all 100 for technical fluency. This result is partly a consequence of the eligibility rule: a role had to show material AI product ownership rather than generic product work. Even with that qualification, the combination is informative. Within the accepted role family, product direction and AI-system understanding are not separate tracks.

Strategy here means more than placing “AI” on a roadmap. The product manager has to connect an intended user or business outcome with a capability whose behaviour is probabilistic, data-dependent or changing. The manager must be able to discuss what the product should accomplish, for whom, compared with which baseline and under which constraints. At the same time, the manager needs enough technical fluency to understand why model choice, data availability, evaluation, latency, inference cost, integration and monitoring can change the product decision.

This is not an argument that product managers should replace engineers, data scientists or model specialists. The role's distinctive value is translation. An effective product manager can turn an outcome into questions specialists can test, then turn technical evidence into a decision that customers, business owners and delivery teams can understand. The translation must preserve uncertainty instead of hiding it behind a confident feature promise.

Consider a fictional customer-support organization evaluating an AI assistant. A weak product brief might say that the assistant should answer customer questions. A stronger brief specifies which customer segments and intents are in scope, which source material the assistant may use, what outcome is expected, what response quality would be useful, what failures are unacceptable, when a person must take over, what latency and cost are tolerable and which evidence is needed before expansion. None of these questions belongs solely to “business” or “technology.” Together, they define the product.

A practical preparation programme should therefore teach outcome framing and AI technical translation in the same case. Learners should practice creating an evidence-linked product brief rather than separate business and technical documents that never reconcile.

Finding 2: delivery is nearly universal

Ninety-nine of the 100 vacancies contain the delivery code. The role shape is therefore operational as well as strategic. Requirements, prioritization, cross-functional coordination, launch and adoption are not work that begins after the “AI thinking” ends. They are how an uncertain capability becomes a bounded product that people can use and an organization can support.

AI products create delivery challenges that a feature list alone cannot manage. A team may need to coordinate model or service dependencies, data access, evaluation sets, interface behaviour, user feedback, monitoring, operational support and a fallback path. A model improvement may raise quality but increase latency or cost. A prompt or retrieval change may alter behaviour without a traditional interface change. A release can look complete from an engineering perspective while adoption fails because users do not know when to trust, question or escalate its output.

The product manager's roadmap should make these dependencies visible. One useful approach is to connect every meaningful release item with its target outcome, assumption, owner, technical dependency, evaluation evidence, operating condition, adoption action and review date. This is an original practical synthesis from the corpus, not a claim that all employers use one template.

Delivery also requires decision hygiene. When a team changes scope, accepts a trade-off or proceeds with incomplete evidence, the rationale should be recorded. Otherwise, later teams cannot distinguish an intentional decision from an overlooked issue. Traceability is valuable not because documentation is an end in itself, but because AI products can change across data, model, prompt, interface and operating context. A concise decision record helps the team learn which change produced which effect.

Finding 3: discovery must test the problem and the AI approach

Discovery is coded in 81 vacancies. Its presence in more than four-fifths of the sample makes it a major role component, but not a universal one. Fifteen records contain strategy, delivery, responsible delivery and technical fluency without a discovery code; four contain only strategy, delivery and technical fluency. Those omissions may reflect role scope, vacancy brevity or coding boundaries. They are not proof that the employers perform no discovery.

AI product discovery has a double burden. First, the team must understand whether the user or business problem is important enough to solve. Second, it must test whether an AI-enabled approach is suitable relative to alternatives. A problem can be real while the AI solution remains unnecessary, unreliable or too costly. Conversely, an attractive technical capability can exist without a sufficiently valuable use case.

The comparison set matters. For a fictional contract-intake workflow, the alternatives might include process simplification, better search, structured forms, deterministic rules, conventional software automation, an AI assistant or no change. Discovery should compare these paths against the same outcome and constraints. The question is not “How can we use AI?” but “Which intervention creates the most useful and defensible change for this problem?”

Good discovery also separates different kinds of uncertainty. User uncertainty asks whether people have the problem and would change their behaviour. Value uncertainty asks whether the change matters to the organization. Feasibility uncertainty asks whether the capability can perform under real data, integration, latency and cost conditions. Responsible-operation uncertainty asks what harm or failure could occur, how people would notice it and what boundaries are needed.

An applied learning experience should make these uncertainties testable. Learners can build a discovery plan that names a hypothesis, evidence source, test, decision threshold and next action. The completed fictional example should show how evidence can lead to continuation, redesign or rejection of the AI path. Rejecting a weak AI use case is a valid product outcome, not a failure of innovation.

Finding 4: responsible delivery is part of product operations

Eighty-two vacancies were coded for responsible-delivery concerns. The category includes terms and duties related to safety, trust, governance, risk, explainability and human oversight. The study does not use this count to claim legal compliance or verified safety. It shows that responsible operation is commonly visible within the product role as described in this sample.

Responsible delivery becomes practical when the team turns general values into observable product decisions. A product manager can ask: who can be affected by an output or action; what failure modes matter; what evidence would reveal them; what boundary limits the feature; when must a person review or override; who owns the escalation; and what would trigger rollback, restriction or retirement?

For the fictional support assistant, a broad statement such as “the system must be trustworthy” is difficult to act on. A bounded product record can specify the intents the assistant may handle, the sources it may use, situations it must escalate, signals monitored after launch, review frequency and decision owner. The team can then connect those conditions to evaluation and release evidence.

This work should not be mistaken for an assurance certificate. Product evidence can support a decision, but it does not prove that every risk has been removed. Nor should a product manager make specialized legal or technical determinations outside the person's competence and authority. The operational role is to ensure that questions, evidence, owners, boundaries and unresolved issues are visible to the people who must decide.

The sample supports integrating responsible-delivery work with ordinary product artifacts. A risk or failure scenario can be linked to a requirement. An evaluation result can be linked to a release condition. A user-control decision can be linked to interface behaviour. A post-launch signal can be linked to an owner and response. This reduces the chance that responsible operation becomes a separate document reviewed too late to change the product.

Finding 5: evaluation connects claims with evidence

The five-code system includes evaluation within technical fluency and responsible delivery. A secondary, deliberately narrow text check found evaluation, quality, accuracy, metric, threshold, benchmark, failure or test vocabulary in 20 titles or short evidence anchors. Because the anchors contain only 8–20 words, this number must not be treated as full-description prevalence. It nevertheless illustrates why evaluation deserves an explicit place in the operating model.

An AI product claim should be phrased so that evidence can challenge it. “Improves support” is too broad. “Helps support agents identify the correct knowledge article for a defined group of intents within an acceptable time” is more testable. The team can ask which dataset represents those intents, which baseline applies, how usefulness is judged, which error types matter, whether results differ across relevant contexts and what operating cost accompanies the result.

Evaluation is not one score. Product usefulness, model behaviour, user experience, operational reliability, latency and cost may move differently. A team needs to decide which dimensions are decision-critical and how trade-offs will be made. The product manager's task is to connect the measurement plan to the product promise, not to select a metric merely because a tool exposes it.

The distinction between pre-release and post-release evidence is equally important. Controlled evaluation can support a launch decision, but real use may introduce new inputs, workflows and behavioural effects. Monitoring should therefore test whether the assumptions behind the decision continue to hold. Feedback from users, incident patterns, cost changes and shifts in input data can all justify a new product decision.

Finding 6: the role is senior-weighted and cross-functional

Thirty-seven vacancies are coded senior, 29 lead or principal, two director and one executive or head. Together they account for 69% of the sample. Two records are associate and 29 are manager-unspecified. The evidence supports describing the sample as senior-weighted, while the geographic and access biases prevent a broader conclusion about the profession.

Substantial ownership is understandable given the interfaces in the work. AI product decisions can affect customer experience, operations, product economics, data use, model behaviour and support processes. The product manager may need to coordinate business owners, users, designers, software engineers, data and model specialists, operational teams and decision-makers. These groups often use different evidence and vocabulary.

Cross-functional work is not simply meeting coordination. The product manager has to expose dependencies and decision rights. Who defines the target outcome? Who can confirm the source data? Who owns model or service performance? Who decides whether an unresolved failure is acceptable? Who supports users after launch? Who can pause or restrict the capability? Without clear answers, a team can be active without being aligned.

This has two implications for role preparation. First, learners need artifacts that create shared meaning: a concise outcome statement, definitions, evidence register, dependency map and decision log. Second, they need communication practice. An executive brief should explain value, uncertainty, trade-offs and the requested decision without pretending that every technical detail is settled. A delivery brief should translate that decision into owners, evidence, gates and next actions.

The seniority evidence does not justify promising a learner a senior role. It does justify teaching the quality of judgement and traceability visible in work with substantial ownership.

Finding 7: agents and platforms widen the product boundary

Fifteen titles contain agent, agents or agentic as whole-word forms. Seven titles contain platform. The categories overlap, and they are not a complete title taxonomy. They show two visible ways in which AI product management can extend beyond a single feature.

An agentic workflow may select tools, take multiple steps, maintain context or initiate actions. Product discovery must therefore examine the whole task and the points at which errors can compound. Evaluation may need to inspect the quality of a final outcome and the path used to reach it. Product boundaries can include permitted actions, tools, data sources, stopping conditions, human review and recovery when an action fails.

A platform role has a different customer structure. Its direct users may be internal product and engineering teams that build downstream experiences. The platform product manager needs to consider reusable capability, interfaces, documentation, enablement, reliability, cost visibility and adoption. A platform can be technically available yet fail as a product if internal users cannot understand when and how to use it.

Both specialisms expand lifecycle responsibility. Changes in a model, service, tool, data source or integration can affect multiple products or action chains. The product record must make consumers, dependencies, evaluation evidence and change communication visible. This does not imply one preferred architecture. It means that product scope should include the operating system around the AI capability, not only its demonstration.

Finding 8: the strongest pattern is combination, not a single skill

The exact coding combinations are revealing. Sixty-six vacancies contain all five codes. Fifteen contain strategy, delivery, responsible delivery and technical fluency without a discovery code. Fourteen contain strategy, discovery, delivery and technical fluency without a responsible-delivery code. Four contain strategy, delivery and technical fluency. One contains strategy, discovery, responsible delivery and technical fluency without delivery.

This distribution resists a simplistic definition. AI product management is not only strategy, only experimentation, only technical translation or only risk coordination. Its operating shape comes from joining these areas around one product decision. Weakness at an interface can undermine strength elsewhere. A well-evaluated model can address an unimportant problem. A valuable use case can fail through poor delivery. A launched feature can become difficult to manage if monitoring and escalation were never designed. A cautious process can still fail if it never produces a usable product decision.

The combination suggests that practical learning should use one continuous case rather than isolated mini-exercises. A learner can begin with a problem and baseline, perform discovery, compare alternatives, define the AI product boundary, identify data and technical dependencies, design evaluation, document responsible-delivery decisions, prioritize a roadmap, prepare release evidence and design monitoring. Each artifact should update the same decision context.

This approach also makes contradictions visible. If the discovery plan says the critical outcome is reduced handling time but the evaluation plan measures only answer similarity, the artifacts do not reconcile. If the release review claims that human escalation is essential but the workflow design has no owner or channel, the control is not operational. Learning to find and resolve these gaps is more valuable than memorizing disconnected terminology.

A practical operating interpretation

The vacancy evidence supports six recurring work areas. They are presented as an original research synthesis, not as a standard or proprietary framework.

1. Frame the outcome and decision

Start with the user, workflow, problem, current baseline and intended effect. State the decision being made and the evidence needed. Name important constraints, including time, integration, cost, data and acceptable product boundaries. A precise frame prevents the team from treating an available model as proof of a valuable product.

2. Discover the problem and compare interventions

Gather evidence from users and operations. Test assumptions about frequency, severity, behaviour and value. Compare AI with non-AI interventions against the same outcome. Decide whether to proceed, narrow, redesign or stop. Record what remains uncertain.

3. Shape the technical product

Translate the chosen use case into capability, data, model or service, integration, latency, cost, lifecycle and operational questions. Define what is inside and outside the product boundary. Make dependencies and specialist owners visible without pretending that the product manager replaces them.

4. Define evaluation and responsible operation

Turn the product claim into measurable questions. Identify useful behaviour, important failure modes, evidence sources, thresholds, human involvement, monitoring and escalation. Link unresolved issues to an owner and decision. Do not present this record as proof of compliance or safety.

5. Deliver, launch and support adoption

Prioritize work by outcome and evidence, not novelty. Connect requirements to dependencies, evaluation stages and release conditions. Prepare users and support teams. Record the decision to launch, limit or delay and the reasoning behind it.

6. Monitor, learn and change

After launch, review user outcomes, behaviour, cost, failure signals and feedback. Check whether the assumptions behind the product decision still hold. Decide whether to improve, constrain, pause or retire the capability, and preserve the evidence for the next review.

These areas form a loop because post-launch evidence can change the original problem framing, not merely generate another backlog item.

What this means for professionals

For people preparing to work in AI product roles, the study suggests that a portfolio should demonstrate integrated judgement. A collection of interface mock-ups or generic roadmap slides cannot show how a person handled technical and behavioural uncertainty. More useful evidence would explain the problem, alternatives, assumptions, product boundary, evaluation logic, trade-offs, delivery plan and monitoring decision for one coherent case.

The work should distinguish verified facts from calculations, estimates, assumptions and unanswered questions. This is especially important when using AI tools during analysis. A generated summary can help organize material, but it is not a source. The professional remains responsible for evidence provenance, definitions, decisions and communication.

Prompts can be practical working aids when they contain a complete sanitized context. For example, a learner can ask an AI assistant to challenge the evidence behind a fictional use case, separate claims from assumptions, identify missing decision fields and propose questions for the relevant owner. The prompt should clearly mark which fictional context the learner may replace with a real but sanitized work context. It should not include personal data, credentials, confidential contracts, security details or restricted company material.

Professionals should also practice saying no. A defensible product manager may recommend a non-AI solution, a narrower scope or a delayed launch. Evidence-led restraint is compatible with innovation because it concentrates effort where the product can create useful value under manageable conditions.

What this means for organizations

Organizations hiring AI product managers can use the findings as questions, not as a universal job template. Is the role expected to own one feature, a product, a platform or a portfolio? Which business and user outcomes are in scope? What technical decisions must the person shape, and which remain with specialists? Who owns evaluation evidence? What responsible-operation boundaries apply? Who can approve, limit or stop a release? What happens after launch?

Clarity matters because titles alone do not resolve these questions. The sample contains manager-unspecified, senior, lead, principal, director, associate and head classifications. Agentic and platform titles further widen the role. A vacancy that names every desirable skill without specifying decision scope can attract candidates while leaving operating ownership ambiguous.

The organization should also consider the interfaces around the role. Product managers cannot create reliable source data, model evidence, operational support or delegated authority by themselves. They can coordinate these elements only when owners, access and decision paths exist. Hiring for the role without designing those interfaces may transfer organizational ambiguity to one person.

Finally, the organization can assess work through traceability rather than confidence. Can the product manager connect a roadmap item to a user problem and business outcome? Can the person explain why AI was selected over alternatives? Can evaluation evidence be traced to the product claim? Are release conditions, unresolved issues and post-launch signals connected to owners? These questions focus on operating quality without claiming a one-size-fits-all process.

Implications for applied education

The vacancy evidence supports a course design with strategy, discovery, technical translation, responsible delivery and execution woven through every module. Twenty substantial lessons can cover distinct subtopics while one fictional company case provides continuity. Each lesson should advance the case rather than repeat a generic explanation of uncertainty or governance.

A coherent sequence might move from product mandate and outcome framing through problem discovery, alternative comparison, user research, capability boundaries, data and model dependencies, evaluation, economics, failure analysis, human involvement, prioritization, delivery design, release evidence, adoption, monitoring and portfolio review. Before drafting, each lesson should have three to six unique subtopics so overlap can be detected at the curriculum level.

The practical section of each lesson should begin after the fictional case and theory have established a clear work problem. A reusable template should be explained first, then shown completed with the case data. Prompts should be fully written for the fictional company, visually consistent and easy to copy as ordinary italic text. The context that a learner may replace should be visible, readable and complete. Generated answers need not be simulated; learners can use the prompt and evaluate the output themselves.

The capstone can combine the artifacts into an AI product operating dossier: outcome and discovery evidence, alternatives, product boundary, technical dependencies, evaluation, responsible-operation decisions, roadmap, release review, monitoring and executive recommendation. Learners can self-assess the dossier against supplied completion criteria. Such an outcome demonstrates structured professional practice without claiming external certification, legal approval, technical assurance or guaranteed employment.

Limitations

First, this is a point-in-time study. Vacancies were current on 21 August 2026 and may close or change afterward. “Current” applies to the retrieval date, not to the date on which a reader later encounters the report.

Second, the corpus is purposive rather than statistically representative. The research sought strict suitable records and stopped at the required denominator of 100. It does not estimate the total number of AI product-manager vacancies or their share of all product roles.

Third, the geographic distribution is skewed. North America accounts for 71 records. Public English-language pages, the queried ATS boards and employer hiring patterns shaped access. The study cannot compare regional demand.

Fourth, source-channel concentration matters. Ninety records come from three first-party ATS families. Organizations using other platforms, local-language recruitment or private search are not proportionally represented.

Fifth, the acceptance rule creates selection effects. Strategy and technical fluency are universal partly because material AI product ownership was required. The 100% result should not be generalized to every role carrying a product- manager title.

Sixth, the five codes compress varied descriptions into transparent analytical categories. Coding supports comparison but involves judgement. Another research team using different boundaries could classify some edge cases differently.

Seventh, the preserved duty excerpts are intentionally short. They protect against bulk reproduction and provide evidence anchors, but they cannot represent every duty. The absence of a keyword from an excerpt is not evidence that the full vacancy omits the concept.

Eighth, employer labels were normalized from public boards, and legal entities were not independently verified. The 67-employer figure is a label count, not a corporate-group count.

Ninth, vacancies describe requested work, not verified organizational practice. The study does not establish that every accepted employer performs each coded activity effectively or grants the title the same authority.

Tenth, the report makes no causal claim. Vacancy counts do not demonstrate actual hiring, applicant success, salary levels, career progression, course sales, technology adoption or business performance.

Finally, the report makes no legal, compliance, safety, audit, assurance or certification conclusion. Product teams should involve appropriately authorized specialists when a decision requires expertise beyond product management.

Conclusion

The operating shape visible in 100 current vacancies is integrative. Strategy and technical fluency appear together in every accepted record, delivery in all but one, responsible delivery in 82 and discovery in 81. Two-thirds combine all five coded areas. The sample is senior-weighted and contains visible agentic and platform specialisms.

These findings support a practical definition: AI product management is the work of connecting a valuable problem to a bounded AI-enabled product, translating between user, business and technical evidence, carrying the decision through delivery, and learning from operation. The product manager does not eliminate uncertainty or replace specialists. The role makes uncertainty, dependencies, trade-offs and decision ownership usable.

For professionals, this means demonstrating a coherent chain from problem to evidence to product decision. For organizations, it means designing clear role interfaces and evaluating traceability rather than confident claims. For applied education, it means teaching one continuous operating case in which strategy, discovery, technical shaping, evaluation, responsible delivery, launch and monitoring reinforce one another.

The conclusion remains bounded to this evidence: 100 public vacancies current on one retrieval date. It is a practical signal about described work, not a forecast of the labour market or a promise of career outcomes.

Research note

This original report was prepared by MTF Institute Research Team from the immutable corpus accepted-vacancies-2026-08-21.tsv and its deterministic validation artifact. The website draft contains aggregate analysis and original synthesis only. No employer job description, logo, screenshot or proprietary framework is reproduced.