From source documents
to training exercises.

01 / Problem and opportunity

Training authors were manually rebuilding source material into exercises.

The reference documents already existed. The remaining work was to read them, pull out the relevant tasks, define learning objectives, list materials and prerequisites, write learner instructions, add completion checks, and format everything into a reviewable worksheet.

I identified that repeated translation and assembly work as the problem to solve. Authors needed a structured starting point, and reviewers needed to see whether it accurately reflected the source—not spend their time reconstructing the document or finding hidden assumptions.

My solution: a source-to-worksheet workflow that drafts the required sections, keeps missing information visible, supports review and revision, and produces an editable training document. The goal was to assist the author, not remove their judgment.

The job to be done“When I have a reference document, help me turn it into a training exercise with clear steps and completion checks, so I can focus on the learning experience instead of rebuilding the worksheet.”

This is a real example from my work at Microsoft: I identified the authoring problem and created a working solution. Role descriptions are generalized here; internal documents, systems, and operational details are not published.

02 / My contribution and process

I built it, put it in front of others, and redesigned it for real use.

I defined the problem, built a working version, shared it, and presented and demoed the solution. I then redesigned the workflow for production needs. This public adaptation came afterward.

1. 01

   Identified the repeated authoring work

   I focused on the gap between an existing reference document and an exercise someone could teach or complete. The opportunity was to assist the translation into objectives, preparation, instructions, and completion checks.

   Output: a concrete problem and a defined training-author workflow.
2. 02

   Defined a consistent worksheet

   I made the worksheet's 17 fields a shared contract. Prompts, revisions, previews, and document generation could then work with the same structure instead of a different free-form response each time.

   Output: a field schema, section requirements, and prompt responsibilities.
3. 03

   Built a working version

   I built a source-to-worksheet flow and iterated on AI-assisted drafting, field mapping, and document output. Supplied source content could become an editable training worksheet—something I could demonstrate, not just describe.

   Output: a working solution and generated documents to inspect.
4. 04

   Shared, presented, and demoed it

   After creating the working version, I shared the solution, presented the approach, and demonstrated the workflow. That put both the output and the product decisions in front of others.

   Output: a shared working version, presentations, and demos.
5. 05

   Redesigned for production needs

   I moved beyond making a single run work and redesigned around clearer responsibilities, consistent fields, source checks, review, failure handling, and document delivery. The focus shifted to a workflow that could be operated predictably.

   Output: production-oriented workflow design and clearer operating requirements.
6. 06

   Created a public version people can explore

   I preserved the reusable concepts and created new sample content, placeholder infrastructure, and this local browser walkthrough. Visitors can explore the review and export experience without internal access.

   Output: an anonymized case study, interactive demo, and reusable blueprints.

03 / Strategy and prioritization

A useful worksheet first. A repeatable workflow next.

I prioritized a controlled source-to-document sequence over an unrestricted chat experience. Copilot Studio and Power Automate supported the low-code design; the browser layer is a separate public adaptation that lets visitors explore it without internal access.

04 / Product and business metrics

Measure accepted work, not generated words.

Proposed pilot criteria—not measured results. The example thresholds below are planning choices, not historical performance or commitments. They would be agreed with pilot participants after establishing a comparable baseline.

A fast model response is not end-to-end time saved. A successful export is not proof of learning. None of these pilot metrics is collected by this public site.

05 / Business judgment

Make the assumptions inspectable.

This planning model asks whether reduced assembly effort could justify implementation and running costs. It charges for every assisted attempt and includes a full manual fallback when the assisted workflow is unsuccessful.

The calculator requires JavaScript. The formulas and all product-story content remain readable below.

06 / Evidence and reflection

A real build, a public walkthrough, and a clear measurement plan.

What I learned from the product work

• Start with the artifact. A concrete output contract makes scope, quality, and ownership easier to reason about.
• More prose is not more value. A short, task-specific outline can be more useful than an impressive-looking wall of text.
• Treat source availability as a product dependency. Better wording cannot repair missing evidence.
• Trust includes saying “not ready.” Visible missing facts and blocked exports are useful behavior, not merely error handling.

07 / Measuring broader use

Measure the next stage, not just the first successful run.

Building, sharing, and demoing the solution came first; production-oriented redesign followed. For broader use, the evaluation plan below would measure whether the workflow consistently delivers accepted training exercises at a sustainable cost.

1. Baseline the authoring work. Measure comparable manual tasks, agree what “accepted” means with authors and reviewers, and separate authoring time from review and correction time.
2. Run a bounded pilot. Use consented, non-sensitive examples, matched tasks, counterbalanced task order, and the same review rubric. Include failures and manual restarts. Report sample size and uncertainty; a small pilot is not a production claim.
3. Expand only if quality and economics hold. Verify any optional connected build, access controls, support ownership, and per-accepted-artifact cost. Pause on critical unsupported content or a broken review boundary before adding sources or users.

A future evaluation would record timestamps, revision counts, outcome categories, and reviewed quality scores with appropriate consent and retention rules—not raw source bodies by default. No such analytics or pilot is running on this site.