Framework

The problem we need to solve

AI can help people produce ideas, plans and product changes quickly. Someone still needs to check whether that work is useful, trustworthy and worth continuing. Producing more work can leave less time to make those decisions well.

When AI produces work faster than people can judge it, approval can become a way to clear a queue. AIPF aims to keep evidence, human judgement and accountability effective as AI increases the speed, volume and autonomy of work.

AI Product Flow (AIPF) offers a simple response: start small, check what happened, and decide the next step. Give each piece of uncertain work a clear purpose, an owner and a limit. Increase the commitment when the results support it.

For example, an organisation wants to improve its customer service. AI can write an impressive plan or a quick answer. Neither shows whether customers get the right help. The organisation needs to test the complete experience, including the work people do to check and correct the answer.

AIPF is a proposed approach. Its case studies are still building evidence. Treat its use in your organisation as something to learn from and improve.

What AI Product Flow connects

AIPF connects three kinds of decisions:

• Portfolio: which work should receive our time, money and attention?
• Product family: how should related products work together?
• Product: does this product help people, and is it fit to use?

A product may be a service, a staff tool or a workflow, as well as software sold to customers. A family is useful when distinct products need shared decisions. Several teams working on one product do not automatically form a product family.

Use the guides alongside the way you already plan, build and run things. Keep useful agile practices: short cycles, ordered work lists, feedback from users and regular conversations about improving the work. AIPF adds clear questions, evidence and responsibility at the points where a decision matters.

Read this Framework for the shared ideas. Then choose the guide for the decision you face; you do not have to start every initiative at product level.

Treat uncertain work as a bet

A bet is a limited commitment to find out whether an idea is worth pursuing. It has a named owner, a question to answer and a condition for stopping. The word reminds us that the result is uncertain.

Before starting, write down:

• who needs help and what should improve;
• what you believe, and what you still need to find out;
• the smallest useful test and the result that would change your mind;
• the available time, money and people;
• who decides next, when they will review, and when the work must stop.

Example: allow a small team two weeks to test whether AI summaries help staff handle service requests. Include time to check the summaries. Stop the test if important facts are repeatedly missing. These are illustrative limits; choose limits that fit your situation.

A bet can fund research before any product is chosen. Record what the research found, including reasons not to proceed. Having invested in research does not automatically justify building something.

Value can mean better service, less risk, public benefit, revenue or meeting an obligation. Choose measures that fit the purpose.

Fund learning in increments

Commit enough resources to answer the next important question. Review the result before committing more. A useful test can support another step, suggest a change or show that the work should end.

Anyone may propose an idea. The people responsible for spending, information access, risk and live use still make those decisions. Funding a test does not give automatic permission to release a product or use restricted information.

In the service example, a promising summary test might justify a trial with a few staff. It does not yet justify use across every service. Record the next allowance and its conditions, such as continued human checking.

Stopping unsuccessful work preserves learning and frees people for something more useful. For required work, such as meeting an existing obligation, test better ways to meet it; the obligation itself remains. Existing budgeting and accounting rules still apply.

Manage live bets as a flow

Limit how much work is active at once. Count work waiting for review as well as work being produced. Reviewers, specialists and support staff all need enough time to do their part.

A simple work list can show ideas, allowed tests, work waiting for a decision and decisions made. Use your existing board or records if they already do this well. A work-in-progress limit is the maximum amount of active work the group agrees it can handle.

When reviews pile up, finish or stop existing work before starting more. Check whether old evidence is still reliable after a change to the product, information or AI tool.

Make a stop decision practical: tell the people affected, end the authorised work, deal with continuing service needs and retain what was learned. If you defer work, record who will reconsider it and what would trigger that review.

Three connected decisions

The three levels look at the same work from different viewpoints. They should use the same facts, with enough context to understand what those facts mean.

In the service example, the portfolio chooses whether to invest in better request handling. A family might bring together intake, knowledge and response products. Each product has a purpose and an owner. The family checks whether a request reaches a useful answer across all three.

Start with the whole intended experience before dividing the work into products. A journey map shows what a person is trying to do, the steps they take and where they need help. A simple product map shows which product supports each part. A value stream follows the work from the original need to its result; it can cross family boundaries.

Keep records short and connected. Each important result or decision needs a stable identifier, owner, date or version, source link and relevant limits. Products keep the original findings. Families add the effect across products. Portfolios use that information to choose the next investment. Count a shared benefit once.

Decisions travel back with the allowed scope, conditions and next review point. Product owners update their work lists and checks. If a source is corrected, identify the affected tests and decisions and ask their owners to reconsider them. Do not silently rewrite the history.

Three phases for learning and deciding

All three guides use the same three phases. The questions differ according to who needs to decide.

These are not Phase 1 at Portfolio, Phase 2 at Family and Phase 3 at Product. Each scope uses all three phases for its own decision. In Phase 2, Product tests a product path, Family tests a shared boundary and its suitability in participating contexts, and Portfolio uses the evidence those slices produce to judge the next investment; it does not run a product slice of its own. A separate evidence slice may test the portfolio process itself; that does not prove the investments it oversees.

A Concept Artefact makes an idea visible. It might be a sketch, storyboard or example of the intended experience. An artefact simply means a useful record or example of the work.

An End-to-End Evidence Slice, also called a steel thread, is a small working test across a complete path. For example: receive a request, find relevant information, draft an answer and have a person check it. The test may use representative conditions; record those limits.

A Minimum Viable Product (MVP) is a minimum usable product or release for learning with users. A narrow working test is not automatically an MVP. Several tests may be needed before a usable release is ready.

Each phase ends with a gate: a decision about the next commitment. The options are Proceed, Revise, Defer or Stop. A family can also Limit where something is shared or Split it into separate approaches. A portfolio can Merge overlapping bets or Rebalance resources between them. Scale is an option at Gate 3 when the evidence and readiness for wider use support it.

Each scope names one owner for its gate decision: the Product owner at product level, the Family owner at family level and the Portfolio owner, or a portfolio board acting for them, at portfolio level. Specialists advise within their expertise; the gate owner records the decision.

A bet’s phase and gate follow the bet’s own question. When one bet supports several products at different stages, record each product’s phase separately; the bet reaches its gate when the evidence answers the bet’s question. Merge and Rebalance affect several bets, so they can be made at any portfolio review and are recorded against each affected bet’s current gate.

Keep these decision states distinct in every record: progress (work done), evidence (what was found), recommendation (what someone advises), funding commitment (permission to commit resources), release (permission to make funds available or start the affected work), acceptance (a result accepted for a stated use) and permission to scale. One decision may grant several of these when the decision-maker has the authority and records each one.

These are learning cycles, not a requirement for three new committees. Use existing reviews where they fit. Routine work inside an agreed permission can continue. Changes to purpose, spending limits, important risks or acceptance go back to the responsible person.

Use AI to shorten the path to evidence

AI can help find questions, compare options, organise observations and prepare a decision note. Keep actual observations separate from AI suggestions, invented examples and forecasts. A confident summary still needs sources that someone can check.

The AI Model Harness means the working rules and checks around AI use. It explains what the AI may do, which information and tools it may use, what must be prevented, how people check results, how they notice problems and what must be rechecked after a change. The Product Guide explains these controls in more detail.

Controls apply wherever AI acts, including Portfolio analysis and Family coordination. Shared controls can be reused, but each use needs an owner, permitted actions, suitable evaluation and a way to detect problems and stop. This does not require three separate harness documents.

Name the people who can pause or narrow AI use. Greater automation needs suitable checks and evidence. People remain responsible for purpose, investment, acceptance and consequences.

Where the guides fit

AIPF does not require a new department, software tool or reporting hierarchy. It works alongside product management, agile delivery, finance, risk and operations. Keep existing responsibilities clear.

The guides help people decide and learn. They cannot by themselves establish that a product is secure, lawful or suitable for a particular service. Use the relevant specialist checks and operating requirements as part of the work.

The shared values are judgement, evidence, restraint, accountability and adaptation. In everyday language: think carefully, check what happened, limit the next commitment, name the owner and change course when needed.

Choose the guide for your next decision

For a broad initiative, start with the portfolio purpose and investment limits. Use the family view to outline the whole experience and related products. Then use the Product Guide to test each part. For a change within one existing product, begin there and involve the other levels when a shared or investment decision is needed.

All three levels use the shared information checklist and phase handoffs below. Use those common fields in existing records rather than maintaining separate copies of the same facts. The AI Portfolio Implementation Guide shows how to run the investment cycle with them, with a graphical overview and worked example.

Shared information and handoffs

Agree what each piece of information means

Use the same meanings at product, family and portfolio level. Link each fact to its agreed source; do not create competing versions in each guide or system.

For each field, agree its meaning, source, owner, unit, reporting period, update timing and permitted use. Say when it is unknown, not yet observed, not supplied or not applicable, with a reason. None of these states means zero or approved. Decide which gaps block a particular decision and which can stay within a limited test.

Connect records across the three levels

The activities below are suggested working steps within the three phases. Repeat or combine them as the work requires. They are not extra gates. The table shows a bet that supports one product; when a bet supports several products, its gate follows the bet’s own question.

Keep claims attached to their sources, context and limits. When something important changes, identify affected decisions and tell their owners. Preserve history. Pause or restrict affected work when its rules require it; unaffected work can continue.

Acknowledgements

Authors

Written by Rick Molony and Ghulam Akbar, with AI assistance.

Licence

This Framework is offered under the Creative Commons Attribution 4.0 International licence.