Skip to main content

    Field Note · 2 September 2026

    How to Measure Whether an AI Workshop Actually Worked

    Move past attendance and satisfaction. Measure what was built, what changed and what continued after the room cleared.

    Filed
    2 September 2026
    Author
    Dima Abramov
    Reading time
    4 min
    Topics
    Measurement · AI Workshops · AI Adoption · Product Analytics
    Share
    How to Measure Whether an AI Workshop Actually Worked

    A full room, a high satisfaction score and a folder of photos can all be true while very little changes. They tell you that an event happened. They do not tell you whether the team can now do something useful that it could not do before.

    I still measure the experience. A confusing workshop rarely produces good work. But experience is only the first rung of the ladder.

    Start before the workshop

    Measurement begins when the problem is selected, not when the feedback form is sent. Capture a small baseline for the workflow the team intends to change: time spent, handovers, error rate, volume, user friction or decision latency. If there is no baseline, describe the current process clearly enough that a later comparison is possible.

    Do not force every project into a financial forecast. Early work is often about learning. The important thing is to name the expected change before the build begins.

    A five-level measurement ladder

    1. Participation

    Who started, who finished and which roles were represented? This is useful operational information. It can reveal access problems or a format that excluded non-technical participants. It is not an impact metric.

    2. Working output

    What exists at the end that did not exist at the start? Count testable prototypes, instrumented flows, documented agent workflows or decisions supported by evidence. A slide describing a future build does not count as a working output.

    3. Capability

    Can participants repeat the behaviour without the facilitator? Ask them to make a change, explain a trade-off, inspect an event or recover from a failed prompt. Capability is demonstrated through action, not self-reported confidence alone.

    4. Adoption

    Is the result used after the workshop? Check again after one week and one month. Usage can mean a team returning to the prototype, applying the method to a second problem, or integrating a useful component into normal work.

    5. Outcome

    Did the target workflow improve? Depending on the problem, look for shorter cycle time, fewer manual steps, higher completion, better decision quality, reduced support effort or faster validation. Keep the measure close to the original objective.

    A compact scorecard

    • Objective: the workflow or decision we want to improve.

    • Baseline: how it works today and the best available measure.

    • Output: the working thing produced in the session.

    • Owner: the person accountable for the next test.

    • One-week signal: evidence that the build left the room.

    • Thirty-day signal: repeated use or a documented stop decision.

    • Outcome measure: the change we expect in the original workflow.

    • Risk note: unresolved data, security, quality or ownership concerns.

    Satisfaction still has a job

    Ask whether the pace, support and material helped people work. Ask where they got stuck. That improves the next workshop. Just keep those questions separate from claims about adoption or business impact.

    A participant can love a workshop and never use the method again. Another can find the session difficult and still create a valuable operational change. Both pieces of information matter, but they answer different questions.

    Be honest about attribution

    A workshop rarely creates a business result by itself. It can accelerate a decision, establish a capability or produce the first usable version. Product work, leadership, data access and follow-through then shape the result.

    Use language that reflects that reality: “contributed to”, “enabled the team to test” or “produced the first working version” is often more accurate than claiming the event caused every later outcome.

    The most important follow-up question

    Thirty days later, ask: what happened to the build? There are only a few useful answers: it is being used, it evolved, it informed a decision, or it was stopped for a clear reason. “We are still considering it” usually means ownership disappeared.

    The broader operating sequence is in the 90-day AI enablement plan. If you want the measurement designed into the session, explore the team formats.

    The studio

    Notes record what happened. Working together changes what happens next.

    These notes come from building with teams, products and communities. If one describes a problem you are facing, bring us the real version.

    About two minutes