Skip to main content

Roles

Why roles are needed in the AI product portfolio​

In many companies, AI is adopted through separate initiatives and pilots. For each use case, a separate solution, a separate integration, a separate team, and a separate approval process are created.

At an early stage, this is fine: the company experiments, looks for where AI applies, and tests hypotheses.

But when scaling, a problem arises:

  • pilots start duplicating each other;
  • different teams solve similar tasks with different tools;
  • products appear without owners;
  • no one is responsible for evolving the internal AI landscape;
  • the business does not understand which tool to use for its task;
  • IT and security are overloaded with one-off requests;
  • it is hard to scale the impact of AI.

That is why a company needs a dedicated loop for managing the AI product portfolio.

Its task is not just to launch initiatives, but to form a set of internal AI capabilities that can be reused across different business scenarios.

What an AI product is in this model​

An AI product is not a one-off pilot or a standalone automation for a single team.

An AI product is a reusable internal capability through which different departments can solve typical tasks with the help of AI.

Examples of AI products:

  • a corporate LLM;
  • a RAG service for searching a knowledge base;
  • agents (Hermes, OpenCode);
  • agent orchestrators (Multica, Paperclip);
  • a code agent for development;
  • an ML platform;
  • a library of ready-made AI components and integrations.

An AI product becomes a full-fledged product only when it has:

  • an owner;
  • users;
  • use cases;
  • connection rules;
  • a lifecycle;
  • metrics;
  • support;
  • a clear role in the portfolio.

Key roles​

1. Product portfolio lead​

The product portfolio lead is responsible for all of the company's AI products.

Their task is not to manage each product hands-on, but to ensure that the portfolio evolves deliberately: which products the company needs, which already exist, which are worth piloting, which to scale, and which to retire.

Area of responsibility:

  • shapes the AI product portfolio strategy;
  • determines which classes of products the company needs;
  • manages the portfolio roadmap;
  • helps decide which products to launch, buy, evolve, or decommission;
  • ensures products do not duplicate each other;
  • connects the product portfolio with the AI initiative portfolio;
  • is responsible for transparency: which products are available, for which tasks, and at what maturity stage;
  • participates in prioritizing product pilots and enhancements;
  • aligns product evolution with infrastructure, security, architecture, and the business.

The role's key question:

Which AI products should the company have so that the business can launch valuable AI initiatives faster and more safely?

2. AI product owner​

The AI product owner is responsible for a specific product within the portfolio.

For example, for a corporate LLM, a RAG platform, a code agent, an ML platform, a meeting transcription service, and so on.

This is a key role, because without an owner a product quickly turns into "a tool that someone once deployed."

Area of responsibility:

  • describes the product's purpose;
  • defines the target users;
  • forms the product hypothesis;
  • manages the backlog;
  • gathers needs from business teams;
  • organizes pilots;
  • analyzes feedback;
  • makes decisions about evolving the product;
  • is responsible for product adoption;
  • tracks user value;
  • participates in calculating the impact of using the product;
  • prepares materials for training and onboarding users.

The role's key question:

Who is this AI product for, what tasks does it solve, and why should the business use it?

3. Technical AI product owner​

The technical owner is responsible for ensuring the product is not only useful but also technically robust.

They are responsible for the architecture, integrations, quality, security, performance, operations, and the technical feasibility of product solutions.

In small teams, this role may be combined with the infrastructure lead or a senior developer. In a mature model, it is a separate area of responsibility.

Area of responsibility:

  • defines the product's technical architecture;
  • is responsible for integrations with corporate systems;
  • manages data requirements;
  • is responsible for quality and stability;
  • participates in choosing the technology stack;
  • assesses technical risks;
  • enforces compliance with security requirements;
  • ensures the product's readiness for production operations;
  • helps the product owner assess the complexity of enhancements;
  • participates in incident reviews and analysis of technical constraints.

The role's key question:

Can this product be used safely, stably, and at scale inside the company?

4. Pilot owner​

The pilot owner is responsible for validating an AI product with a specific business team or a specific set of scenarios.

For example, a company pilots a RAG service in the legal department, a code agent in the IT team, a Multica/Paperclip-like tool in the AI function, and an automation platform in the operations unit.

The pilot owner connects the product team, the business users, and the success criteria.

Area of responsibility:

  • defines the goal of the pilot;
  • selects the pilot team;
  • records the value hypothesis;
  • describes the validation scenarios;
  • agrees on the success criteria;
  • organizes feedback collection;
  • records constraints and risks;
  • prepares conclusions from the pilot;
  • proposes a decision: scale, rework, repeat the pilot, or close.

The role's key question:

Has the pilot proven that the product is useful, applicable, and ready for the next stage?

5. Scenario business owner​

The scenario business owner is responsible for the specific business task on which the AI product is validated or used.

They do not own the product itself, but they own the problem, the process, the users, and the expected value.

For example:

  • the legal unit wants to search for similar contracts;
  • the risk unit wants to find similar operational-risk events;
  • HR wants to automate resume processing;
  • the IT team wants to speed up development with a code agent;
  • support wants to automate responses to users.

Area of responsibility:

  • formulates the business problem;
  • describes the current process;
  • provides domain expertise;
  • helps define quality criteria;
  • allocates users for the pilot;
  • participates in testing;
  • confirms or refutes the value;
  • helps assess the impact;
  • decides whether the scenario is ready for rollout in their own area.

The role's key question:

Does the AI product solve a real business task better, faster, or cheaper than the current way of working?

6. Support team​

The support team is responsible for ensuring the AI product keeps working after the pilot and rollout.

This is an important role, because many AI solutions die not at the development stage, but after the first launch: there is no support, no owner of changes, no update process, no incident response, no quality control.

Area of responsibility:

  • maintains the product in production operations;
  • handles user requests;
  • records incidents;
  • monitors availability and stability;
  • participates in updates;
  • controls quality degradation;
  • maintains a knowledge base for the product;
  • helps new users connect to the product;
  • passes feedback and enhancement requests to the product owner.

The role's key question:

Can the business use this product reliably every day without manual heroics from the launch team?

Distribution of responsibility across the product lifecycle​

StagePrimary roleSupporting roles
Product ideaProduct portfolio leadBusiness, infrastructure lead, architecture
Needs assessmentProduct portfolio leadInitiative owners, scenario business owners
Solution selectionProduct portfolio leadTechnical owner, security, IT
Pilot launchAI product ownerPilot owner, scenario business owner
Value validationPilot ownerScenario business owner, product owner
ScalingAI product ownerProduct portfolio lead, technical owner, training
Handover to operationsTechnical ownerSupport team, product owner
Product evolutionAI product ownerUsers, business, technical team
Product closureProduct portfolio leadProduct owner, architecture, security

How roles interact with the AI initiative portfolio​

The AI product portfolio and the AI initiative portfolio are two connected but distinct loops.

The AI product portfolio answers the question:

Which AI capabilities does the company have and how do they evolve?

The AI initiative portfolio answers the question:

Which business tasks do we solve with AI products and what impact do we get?

One AI initiative can use one or several AI products.

For example:

  • an initiative to speed up development may use a code agent and RAG over the internal knowledge base;
  • a document-processing initiative may use OCR, an LLM, and agent orchestrators;
  • a business-process automation initiative may use an LLM, RAG, and integrations with corporate systems.

That is why AI product owners must participate in routing initiatives.

Their task is to help understand:

  • which product fits the task;
  • whether a ready-made capability already exists;
  • whether a new product is needed or an enhancement of an existing one;
  • whether the task can be solved through an already existing functional block;
  • what constraints the product has;
  • which delivery track is needed for implementation.

Antipatterns​

1. A product without an owner​

A tool was deployed, a pilot was run, but after that no one is responsible for evolution, users, quality, and impact.

Result: the product gradually dies or is used chaotically.

2. A pilot instead of a product​

A team builds a solution for a single use case and calls it a product.

Result: dozens of non-reusable solutions appear that are hard to support and scale.

3. A product owner without authority​

The product has a formal owner, but they cannot manage the backlog, priorities, pilots, and evolution.

Result: the role exists on paper, but in practice no one manages the product.

4. The business does not participate in the pilot​

The AI function comes up with the scenarios itself, tests the product itself, and draws its own conclusions about value.

Result: the product works technically, but the business does not embed it into a real process.

AI products live separately, initiatives live separately.

Result: every new initiative again goes through the path of choosing a tool, approvals, architecture, and piloting from scratch.

The right model​

The right model is when every AI product in the company has:

  • an owner;
  • a technical owner;
  • a clear target audience;
  • a list of supported scenarios;
  • connection rules;
  • a lifecycle;
  • adoption and impact metrics;
  • a piloting process;
  • a handover-to-operations process;
  • a place in the overall AI product portfolio.

Then the AI function stops being a team that manually launches separate pilots and becomes a system that develops the company's internal AI capabilities.