AI Product Card
Purpose
The AI product card is the single record for a reusable AI product in the portfolio. It shows which task class the product covers, who owns it, which initiatives use it, what maturity stage it is in, and which constraints must be considered.
The card is not a technology description. It supports a management decision: launch the product, pilot it, scale it, evolve it, merge it with another product, or retire it from the portfolio.
When It Is Used
The card is used when:
- a recurring task class may deserve its own AI product;
- initiatives are routed to an existing product;
- a product moves from pilot to the managed operating loop;
- the team needs to identify duplicate products;
- the product is reviewed in an AI product portfolio ritual;
- the team prepares a decision at a product lifecycle stage gate.
Who Owns It
The primary owner is the AI product owner. This role owns product purpose, target audience, supported use cases, metrics, constraints, and evolution.
Supporting roles:
- product portfolio lead — manages the product's place in the portfolio and duplicate prevention;
- technical owner — owns architecture, integrations, quality, security, and operational readiness;
- use case owners — confirm that the product solves real tasks;
- support team — records support model, incidents, and constraints;
- AI office — checks card completeness and product stage-gate decisions.
Inputs
The card needs:
- repeated business requests or a set of initiatives;
- task class description;
- expected users;
- selected or expected delivery track;
- data, security, and integration requirements;
- pilot or hypothesis-validation results;
- first usage, quality, and impact metrics;
- owner decision about the next step.
Card Structure
| Block | What it records | Why it matters |
|---|---|---|
| Identification | name, product type, maturity status, creation date, catalog link | Makes the product visible as a portfolio entity |
| Task class | which recurring tasks the product covers and does not cover | Prevents the product from becoming a generic tool for everything |
| Target audience | roles, teams, departments, typical users | Shows who should use the product |
| Owners | AI product owner, technical owner, support, adjacent functions | Makes decision rights and support clear |
| Use cases | supported use cases, pilot use cases, prohibited use cases | Routes initiatives into the product deliberately |
| Delivery track | onboarding or development route, artifacts, participants, stage gates | Connects the product to initiative delivery |
| Risk profile | data, access, decision impact, integrations, regulatory constraints | Makes control proportional to risk |
| Readiness | pilot status, instructions, support, monitoring, onboarding rules | Shows whether the product can scale safely |
| Metrics | usage, quality, cost, impact, reuse | Evaluates the product by evidence, not access availability |
| Decisions | launch, scale, rework, merge, retire | Keeps product management history transparent |
Maturity Statuses
| Status | What it means | Next decision |
|---|---|---|
| Candidate | A recurring task class exists, but the product is not formalized yet | Launch a pilot, extend an existing product, or reject |
| Pilot | Product applicability is being tested on limited use cases | Scale, rework, repeat the pilot, or close |
| In operating loop | The product has an owner, usage rules, support, and portfolio place | Connect initiatives and measure usage |
| Scaling | The product is expanding to new teams and use cases | Stabilize support model and impact metrics |
| Evolving | The product is improved based on demand and feedback | Update roadmap and backlog priorities |
| Merged / retired | The product is no longer needed as a separate entity | Migrate users, close risks, and record the decision |
Card Stage Gates
| Stage gate | What is checked | Possible decision |
|---|---|---|
| Is there a product hypothesis? | Recurring task class, target audience, owner, distinction from existing products | Launch a product candidate or implement as a one-off initiative |
| Is the pilot confirmed? | Real usage, result quality, constraints, first metrics, user feedback | Scale, rework, repeat the pilot, or close |
| Is the product ready to scale? | Support, documentation, security, onboarding rules, metrics, technical robustness | Move into the managed loop or return for rework |
| Should the product remain in the portfolio? | Active usage, confirmed value, support cost, duplication, technology relevance | Keep, merge, replace, or retire |
Minimum Fields
The minimum card answers ten questions:
- Which task class does the product cover?
- Which use cases are supported?
- Which teams and roles is it for?
- Who is the AI product owner?
- Who is the technical owner and who supports it?
- Which delivery track is used to connect initiatives?
- Which data, access, and integrations are needed?
- Which constraints and risks are known?
- Which metrics show usage, quality, and impact?
- Which decision was made at the last stage gate?
Quality Bar
A good card:
- describes the product through a task class, not only technology;
- shows owner, users, and onboarding rules;
- links to initiatives already using the product;
- records risk profile and usage constraints;
- tracks usage, quality, cost, and impact metrics;
- keeps decisions about pilot, scaling, evolution, or retirement.
A weak card:
- describes only a tool or vendor;
- does not show which initiatives use it;
- has no owner or technical accountable role;
- does not record constraints and prohibited use cases;
- does not show whether the product is used in real work;
- does not help decide whether to evolve or retire the product.