How to Choose an AI Learning Project That Proves Workplace Capability

When I taught product managers who went from writing specs to building and shipping the product and automating work around it, the failure was usually an undefined “done,” not the model. That is a qualitative teaching observation, not a measured prevalence claim.

The project you choose determines what your work can prove. A polished chatbot can show that you can make a demo. A bounded workflow with test cases can show that you can frame a problem, inspect evidence, handle failure, and place a decision with the right person.

The completed comparison below is the useful artifact. For this learning objective, a customer-feedback-to-decision brief beats a meeting-summary assistant and a support-ticket triage classifier because it exposes more workplace judgment without requiring production writes.

Read it alongside the guide to what to learn before building AI agents, then copy the blank worksheet before you pick a tool. When you score the outputs, use a separate rubric for grading AI output rather than relying on how polished the prose sounds.

Choose a project that exposes a decision, not a demo

Choose a project when a reviewer can see the real workflow, the user, the baseline, the artifact, and the decision boundary. If the only proof is “the output looks good,” the project is too vague.

This follows the logic of OpenAI Academy's workflow-readiness evaluator, which starts with an observable workflow problem and asks about frequency, reach, friction, repeatability, process readiness, governance, dependencies, and ownership. It explicitly warns that “AI could probably save time” or “this would make a good demo” is not enough. Use the evaluator as a source of fields, not as a reason to force AI into a weak process.

Microsoft's adoption guidance makes the same decision sharper: define the business outcome, compare ambition with readiness, identify the weakest capability, and give every initiative a named outcome and owner. Its transformation-pattern guidance is written for organizations, but the selection test transfers well to a learner's project.

Use these vetoes before scoring anything:

• No real workflow or identifiable user.
• No deliverable a reviewer can inspect without watching a live demo.
• No evaluation cases, or no definition of what counts as a failure.
• No safe access path for the inputs.
• No stakeholder who can accept, reject, or use the result.
• No human review boundary for a consequential output.

If a candidate hits a veto, do not rescue it with a more impressive model. Shrink it, replace it, or stop.

Fill in this project-selection worksheet

Complete the fields before you write a prompt or open a builder. The point is to make the proof contract explicit.

Field	Question to answer
Real workflow and user	What repeated work happens, for whom, and what decision or output follows?
Learner capability being demonstrated	What must the learner frame, build, test, explain, or repair?
Observable baseline	What can be seen or counted before the project starts?
Deliverable	What artifact can a reviewer inspect without trusting a demo?
Evaluation cases	Which normal, ambiguous, missing-data, and adversarial cases will be tested?
Human review	Who checks the output, what do they check, and when do they take over?
Access and governance constraints	Which data, tools, permissions, policies, and approvals bound the project?
Stakeholder or owner	Who accepts the artifact and owns the workflow after the learner leaves?
Timebox	What is the smallest useful duration and scope?
Stop rule	What failure, missing prerequisite, or unresolved risk ends or reshapes the project?

The fields are deliberately ordinary. Formal work-based assessment guidance for AI roles expects integrated evidence of technical judgment, test-data interpretation, communication, risk assessment, and independent work, not just a tool demonstration. The Skills England AI Data Specialist standard is one example of that pattern. See the official standard.

Compare three candidates before you build

Here is the completed worksheet for a product manager choosing a three-to-five-day learning project. The inputs are plausible, not a claim about a particular employer. Replace them with your own workflow and mark unavailable workplace data honestly.

Field	Meeting-summary assistant	Support-ticket triage classifier	Customer-feedback-to-decision brief
Real workflow and user	A product manager turns meeting notes into decisions and actions for a product team.	A support lead routes incoming tickets to queues for agents.	A product manager turns feature requests and issue reports into a prioritization brief for a product lead.
Learner capability	Extraction, prompting, concise communication.	Classification, thresholds, escalation, data handling.	Workflow framing, source traceability, evaluation, uncertainty, recommendation, and review.
Observable baseline	Existing notes and action lists, but quality is subjective.	Current labels, routing corrections, and escalation policy, if accessible.	A small feedback set and the current manual brief format.
Deliverable	Summary template plus sample output.	Label schema, classifier prototype, confusion review, and escalation rule.	One-page brief, source map, rubric, test cases, failure log, and revision.
Evaluation cases	Clear decisions, competing decisions, missing owner, contradictory notes.	Clear label, ambiguous label, sensitive content, unknown category, urgent ticket.	Duplicate request, unsupported impact claim, dependent request, weak preference signal, conflicting evidence.
Human review	The product manager reviews every summary.	The support lead reviews low-confidence or high-risk tickets.	The product lead reviews every recommendation before roadmap action.
Access and governance	Sanitized notes are enough for a dry run; meeting privacy still matters.	Real tickets and routing writes need permission, retention, and operational approval.	Synthetic or sanitized feedback is enough; no production write is needed.
Stakeholder or owner	Product manager or meeting owner.	Support operations lead.	Product lead or product operations owner.
Timebox	Two to three days.	One to two weeks plus approval time.	Three to five days.
Stop rule	Stop if reviewers cannot agree what a correct summary contains.	Stop if label ownership, safe access, or escalation policy is missing.	Stop if there is no decision owner, source trace, or testable output.

The winner is candidate three for this learning objective. It is not universally the highest-value business opportunity. Candidate two may be the right production investment when ticket data, governance, and an operational owner already exist. Candidate one is a sensible warm-up, but a polished summary can hide weak judgment about evidence, priority, or ownership.

The choice also matches task-oriented AI-literacy research. Bogart and colleagues argue that practical, contextualized work-task assessment is more aligned with job use than abstract technical knowledge alone in the study they describe. Read the paper. A project that makes the learner defend a decision is closer to that target than a project that only rewards fluent output.

Make the winner a reviewable capability artifact

The learner's deliverable is a one-page decision brief with six parts:

1. The workflow, user, and decision owner.
2. A table of feedback items with source IDs and issue types.
3. Evidence strength and unresolved questions for each proposed theme.
4. One bounded recommendation that fits the timebox.
5. Evaluation cases, review criteria, and the human approval step.
6. A failure log showing what changed after testing.

This is stronger than a screenshot because a reviewer can inspect the reasoning. It also makes the learner's AI role visible. The tool may group text, propose themes, or challenge a draft. The learner still checks traceability, rejects unsupported impact claims, and decides what the stakeholder should see.

The implementation can start as a plain configuration before you connect a model or a workplace system. This is the contract used for the desk run:

workflow: customer-feedback-to-decision-brief
input: four-synthetic-feedback-cards
required_fields:
  - source_ids
  - issue_type
  - evidence_strength
  - unresolved_question
  - recommendation
  - human_owner
test_method:
  cases: [normal, clear-request, weak-evidence, dependency]
  reviewer: human
  pass_rule: no invented impact and every required field present
observed_output:
  before_revision: "T1, T3, and T4 failed; T2 passed"
  after_revision: "Four of four cases passed"

The configuration is useful because it states what the learner must produce, how the reviewer will test it, and what the recorded output means. It is a project contract, not a claim about model accuracy.

Institute of AI PM's capstone guidance makes a related distinction between describing a product and evaluating it. Its stronger artifact includes test cases, findings, failure modes, feature decisions, and responsible-AI review. That is course guidance, not proof of transfer, but it gives a useful standard for what a portfolio artifact should contain. See the capstone checklist.

Run a small evaluation set before calling it proof

Use four cases. You need one normal case, one ambiguity case, one weak-evidence case, and one dependency or safety case. The point is not statistical coverage. The point is to make failure visible early.

For the worked project, use these synthetic feedback cards:

Case	Input	Expected behavior
T1	“The CSV export sometimes drops timezone and account-ID fields.”	Preserve both fields as evidence, flag reliability, and avoid jumping to a visible feature.
T2	“Two finance leads want saved filters for weekly unpaid-invoice review.”	Identify a clear user request and propose a small validation with a finance lead.
T3	“Two users ask for dark mode but describe no work failure.”	Mark it as a preference signal and do not claim retention or productivity impact.
T4	“A scheduled month-end export would help if the fields were reliable.”	Treat field reliability as a dependency and sequence scheduling after the check.

The first desk run on 2026-08-23 exposed three failures. The draft lost field-level evidence in T1, invented a retention benefit in T3, and ignored the dependency in T4. T2 passed. These are not workplace failure rates. They are the recorded outputs of this small artifact check.

The revision was small but important. The original contract only asked for a recommendation. The revised contract required:

• source_ids
• issue_type
• evidence_strength
• unresolved_question
• recommendation
• human_owner

It also added a veto: do not claim an outcome that the input cards do not support.

After the revision, all four cases met the output contract in the desk re-run:

Case	Revised output	Reviewer decision
T1	Reliability issue. Check whether timezone and account-ID loss is reproducible before adding reporting features.	Pass.
T2	Workflow request. Test saved-filter fields with one finance lead.	Pass.
T3	Preference signal. There is insufficient evidence for retention or productivity impact.	Pass.
T4	Dependent opportunity. Verify export field integrity before scheduling automation.	Pass.

The result is useful because the failure examples changed the artifact. It does not prove that a learner or a model will achieve the same result. A reader can reproduce it with a comparable public chat tool and a text file, or replace the synthetic cards with sanitized workplace examples after approval.

Set human review, access limits, and a stop rule

The project is not complete when the brief sounds reasonable. It is complete when another person can say what they reviewed and what happens next.

Use this review checklist:

• Can every important recommendation point to one or more source IDs?
• Are weak signals labeled as weak instead of turned into business outcomes?
• Are dependencies visible, especially when one feature relies on data quality?
• Does the deliverable state what the AI did and what the learner checked independently?
• Is a human owner named for the final decision?
• Are inputs synthetic, sanitized, or approved for the chosen tool?
• Can a reviewer reproduce the test cases and see the failure before revision?

Keep the project assistive when access or readiness is uncertain. Microsoft distinguishes assistive patterns from execute patterns and notes that execute work demands more maturity in governance, security, business strategy, and technical foundations. Use its readiness guidance to decide whether your learner should prepare a recommendation or perform an action.

Stop or reshape the project when any of these conditions holds:

1. The workflow owner cannot be named.
2. The artifact cannot be inspected without trusting a live demo.
3. The inputs cannot be used under the team's data and policy rules.
4. The evaluator cannot define a failure case.
5. Human review cannot catch the important error.
6. The project needs production integration to look successful.

That last condition is common. A learning project should prove judgment before it proves integration. Add access only after the artifact survives review.

What this project proves, and what it does not

The completed brief can prove that the learner can frame a workflow, preserve evidence, write a testable output contract, inspect failures, revise the method, and present a bounded recommendation to a named owner. It cannot prove independent permission to act in a regulated or high-risk system. It cannot prove a production business result. It cannot prove that a team will adopt the workflow after training.

Those are separate checks. A work-based project is a bridge between learning and work, not a substitute for policy approval, domain supervision, or a live rollout evaluation.

This is where my teaching observation matters. When I taught product managers who went from writing specs to building and shipping the product and automating work around it, the failure was usually an undefined “done,” not the model. I describe that as a qualitative observation from my teaching, not a measured prevalence claim. The AI consulting and tutoring work I offer starts from the learner's real workflow and aims to leave the team able to run it themselves. For the follow-through after the project, see how to make AI training stick in a small team.

Start with three candidates. Fill the ten fields. Reject the project that cannot name its reviewer or its failure cases. Then build the smallest artifact that makes your judgment visible.