Should We Fund AI Discovery, Tutoring, or a Prototype First?

When I taught product managers who moved from writing specifications to building and shipping products, the recurring gap was often not the model. It was that nobody could say what done meant. That observation is qualitative and bounded to Marius Manolachi's teaching work, not a measured client result.

The same mistake appears in the first AI purchase. Teams buy the most impressive deliverable before deciding which uncertainty they need to remove.

The first purchase should buy the missing evidence

Fund the option that resolves the constraint currently blocking a good next decision. Discovery buys clarity about the work. Tutoring buys internal capability. A prototype buys evidence about one bounded workflow.

The decision rule is simple:

Fund discovery when the workflow, owner, outcome, or data path is unclear. Fund tutoring when the work is clear but the internal capability to frame, verify, and operate it is missing. Fund a prototype when one bounded workflow, testable outcome, usable inputs, and a safe action boundary already exist.

Any option without a named artifact and next investment decision is vetoed. That is the useful part of the rule. It stops a workshop from becoming a slide deck, tutoring from becoming passive attendance, and a prototype from becoming a demo with no release question.

The OpenAI Academy discovery workshop playbook starts with current workflows, pain points, inputs, outputs, readiness, owners, milestones, and follow-up. It explicitly says the workshop does not need to build a complete solution. Enterprise Ireland's AI Discovery brochure makes a similar separation: discovery maps data and skills, scores use cases, and produces a roadmap before prototype and operationalisation stages.

What each option should leave behind

Treat each purchase as a request for a specific artifact, not a vague promise of progress.

First purchase	Buy it when	Minimum artifact	Next investment decision
Discovery	The workflow, owner, success condition, data path, or risk boundary is unclear.	Workflow map, candidate list, readiness record, scored use cases, named owner, and next milestone.	Which one bounded workflow is ready for a test, or what missing evidence must be collected first?
Tutoring	The work is clear, but the internal operator cannot yet frame the task, verify outputs, or operate safely without help.	A learner-produced work sample, a reusable workflow guide, and a transfer check on a changed task.	Can the operator continue independently, repeat tutoring, or request qualified review?
Prototype first	One workflow, one outcome, representative inputs, a human owner, and a safe action boundary already exist.	A bounded test, review record, failure notes, and a continue, revise, switch, or stop recommendation.	Is there enough evidence to expand the test, invest in operationalisation, or stop?

The discovery column follows the outputs described by OpenAI Academy and Enterprise Ireland. The prototype column follows the constraints in the NIST AI RMF Core, which asks teams to establish context, business value, risk tolerance, scope, data suitability, human oversight, metrics, and limitations. The tutoring artifact is a proposed buyer-facing deliverable. OECD evidence makes the capability gap commercially relevant, but it does not prescribe this exact tutoring format.

The worked matrix: a Marius-owned workflow

This is not a client case study. It is a clearly labeled Marius-owned workflow: turning the assigned query and source package into one publishable evidence-backed post for Marius Manolachi's personal site.

The inputs are the query, editorial contract, five supplied primary URLs, locked entity facts, and existing internal-link targets. The output is one post plus a claim ledger, decision matrix, review report, and image manifest. The boundary is also explicit: no client data, no external system writes, no autonomous publication, and no production AI decision.

Freeze the workflow state before scoring

The state below is recorded before choosing an option. A 0 means absent, 1 means weak, 2 means partial, and 3 means clear or strong.

Criterion	Workflow input	Rating
Decision uncertainty	The uncertainty is which first purchase to make, not what the workflow or output is.	1/3
Workflow clarity	Inputs, output files, evidence gate, review gate, and publication boundary are named.	3/3
Internal skill gap	The workflow already specifies research, drafting, and review work. This is not a claim about every team or about Marius's general ability.	1/3
Data readiness	The source package, locked facts, and internal targets are available. No client data is needed.	3/3
Risk boundary	The work is editorial and reversible, with no client-data handling or production action.	3/3
Time to learning	The decision needs a first useful artifact now. This is a priority rating, not a time measurement.	3/3
Artifact produced	The job requires a matrix, claim ledger, review report, and publishable post.	3/3
Next investment decision	The next choice can be named after the matrix, but the matrix does not prove a future prototype will perform.	2/3

Apply the same weights to all three options

The scoring rule is deliberately plain. Each option receives 0, 1, 2, or 3 on every criterion. A 0 contradicts the current condition or cannot use it. A 1 is a weak fit, 2 is adequate, and 3 is a strong fit. The weighted total is weight × rating / 3, added across all eight rows.

Criterion and weight	Discovery first	Tutoring first	Prototype first
Decision uncertainty, 20	1	1	2
Workflow clarity, 15	1	3	3
Internal skill gap, 15	1	1	2
Data readiness, 10	2	3	3
Risk boundary, 15	2	3	3
Time to learning, 10	1	2	3
Artifact produced, 10	3	2	3
Next investment decision, 5	2	2	3
Weighted total	50/100	68/100	88/100

The result is prototype-first for this workflow. The recommendation is not that Marius should immediately deploy an AI publishing system. It is that the next useful spend, if one is approved, is a small non-production prototype that turns a query and source bundle into a claim ledger and draft while a human reviews every material claim and decides whether the post is publishable.

That distinction matters. The matrix is evidence for what to buy next. It is not evidence that the prototype works.

The vetoes that stop a premature prototype

Do not let a high score override a missing control. Prototype funding is vetoed when any of these is missing:

1. One named workflow. “Improve operations with AI” is a programme, not a test.
2. One checkable outcome. “Make the team more efficient” does not say what will be reviewed.
3. Representative inputs. A polished example cannot stand in for the cases the workflow actually sees.
4. A safe action boundary. The first test should prepare, classify, retrieve, or draft when a wrong action could be costly. Keep consequential writes and commitments behind human approval.
5. A named owner. Someone must own the review rule, the stop decision, and the next step.
6. A next investment decision. The test must end with continue, revise, switch to discovery or tutoring, or stop.

These are consistent with NIST's distinction between mapping context and measuring a system in conditions similar to deployment. NIST also calls for documented limitations, human oversight, privacy and security checks, and the ability to fail safely. The NIST AI RMF and Playbook are voluntary guidance, not a legal clearance or a universal product gate.

When tutoring is the better first investment

Tutoring wins when the workflow is already visible but the people who must operate it cannot yet make good decisions without help. The deliverable should be capability, not attendance.

Use a real work sample. Ask the learner to frame the task, choose what the system may and may not do, verify the result against source evidence, and explain what happens when the evidence is weak. Then change the task. If the learner can repeat the process on the changed case, you have evidence for a next capability step. If not, buy another targeted tutoring cycle or keep qualified review in place.

OECD's 2026 report describes skills as a major factor in AI adoption and says workers receiving employer-funded training report more positive outcomes, while also noting gaps in the evidence about which skills are needed and how they are best acquired. That supports treating capability as a real investment question. It does not support claiming that any particular course, workshop, or tutoring package guarantees independence.

The bounded teaching observation behind this emphasis is my own: product managers I taught moved from writing specs to building and shipping products, but the recurring gap was often defining what done meant. In a commercial decision, that means tutoring should be judged by a learner-produced artifact and a transfer check, not by enthusiasm during the session.

When discovery is the better first investment

Discovery wins when the business has ideas but not a comparable workflow description. Buy it when you still need to identify who does the work, what starts it, what output matters, which inputs exist, what human judgment remains, and who will own the next milestone.

OpenAI Academy's playbook recommends using real workflows and examples, capturing owners and first milestones, and ending with evidence to collect. Enterprise Ireland's model also shows discovery as a staged activity that can produce a roadmap and scored use cases before a prototype. That is useful because a discovery artifact can tell you not to build. A prototype cannot answer an undefined question cleanly.

Discovery is not automatically right just because it sounds cautious. Veto it if the facilitator cannot access the people who do the work, if the team refuses to name a decision-maker, or if the engagement promises a roadmap without a follow-up decision.

What would reverse the worked recommendation?

The dissenting assumption is that the current editorial workflow description is complete enough to be useful. If its source package does not represent the inputs future posts actually use, or if reviewing claims is the real bottleneck, the prototype score is overstated.

Reverse to discovery first if the owner, workflow boundary, success condition, or source and data path becomes unclear. Reverse to tutoring first if the workflow remains clear but the operator cannot independently frame a changed task, verify source evidence, or make the publish/no-publish decision. Keep all three options paused if the team cannot name an artifact and the next investment decision.

This is one first-party workflow and one decision artifact. It is not a client result, market benchmark, conversion study, or universal buying sequence. Replace the inputs with your own workflow and rerun the matrix. If you are still prioritizing candidate use cases, start with the guide to prioritizing AI use cases in a small business. If you are comparing the people who might help you deliver the work, read How to Choose an AI Consultant, Agency, or Internal Team. If the internal capability gap is the binding constraint, Marius Manolachi's AI consulting and tutoring work follows the same principle: existing people become more capable on their own work.