Practical guide
AI fluency for product, programme and technology teams
Choose product and programme exercises around decisions, dependencies and delivery evidence, using a fictional feature rollout.
Product, programme and technology-management teams need to distinguish user evidence, delivery assumptions and decisions that require an accountable owner. This original guide maps those differences into practical AI-enabled exercises. It uses a fictional feature rollout to help leaders choose what to practice, without presenting AI-generated priorities, estimates or technical assurances as approved plans.
Choose a decision layer
Separate deciding what matters from coordinating how work will happen.
A product exercise might ask whether a user problem deserves further discovery. A programme exercise might ask which dependency threatens a milestone. A technology-management exercise might ask what evidence is needed before selecting an implementation approach. These questions overlap, but each needs a different output and review standard.
In the fictional rollout, use a discovery note, dependency map and decision record as separate artifacts. State the owner and intended use of each. A worker who creates a good roadmap summary has not necessarily demonstrated the ability to evaluate a technical tradeoff or investigate user evidence.
Keep demand signals distinct from commitments
A request, a priority and an approved scope item have different meanings.
The exercise pack contains customer feedback, a sponsor request and an engineering estimate. Ask the participant to mark which items are observations, proposed work or confirmed commitments. A senior request may affect priority, but it does not by itself establish feasibility or resolve conflicting user needs.
AI can help cluster requests and draft a comparison. Inspect whether it has converted repeated wording into evidence of broad demand. Preserve source context and identify who was represented. Do not create a precise ranking formula unless the exercise provides and explains the decision criteria.
Model dependencies rather than only dates
A plan should explain what must become true before the next step can proceed.
For the fictional rollout, testing depends on a data import and a support handoff. The import is estimated but unconfirmed. Ask the worker to show that dependency explicitly instead of producing a clean calendar that assumes it is complete. Keep estimated dates distinguishable from commitments.
Introduce a delay in the import and ask which downstream activities change. A useful response identifies affected work, possible alternatives and the owner of the revised decision. It does not shift every date mechanically or promise recovery without evidence of available capacity.
Review a decision record for traceability
A decision record should preserve the reason for choosing an option and the conditions that could change it.
Ask for the problem, considered options, relevant evidence, tradeoffs and next review trigger. If AI suggests a technical option, the participant must identify the assumptions and expertise needed to evaluate it. The record should not imply a security, reliability or performance property that the pack has not established.
Keep rejected alternatives visible when they explain an important constraint. A concise record can still state uncertainty. The purpose is to make future revision intelligible, not to defend the original choice after the evidence changes.
Use separate practice paths for separate weaknesses
Match development work to the layer where the error occurred.
If user feedback is overgeneralized, practice evidence synthesis. If milestones hide prerequisites, practice dependency mapping. If a recommendation omits authority, practice decision ownership. If a technical claim lacks support, practice identifying what qualified review is required. Do not collapse these into a single measure of product intuition.
Review the final artifact with the supplied inputs and the changes introduced during the exercise. Keep conclusions limited to observed work. The product manager guide provides a detailed prioritization exercise; this page remains a function-level route for choosing among discovery, programme coordination and technology-decision tasks.
Sources and scope
NIST addresses AI risk management. Skills England describes workplace AI foundations.
These sources provide background, not endorsement of this exercise. The worked example and suggested review method are original illustrative guidance. They are not customer results, validated benchmarks or evidence of a particular product capability. Adapt the exercise to the task and use qualified review where consequences require it.
Sources: [1] [2]
Sources
- 1.AI RMF Core · NIST
- 2.AI foundation skills for work benchmark · Skills England