Should We Investigate an AI Opportunity Before Training the Team?

Quick answer: Investigate first when the workflow, owner, value metric, or approval path is missing. Train first when the workflow is clear but the team cannot perform or judge it safely. Do both when the opportunity is concrete and the team must learn through the real decision. Stop or re-scope when a critical veto remains.

Most training requests arrive as if the decision has already been made. “We need an AI workshop” sounds specific, but it can hide four unanswered questions: which workflow, owned by whom, measured how, and approved under what boundary?

The useful next step is a sequence decision. Spend the next dollar on discovery, capability, or a deliberately small combination.

The artifact below is the sourceable part of this page: a seven-field opportunity-versus-capability gate with explicit vetoes and three bounded worked decisions. It is a decision aid, not a validated scorecard. Replace its unknowns with evidence from your workflow.

The sequence depends on what is missing

Investigate an AI opportunity before broad team training when the workflow owner, current pain, or value metric is still unknown. Train first when the task and outcome are clear but the team cannot safely perform, evaluate, or approve the work. Fund both when the task is concrete and the team needs to learn inside the investigation.

That order follows two different research problems. The EnBW action-design research treats AI use-case identification as a decision process with several interacting choices, not as a simple list of ideas. Its method moves through scoping, preparing, discovering, understanding, designing, and concluding before implementation. The EnBW research supports the need to make the decision process explicit.

WestEd makes a related distinction: define the use case before assessing organizational readiness. Its readiness areas include organizational value, infrastructure and architecture, privacy and security, and data readiness and governance. WestEd's readiness guide is written for public agencies, so I use it as a structure for questions, not as a universal scoring model.

The practical consequence is simple. Training cannot repair an opportunity that nobody has described. Discovery cannot make a team capable by itself.

Use this one-page opportunity-versus-capability gate

Fill the seven fields before buying a general AI programme. Score each field from 0 to 2: 0 means unknown or blocked, 1 means plausible but needing evidence, and 2 means named and evidenced.

Field	0	1	2
Workflow owner	No accountable role	Likely role, not confirmed	Owner and outcome are named
Current pain	No concrete pain	Friction is described	Current work and consequence are bounded
Value metric	No outcome or stop rule	Candidate measure exists	Measure, baseline method, and review horizon exist
Data and system constraints	Inputs, access, latency, or integration unknown	Some constraints known	System boundary and constraints are explicit
Risk and approval requirements	No risk boundary or approver	Review is proposed	Failure impact, approver, and escalation are explicit
Learner readiness	Team cannot safely perform or judge the task	Baseline exists, practice missing	Team can practise, judge, and work within the boundary
Next-step budget	No protected time, money, or exit condition	Small budget is possible	Time, owner, budget, and stop or expand rule are reserved

Use the total out of 14 as a conversation starter, not as a procurement verdict. The sequence comes from the missing field and the vetoes.

Gate result	Fund next	Do not fund yet
Investigate first	A short discovery step that names the owner, pain, measure, constraints, and approval path	Generic training aimed at an undefined use case
Train first	Baseline, task-linked practice that produces a workflow brief and acceptance boundary	Broad capability training with no real task
Do both	A bounded investigation paired with practice on evaluation, judgement, and approval	Discovery separated from the people who must operate the result
Wait or re-scope	Evidence gathering or a safer alternative	Any expansion while a critical veto remains

The vetoes matter more than the total

Do not proceed to a larger AI investment when there is no accountable owner, no checkable outcome, no accessible data or system path, no human approval path for a consequential action, or no protected budget for the smallest useful test. A high total cannot cancel a missing safety boundary.

This is an analysis rule from the artifact, not a claim that the cited research uses these exact thresholds. WestEd's guide does support use-case-specific assessment of value, systems, data, governance, and stakeholders. The gate makes those concerns usable in a budget conversation.

Three bounded decisions from Marius Manolachi's work

These cases are deliberately narrow. They do not report rates or generalize from a study. They show how the gate behaves when the available evidence changes.

Locked context	Score	Decision	Principal veto or limit
Product managers learning to ship, F-pms	8/14	Train first, with discovery as the training output	No broad training if the product slice and definition of done are missing
Orange workshop starting from existing work, F-orange	2/14	Investigate first	No generic training until an owner, workflow, and measure exist
TryUncle's latency and human-approval constraints, F-tryuncle	9/14	Do both in one bounded step	No expansion without an operational approver and budget

The scores are not client data. They are transparent placeholders for what the locked facts do and do not establish.

Product managers learning to ship

I have taught product managers who moved from writing specifications to building, shipping, and automating work around the product. The recurring failure was not necessarily the model. It was that nobody could say what “done” meant. That is the locked F-pms observation, not a measured training result.

Here, the opportunity is concrete enough to attach learning to a real product slice. The capability gap is the blocker. Train first, but make the training produce discovery evidence: a named slice, an acceptance boundary, a way to evaluate the result, and a human who can approve it.

The decision changes if the team already has those capabilities. Then a short opportunity investigation may come first. The point is not that product managers always need training. The point is that an undefined definition of done is a capability problem that discovery alone will not solve.

The Orange workshop starting from existing work

The locked F-orange fact is that Marius Manolachi led a ChatGPT workshop at Orange. The useful teaching lesson was to start from the work people already do, not from an agent tour. The fact does not establish a specific Orange workflow, owner, value metric, data boundary, or business result.

That leaves the gate with several zeros. Investigate first. Ask one owner to bring one current workflow, its painful point, the outcome that matters, and the approval boundary. Training can then use that work as its practice material.

This is the principal exception to a training-led response. A team can be enthusiastic and still have no defined opportunity. The right first purchase is a small discovery step, not a generic course disguised as strategy.

TryUncle's latency and human-approval constraints

I am building TryUncle, an AI agent that watches the screen and annotates it live. In that product context, latency and human approval are product constraints. They determine what the workflow can ask the system to do and what a person must still judge. This is bounded to F-tryuncle; it is not a reported performance result.

This case calls for both. The opportunity is specific enough to investigate: a live screen-watching and annotation workflow. The constraints are also specific enough to shape practice: measure time to useful annotation, test the handoff to human approval, and rehearse what happens when the system is late or uncertain. The team should learn while it makes the decision.

Do not turn this into a broad AI literacy programme. The relevant capability is practical and local: evaluate the output, understand the latency boundary, and keep approval with the right human.

Make training task-linked before you fund it

Training earns its place before discovery only when it creates capability and usable evidence on the work. The UK government's PRIMES research names six requirements: Practical, Reachable, Integrated, Modular, Expandable, and Sustainable. The PRIMES report connects effective training to real tasks and decisions, clear boundaries for when AI should and should not be used, existing systems, protected time, responsible use, and ongoing review.

For a buyer, translate that into a training acceptance test:

1. Practical: learners use the real or safely sanitised task, not a generic demo.
2. Reachable: the schedule, format, support, and protected time fit the people expected to use the workflow.
3. Integrated: the exercise fits current systems, data rules, professional responsibilities, and approval paths.
4. Modular: the team can start at its actual capability level and repeat the part that fails.
5. Expandable: the skill transfers across the relevant tools or roles without pretending every workflow is the same.
6. Sustainable: the team has a review point for changing tools, risks, and further learning.

The AI literacy development canvas makes the same investment legible from another angle. It separates conceptual, ethical, and practical literacy, then connects strategy and goals with assessment and training, execution, and measurement. The peer-reviewed canvas is a useful reminder that capability is not just tool familiarity. It includes understanding, responsible judgement, practical use, and a way to measure whether the capability serves a defined use case.

Release the next budget in a small, reversible step

Use the gate in a live decision meeting. The first funded step should be small enough to stop when a veto remains.

1. Name one workflow owner and write the current work in plain language.
2. Choose one value metric and define how someone will check it.
3. Record the data, system, latency, risk, and approval boundaries.
4. Score learner readiness separately from opportunity quality.
5. Choose discovery first, training first, both, or wait. Write the veto and the exit condition in the budget request.
6. Review the produced artifact. If the step did not make the workflow, measure, owner, or approval path clearer, do not expand it.

The budget request should therefore contain one sentence like this:

We are funding [discovery, task-linked training, or both] for [workflow], owned by [role], measured by [metric], within [data and approval boundary], for [protected time and budget], and we will stop if [veto or exit condition].

That sentence is more useful than “train the team on AI” because it gives the buyer something to approve, inspect, and decline.

If you want to run the gate on a real workflow, the AI opportunity discovery parent page is the canonical next reading. For a narrower prioritization step, see How to Prioritize AI Use Cases in a Small Business. If the capability question is specifically about shipping, Why Do Product Managers Struggle to Ship AI Products? covers that adjacent problem. Marius Manolachi's AI workflow sprint is the commercial next step when the team wants to work through one real process and leave with a capability it can run itself.