Product Guide

Build something that helps

AI can help you produce work quickly. You still need to know whether it solves a worthwhile problem, whether the result is trustworthy and who will look after it.

This guide helps a non-technical Product Owner develop reliable products that are fit for use. Start with the people and outcome, try a small part, learn from the result and decide what to do next.

You do not need to be a software developer to use it. A product may be a service, report, policy, learning resource or internal workflow. The guide applies when AI helps create or run the work, even if the finished product contains no AI.

You decide the purpose, priorities and whether the result is useful. Delivery and review check technical correctness. You can delegate within agreed limits without reading code or supervising every AI action; important unresolved choices must return to you.

It uses the shared principles in the AI Product Flow Framework and works within your existing way of planning, delivering and supporting products.

Know what this product is responsible for

A product serves a need for particular people. Name its purpose, the people it affects and the result you want. Make clear what it owns, what it needs from elsewhere and what is outside its scope.

Invented example: a service organisation wants customers to receive correct answers without repeating their requests. One product helps staff record requests; other services provide knowledge and responses.

Do not assume every capability needs its own application or team. Revisit the product boundary when you learn more about users, ownership and support.

A bet commits limited time, money or effort to answer a question. Name its owner, limits and stop condition. For example: “Can an AI summary preserve everything staff need to help this customer?”

Use a small test before making a larger commitment. Your existing work list, delivery process and release rules still apply. AIPF makes the AI use, evidence and decisions clear within that work.

Five questions to keep close

1. Who needs help, and what would improve for them?
2. What are we assuming, and what could show us we are wrong?
3. What is the smallest useful next step?
4. Does the result meet its purpose, including when something goes wrong?
5. Who can accept it, support it or stop it?

Ask these questions for a new product and for an important change. Match checks to the consequences of failure. Explain why lighter checks are enough for a small, reversible edit.

Five habits that matter when using AI

Start with the need

Talk with or observe people who experience the problem. Include staff, customers and people affected by the outcome. Consider a smaller change, an existing service or no new build.

This is Judgement: choose what is worth doing before asking AI to produce more of it.

Look for facts that could change your mind

An AI summary can sound convincing while repeating an unsupported assumption. Keep observations separate from estimates, interpretations and invented examples. Find the original source and note what it cannot tell you.

This is Evidence: test the idea against something that could contradict it. Several AI tools agreeing is not, by itself, an independent check.

Keep the next step manageable

Allow time to do the work, check it, connect it with other work and support it. Limit how much is active at once. Finish or stop work before the checking queue becomes unmanageable.

This is Restraint: commit enough to learn the next useful thing. Do not keep going just because you have already spent time on it.

Name the person responsible for use

A result can work in a test and still be costly or difficult to run. Include user needs, quality, rights, disclosure, security, support, recovery and ongoing cost in the decision.

This is Accountability: a named person remains answerable for the product, acceptance and any public claims. The maker must not be the only person or system judging the result.

Change the work when you learn

Users, sources, AI models and costs can change. Revisit a decision when its supporting facts no longer hold. Record what changed as a result of learning.

This is Adaptation: use findings to improve the product or way of working. Collecting lessons without acting on them is not enough.

Work through three questions, then decide

AIPF names three phases. They describe the evidence needed for a decision, not a fixed set of meetings. Activities can overlap or repeat.

“Prove” means collect evidence for the chosen question; it is not a promise of certainty. “Operationalise” means put the people and support in place to keep using the result.

Each phase ends with a gate: a decision by someone with authority. The decision returns to the work as a clear action, owner, limits and next review.

Other decisions are available at every gate. A stop condition can interrupt work at any time. Existing delegated decisions stay with their owners; sharing results does not create a second approval requirement.

AI Product Acceptance, also called “Done, Done” (done, and accepted for use), means that an authorised person accepts a specific result for a stated use, with evidence, limitations and support responsibilities recorded. “Generated”, “reviewed” and “passes a test” each describe progress. None alone means accepted. Resolve known defects that could materially affect the intended use and explain remaining limits. No process guarantees a product has no bugs.

Acceptance can be reopened by an incident, poor results, changed information, a cost increase or changed AI behaviour. An MVP is usually built after a Gate 2 Proceed and judged at Gate 3. Phase 3 can also end in Stop, so completing it does not by itself mean you have an MVP or have finished learning.

Make each responsibility someone’s job

An accountability means someone remains answerable for the result. Keep the six responsibilities below clear. You do not need six new posts.

The product decision-maker may be a Product Owner, product manager, founder or another authorised person. Name that person. Name specialists for decisions needing their expertise. If evidence is insufficient, seek help, narrow the intended use or stop.

One person may hold several responsibilities. Independent review must still provide a real check; the maker cannot be the sole accepter. A reviewer AI may help, but model agreement alone does not prove independence. The reviewer needs time, competence and authority to challenge the work.

Keep eight useful records

AIPF calls these records artefacts. Use notes, prototypes, test results or existing tools to show the purpose, results and decisions. Separate documents are optional.

Keep the detail needed for the decision and link to original sources. Use the same references in family and portfolio views. Avoid maintaining three different copies of a fact.

Why this product exists — Product Intent

State who needs the product, the problem, expected benefit, boundaries and signs of success. Explain how it contributes to a wider service, family or bet where relevant. Include dependencies and exclusions. Agree examples of correct and unacceptable results.

Write the idea clearly enough that a result could show it is wrong. Example: “Help staff record requests accurately without making customers repeat them.” Compare this with observed needs before treating it as established demand.

What we know and need to test — Assumption and Evidence Map

List important assumptions, sources, dates, owners, supporting and contrary findings, context and uncertainty. Separate observations from estimates and AI suggestions. Check new assumptions before relying on them, especially those affecting purpose, results, cost or safety.

Name at least one result that would defeat the idea. AIPF calls this a falsifier. Choose the cheapest useful test that could find it and say which decision it would change.

Example: if summaries regularly omit important exceptions, this approach may not be suitable for the service.

Show the intended experience — Concept Artefact

Show the idea before building it. Use a sketch, short story, sample report, role-play or mock-up. A reader should be able to react without reading a technical specification.

Use simple personas to describe people’s needs and constraints, and journey maps to show steps and handoffs. Check assumptions with relevant people. AI-created personas are not interview findings.

Example: a customer explains an unusual request once; staff find information and check the answer. They can return to the original request if the summary is unclear.

Show the whole intended experience alongside the small part you are exploring. Label what is included now, deferred, excluded or still undecided. A story map can place the next small piece of work beneath that whole journey.

Use the concept to clarify intent; keep it easy to change or discard. Reactions can reveal understanding or interest. A convincing simulation does not prove demand or that the product can operate.

Compare ways forward — Roadmap Options

Present more than one credible option. For each, show the next question, smallest useful step, dependencies, estimated effort and cost, checking and support needs, exclusions and review condition.

Example: improve the request form, try an AI summary, or keep the existing process while collecting better evidence. Compare the benefit and cost of learning, not just feature lists.

Separate estimates, approved commitments and actual spending. Link the chosen option to its decision. A preferred roadmap is not an approved budget.

Set the rules around AI — AI Model Harness

Record what AI may do, approved information, which checks run and when, who reviews them, and what must stop or return to the owner. Recheck affected work after changes.

Example: AI may draft a summary using approved information. Staff can inspect the original, correct errors and stop use when important information is lost. See “Keep AI use within clear rules” below.

Try one connected part — End-to-End Evidence Slice

Test the smallest real or representative path that answers the next important question. Include what happens when it fails, unusual cases and recovery. Mark any simulated parts so readers know what the test does not establish.

Record the tested version, question, comparison, cases, pass/fail criteria, method, results, limits and reviewer. Tests support only the claims they examine. Check against original sources or separately established examples: implementation and tests can share the same mistake.

Example: take a request through summary creation and staff checking. Include a request with an exception and a case where the AI cannot give a useful summary. Check whether staff can recover using the original.

Older material may call an evidence slice a steel thread. It need not be ready for release. An MVP, or Minimum Viable Product, must be usable for its intended user test. An attractive demonstration is not automatically either one.

Record what was accepted — Acceptance Record

Record the version, permitted use, accepter and authority, evidence, limits, conditions and next review. Link affected products, family and bets.

Give the owner a demonstration and a plain-English summary of checks, unresolved issues and support arrangements, with links to evidence.

Keep acceptance, funding commitment, release, wider reuse and permission to scale distinct, as the Framework’s decision states require. They may use the same evidence but have different owners. The maker cannot be the sole accepter.

Example: the summary is accepted for a staff-supervised trial of routine requests. Urgent requests and automatic sending remain excluded.

Record what learning changed — Learning Record

Explain the finding, what decision, rule or practice changed, who owns the change and who else is affected. Keep previous versions when evidence is corrected. Ask affected owners to revisit their decisions.

Example: exceptions were lost in summaries. The team changes the prompt, adds cases to its tests and tells the response-service owner which earlier results need rechecking.

Keep AI use within clear rules

The AI Model Harness means the working rules and checks around AI, using approved tools, access and policies. It need not be a new platform. Validation must operate during the work without requiring constant owner supervision.

1. Before starting, agree success checks, limits, review points and who runs the checks. AI agents or automated testing tools can run routine checks without a second person. Independent review and acceptance still need a capable person with the authority to challenge the work.
2. At each review point, compare results and assumptions with the intent and sources before further work relies on them. Use tests and independent challenge.
3. Correct technical errors within scope and rerun affected checks. Pause dependent work when a check fails or important evidence is missing.
4. Bring unresolved choices about purpose, scope, important assumptions or acceptable risk to the owner, with options and a recommendation. Record the decision before resuming affected work.

Check the harness itself with a known error or unsupported assumption in a safe test. Confirm it detects the problem and stops dependent work. Fix missed checks; one successful test does not prove complete coverage.

Some tools use skills for repeatable instructions, plugins to connect tools or information, and agents to carry out work. Their names do not grant permission. Changes to models, prompts, instructions, tools, sources or access may weaken previous evidence and require new checks.

Link important shared dependencies and permissions to the family and portfolio records. Name owners who can narrow, stop or restore use. A change to an AI tool must not quietly inherit acceptance for a different version.

More automatic action can be allowed when evidence and controls justify it. Keep purpose, investment, important risks and gate decisions with accountable people. Automatic acceptance still needs checks that can detect the producing system’s mistakes, plus sampled human inspection by capable reviewers. Incidents or worsening results can require less automation.

Automatic acceptance here means pre-authorised routine checks within a named boundary. It does not allow AI to take ownership of a gate, investment or material-risk decision. Record who authorised that boundary, which uses it covers and when it must return for human judgement.

Connect this work to the wider decisions

The Product Family Guide helps related products work together. The Portfolio Guide helps choose which work receives resources. A product can connect directly to the portfolio when no shared family decision is needed.

Send the relevant owner the result, sources, limits, costs, benefits and proposed next step. Record the decision that comes back: allowed scope, conditions, owner and review point. Update the work list and checks accordingly.

Example: a further summary trial may require human review and an agreed handoff. Record both conditions. Permission for a trial does not prove wider customer benefit.

Use the Framework’s shared information checklist and phase handoffs when preparing these records.

Take one useful next step

Choose a need, show the intended experience and identify the question most likely to change your plan. Test a small part, discuss what happened and act on the result. Repeat as needed.

Use existing agile routines: an ordered work list, short cycles, conversations with users and reviews of how the work could improve. Add a record or meeting only when it helps someone act, decide or meet a real obligation. AIPF can work with Scrum, Kanban, lean and existing delivery and operations practices.

Sources

Further reading

Atlassian’s user-story guide shows how short, non-technical descriptions explain who needs something and why. Atlassian Agile introduces learning through small steps and feedback. These are reading aids, not required templates or tools.

The LeSS framework and Nexus Guide inform attention to the whole product and connections across teams. AIPF’s three decision levels do not prescribe their team structures or events.

The original structure drew on the Scrum Guide by Ken Schwaber and Jeff Sutherland. The evidence-slice approach also draws on direct and second-hand observation of major Australian Government IT projects with substantial cost and delivery difficulties.

Acknowledgements

Authors

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

Licence

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