Case study · in progress
Teaching product managers to write outcomes, not to-do lists

The problem

Three years ago, this product team moved to Monday.com in a single day, with no training. The board was supposed to be the team's single source of truth for deliverable status. Today, only two people use it as intended. Leaders lack visibility, deadlines slip, and status updates happen in extra meetings and side conversations.

What I found

I interviewed the team's program manager and facilitated a root-cause session in Mural. Of six barriers to adoption, only one was a knowledge gap that training could close. The others called for clear ownership rules, defined update triggers, tool configuration, and leadership changes, so I recommended those separately.

Follow-up interviews changed the picture. The people who own the board are the outbound product managers, and their real gap was writing outcomes: they described deliverables ("publish the deck") instead of impact ("sellers can tell the story"). I revised my own analysis to match the evidence instead of forcing the original plan.

Defining success

Nothing was being measured, so I built the measure. I wrote a five-criterion quality rubric with one gate: if you can check it off today, it's probably a deliverable. The goal: by end of Q4, 80% of the 20 most recent PM-written outcomes describe impact and name how success will be measured. Action mapping then tied every practice activity to that on-the-job behavior, and the evaluation plan covers Kirkpatrick Levels 1 through 4. There is no baseline yet, and I chose not to invent one.

The design

Learners play an outbound PM reviewing teammates' drafts before a product launch. The module opens on a team call where the dashboard says everything is on track even though client renewals are slipping. My SME believed narrative work can't be measured. I disagreed, chose upgrade rate and win/loss reasons as the measure, and gave that belief to one of the characters so the module could address it. Practice builds one skill at a time: sort outcomes from deliverables, diagnose a weak outcome, fix it, then write one from scratch, ending with a scored check. Two job aids supports the skill on the job.

The build

I'm building the module in Storyline 360 on a visual system I made for it: a color palette checked against WCAG 2.1 AA contrast in Adobe Leonardo, a type scale based on how text actually renders in Storyline, and a cast of characters in my own illustration style. I drew the lead character by hand to set the style, used AI for fills and recoloring, and drew the final hair and features of the others myself.

How I worked with AI

I used Claude to draft analysis, storyboards, and build specs. The decisions stayed mine.
A few examples: