Make the whole experience work
Related products can help or hinder one another through shared information, services or scarce people. Customers should not have to repair the gaps, and sharing should allow differences that meet their needs.
This guide helps you decide what products share, how they connect and who handles problems between them. AI can spread a weak assumption through reused prompts, models or components.
Use it alongside the Product Guide and AI Product Flow Framework, within your existing teams and tools.
When do you need a product family?
A product family is a group of related products, services or workflows where a choice in one can help or harm another. They may serve the same people, use common information or rely on shared services.
Use a family view when shared choices need an owner. Products may retain different audiences, brands, channels and technology; shared content or review capacity can justify coordination without one application or customer journey.
Example used throughout: a service organisation wants people to get a correct answer without repeating their request. It may need intake, knowledge and response services. Each has a purpose and an owner. The family view shows how they fit together. This is an invented example, not a report of results.
A capability is something you need to do, not automatically a product or application. Establish its users, outcome and owner. Products may share an application; several teams may serve one product.
A value stream follows a need through to its outcome—for example, from asking for help to getting the problem resolved. It may cross more than one family. Use the journey to understand people’s experience and the family view to manage shared decisions.
Start with the whole outcome, then choose a small test
One experience, connected responsibilities
- Explain the needIntake servicePass on the request without losing its meaning.
- Find reliable informationKnowledge serviceSupply a current source and its limits.
- Resolve the requestResponse serviceCheck the answer and whether it helped.
Test one important connection firstCan the next service use the information correctly, including exceptions?
Write a short family outline as the opening section of the Dependency and Integration Map. Show the intended outcome, people affected, possible products, owners, shared needs and unanswered questions. Mark what the next test includes and what it leaves for later.
Use journey maps for experiences and handoffs, personas for people’s needs and context, and concept maps for information dependencies. Label untested personas as assumptions.
Link product intent, concept and evidence rather than copying them. The outline stays within the Dependency and Integration Map; the optional Pattern below serves a different purpose.
For a new family, agree boundaries and shared constraints before authorising its first product commitment. For a new product joining an existing family, check compatibility, capacity and effects on current products. Neither route requires completing the family’s whole lifecycle first.
Six habits for working across products
Judge the combined result
Check the whole experience with users and people on both sides of a handoff. Remove avoidable dependencies and duplicate work; retain differences that improve access or outcomes. This is Judgement: assess the combined result.
Check before reusing an approach
A pattern describes an approach to a recurring problem in a stated context. Different people, information, permissions or consequences may require Limit or Split. This is Evidence: test reuse in each new setting; agreement among AI tools does not establish it.
Count the cost of sharing
Include adoption, training, integration, review and support. Start with a small test. Past effort does not justify further investment; stopping a shared approach need not stop its products. This is Restraint: match commitment to evidence.
Keep shared work within people’s capacity
Integration means making the parts work together. Set a work-in-progress limit including checking and waiting decisions. Order work around scarce reviewers; coordination can itself become a bottleneck. This is Restraint: AI output cannot create review capacity.
Make the shared foundation dependable
The shared substrate is the common information, models, tools and checks. Name owners and recovery arrangements. Transfer drift means reuse changes meaning, behaviour or safeguards. This is Adaptation: recheck affected products when shared sources change.
Check who benefits and who carries extra work
Track benefit, cost, accessibility and harm in each product. Count a shared outcome once. Adoption or a working connection does not establish sustained value. This is Accountability: product owners answer for local effects; Integration maintains the combined view.
Decide what to share and what to do next
The three AIPF phases help you ask different questions. Each ends with a gate: a decision by someone with authority. Use existing reviews where they fit.
| Phase and everyday question | What the family makes clear | What returns to product owners |
|---|---|---|
| 1 — Validate, Show, and Set Boundaries. What should work together? | Outcomes, people, product boundaries, shared constraints, owners and next test. | Allowed product work, shared expectations, effort limits and review conditions. |
| 2 — Prove the End-to-End Evidence Slice. Does the connection work? | A test across a meaningful handoff, including failures and recovery in named settings. | Results, changes needed and where reuse is or is not supported. |
| 3 — Decide and Operationalise. How far should shared use go? | Benefits by product, shared costs, support and remaining risks. | Agreed uses, owners, limits, support and next review. |
An evidence slice tests a small connected path. A product slice tests its own use; a family slice tests a shared boundary or reuse claim in named contexts, including failure and recovery. “Prove” concerns that question; “operationalise” means prepare for ongoing use and support.
Before releasing dependent product work, the family gate must settle:
- product purposes, boundaries, affected people and important handoffs;
- required sharing and separation, including data permissions and shared architecture, tools and channels;
- owners, work order, capacity, cost, support and review responsibilities;
- the next evidence question, allowed effort, success checks, stop conditions and review trigger.
Resolve choices the next commitment depends on. For deferred choices, record an owner, decision trigger and any work held meanwhile. Keep these decisions in the five records; separate stack and roadmap documents are optional. State exactly which product discovery or test may proceed.
| Decision | What it means |
|---|---|
| Proceed | Take the next agreed step in shared work. |
| Revise | Change the approach, scope or assumptions. |
| Defer | Wait for a stated condition, with an owner and review trigger. |
| Stop | End the shared commitment and assign any remaining responsibilities. |
| Limit | Use the approach only in named products or settings. |
| Split | Use different versions where important differences require them. Name their owners. |
| Scale | Extend reuse when evidence and support justify it. Available only at Gate 3. |
The other decisions are available at every gate. A stop condition may interrupt work at any time. Record the scope, evidence, conditions, owner and next action for each decision.
Accepting a shared approach does not automatically accept it in every product or approve more spending. Each product still checks its own use. A changed source, AI model, incident, shortage of support or disappointing benefit may require another decision.
Give shared responsibilities named owners
Each product keeps the responsibilities in the Product Guide. Four family responsibilities cover the work between products. Accountability means someone remains answerable; it does not require a new job title.
| Existing AIPF name | In everyday work, this person makes sure… |
|---|---|
| Family | The shared outcome, priorities across products, trade-offs and the family gate decision have one owner. |
| Integration | The family outline stays clear, the parts fit, dependencies are reduced and the combined benefit is checked. |
| Coordination | People can find the work, evidence, decisions and problems; shared work stays within review and integration capacity. |
| Platform and Substrate | The common information, AI tools and controls are reliable, supported and safe to change. |
The Family owner holds the family gate decision. Specialists judge matters in their area; the gate decision still has one owner. One person may hold several responsibilities in a small family.
Record owners are named below. Coordination does not grant spending authority or override product acceptance.
Keep five core records; add a Pattern when useful
AIPF calls these records artefacts. Use existing views where suitable and one agreed source per fact. The family outline opens the Dependency and Integration Map. The optional Pattern records a reusable approach when that would help; it is not a sixth core commitment.
What must connect — Dependency and Integration Map
Show which product supplies what to another, and who owns each side. Include the information or service, its source and version, permissions and the checks needed before it is used. Say what happens if it is missing, unclear or wrong. Remove dependencies where you can.
Owner: Integration. Built from: the family outline and each product’s dependencies.
What everyone relies on — Shared Substrate Map
Show the shared tools, sources, models and checking services. Name owners, supported uses, capacity, costs and recovery arrangements. Identify changes that require product owners to recheck their use.
Owner: Platform and Substrate. Feeds: the Portfolio’s Model and Vendor Concentration Register and Autonomy Boundary Map.
Who moves and judges the work — Coordination Function Map
Show who supplies, updates, receives and judges shared records. Identify waiting decisions, available reviewers, active-work limits and when an issue needs a different decision-maker. Keep AI’s routing tasks separate from human decisions.
Owner: Coordination. Board movement or an agent’s completion message is not approval. Link dependent work to the recorded authority; test that missing or withdrawn authority stops it.
What reuse is supported — Cross-Product Evidence Ledger
For each important claim, keep a reference, source, date, method, setting, result, uncertainty and permitted reuse. Include contrary findings. Distinguish observed results, estimates and AI-generated material.
Keep earlier versions when a source or assumption changes. Mark what is no longer current, identify affected decisions and ask their owners to reassess. Pause or restrict affected use when its agreed risk rules require it. Unaffected work can continue.
Owner: Coordination maintains the view; source and product owners own claims. Built from: product Assumption and Evidence Maps, End-to-End Evidence Slices and Learning Records. Link Pattern versions to tested contexts and contrary findings.
Who gains and who pays — Family Benefits Map
Link the intended outcome to expected and observed benefit in each product. Keep the measure, starting position, period, owner and source. Show shared costs, local burden, harm and the basis for each product’s contribution. Do not add unlike measures or count one outcome repeatedly.
Owner: Integration; product owners own local results. Built from: product Acceptance Records and benefit measures. Feeds: the Portfolio’s Benefits Realisation Map.
What can be reused — Pattern (optional)
Create a Pattern when a recurring problem warrants a reusable approach across the family. It may cover experience, workflow, information, technology or AI controls. It can serve every product where applicable; membership alone never requires adoption. A template or component may implement a pattern without describing its reasoning or limits.
Keep a short record of:
- name, identifier, version, maintainer and status;
- problem, intended outcome, context, prerequisites and when not to use it;
- approach, what must remain consistent, permitted variations and an example;
- alternatives, trade-offs, costs, risks and failure/recovery behaviour;
- evidence links, tested product contexts, limitations and permitted uses;
- decision owner, review triggers and how to change or retire it.
Propose it in Phase 1 when useful; test its intended range in Phase 2; decide supported uses and support in Phase 3. A candidate remains unproven outside its tested contexts. Record each product’s adoption, adaptation or non-use. Changes must identify affected users, prompt rechecking and preserve earlier versions; retirement must name a replacement or withdrawal route.
Owner: Integration coordinates a named maintainer. The Family owner decides shared status; product owners accept their own use. Link evidence to the Cross-Product Evidence Ledger and shared implementations to the Substrate Map rather than duplicating either.
Invented example: a handoff carries the original request, supporting source, limitations and a correction route. Products may use different forms or systems while preserving that information. Its suitability still needs testing.
Share AI controls safely
The shared AI Model Harness is the set of rules and checks around AI use. The Platform and Substrate owner looks after common controls. Products check whether those controls are suitable in their own setting. Wider AI permission needs evidence and continuing human oversight.
Shared prompts, models or sources can repeat the same mistake; repeated agreement is not independent confirmation. Checks must be able to detect failures the producing system misses. AI doing Family routing, coordination or analysis also needs evaluated controls for those tasks, with named owners and stop conditions.
Send findings up and decisions back
The Portfolio Guide sets investment limits. Family translates them into shared expectations; the Product Guide governs each product’s evidence and acceptance.
Products return findings, costs, benefits and uncertainties. Family adds cross-product effects; Portfolio decides further investment. Use original source records. Return decisions with scope, conditions, owner and review point.
These are connected decisions, not mandatory reporting layers. Products without a useful family decision connect directly to Portfolio. Routine work stays within agreed authority.
Work with agile methods without adding needless layers
Keep a short, ordered list of shared work. Review useful increments with users and support people; use existing routines for cross-product decisions.
LeSS and Nexus coordinate teams working on one product. Apply their lessons about whole outcomes and fewer dependencies without treating every team as a product or importing mandatory roles, events or common Sprint lengths.
Practise judgement, evidence, restraint, accountability and adaptation.
Sources
Pattern practice in 2026
GOV.UK describes adaptable task patterns; its contribution criteria require evidence of usefulness and tested contexts. IBM Carbon distinguishes patterns from coded components. Microsoft emphasises problem fit and trade-offs; Google Cloud applies contextual selection to AI workflows. These sources, checked in October 2026, inform this proposed AIPF record; they do not prescribe it.
Further reading
LeSS principles and the Nexus Guide inform the whole-product perspective; this is not their implementation manual.
For shared information fields and phase handoffs, use the Framework’s shared information checklist. Further family-specific templates can be developed as needed without duplicating the records.
Earlier versions also drew on Conway’s Law and Team Topologies to consider communication and the demands placed on teams.
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.
Help improve this page
Found a problem or a better way to explain it? Suggest a correction or improvement.