Hello there! You've reached the portfolio-ish site of Ben Leduc-Mills. I like making, in many forms -- through music, woodworking, lasers, electronics, code, Lego, 3d printing, e-textiles, you name it. This website captures some of my career from interaction design, rapid prototyping & digital fabrication, open source hardware, software engineering, user research, and of course, AI.
Yes, I use AI everyday. For code, for design, and for research. No, I didn't use it for this website.
Rebuilding a Broken Jobs-to-be-Done Practice
Our JTBD was broken. Two quarters later, I had the pilot study numbers to prove it, and a working playbook to help fix it for everyone else.
Context & Contributions
Teams across GitLab had been writing Jobs to be Done statements for years, but nobody had ever stepped back and looked at the whole set together. I proposed and led a two-quarter OKR to do exactly that: audit every job story we had, figure out why the practice wasn’t delivering what JTBD is supposed to deliver, and then actually fix it rather than just diagnose it. A product design partner joined me on rewriting the JTBD handbook pages once the new approach was proven out, and stakeholders across the Create stage and UX Research teams gave guidance and support along the way.
PROJECT DETAILS
ROLE: LEAD RESEARCHER (HANDBOOK REWRITE CO-AUTHORED WITH A PRODUCT DESIGN PARTNER)
PROJECT TYPE: 2-QUARTER OKR, META-ANALYSIS + METHODOLOGY PILOT
DURATION: MAY–OCT 2023Problem
Jobs to be Done is supposed to help you understand and improve the jobs your customers hire your product to do. Our version of it didn’t do that. It’s easy to confuse JTBD, the whole framework, with a job story, which is just one piece of it, and that’s largely what had happened at GitLab: teams had been generating job stories in jtbd.yml with no shared format, no consistent validation, and no real throughline back to the people actually doing the jobs.
Hypothesis
If we treated the full set of job stories as data and actually analyzed it, rather than trusting that dozens of independently written statements added up to something coherent, we’d find the specific ways the practice was falling short, and from there we could design a process that fixed them rather than just naming them.
Methods & Process
Auditing
As of May 2023, jtbd.yml held 194 job stories, 167 once duplicates and retired categories were stripped out. Only 52% had been validated in any form, and even that number was generous: 80 were marked “researched,” a handful interview-based or heuristic, and 59, more than a third, were simply blank. Only 17% had ever been given a letter grade. Coverage was worse than the raw count suggested: 62% of GitLab’s product divisions, stages, groups, and categories combined, had zero job stories at all. Monitor and Verify were in decent shape at 73% and 64% coverage; Manage had none, and Secure sat at 12%. Ops alone owned 59% of every job story that existed, against 24% for Dev and 17% for Sec.
Diagnosing
The audit pointed to three specific failures, not just one vague “needs improvement.” The picture was incomplete: with over half our product groups never having done any JTBD work, it was like trying to read a book with half its chapters missing. The process was inconsistent: different groups arrived at their job stories through completely different methods, only about half validated at all, like a book written in ten languages by ten different authors. And the performer was invisible: a job story on its own doesn’t tell you who’s doing the job, what larger goal they’re working toward, or which part of it actually matters most to them.
Rebuilding
Working from Jim Kalbach’s JTBD methodology, I rebuilt the practice around a playbook with the job performer, not the job story, at the center: pick a job performer, gather what’s already known about them, interview real people doing that job, synthesize and validate a single canvas from those interviews, generate outcome statements from it, then run a survey to score and prioritize those outcomes. Every canvas covers the job map, the social and emotional dimensions of the job, related jobs, and aspirations, so a job story stops being an isolated sentence and starts being part of a real, validated picture of a person.
Piloting
I ran the whole playbook for real, inside Create. Across the stage’s groups, three main job performers emerged: Code Author, Code Reviewer, and Repository Manager. Six internal interviews built the initial canvases, then twelve external customer interviews, each covering at least two of the three jobs, validated each canvas eight times over. That produced around 180 outcome statements, narrowed to 150 for the scoring survey, which had pulled in 134 responses by the time I wrote the report and was still collecting.
Findings & Results
The pilot did what it needed to do: it produced a prioritized, quantified list of outcomes for Create, grounded in real interviews and real survey data instead of intuition. That’s the actual point of Outcome Driven Innovation scoring, an outcome like “increase the chance that the pipeline passes” isn’t tied to one team’s roadmap, it’s a shared target that any stage can see and act on.
That portability turned out to be one of the more useful side effects. A job performer might have one home stage, but the outcomes they care about show up everywhere. If Create’s Code Author and Verify’s job performer both care about pipeline reliability, both teams can see that overlap and coordinate instead of duplicating research or, worse, never finding out the other team was already working on it. I sketched out exactly that scenario in the report: Create noticing an underserved outcome shared with Verify, pinging them in Slack to ask if it’s already in flight, and landing on an actual idea (using AI to catch common pipeline failures automatically) worth tagging in for review.
My handbook co-author and I used the pilot’s results to start rewriting the JTBD handbook pages around this playbook instead of the old, looser guidance, with the goal of making it something any team could pick up and run themselves. We also built a FigJam template covering every step, ending in a workshop format for a team to walk through their own top-ranked opportunities and turn them into roadmap action items. I spent the months after this report consulting with other groups directly to help them run the playbook on their own jobs, since the whole point was never to have one team’s outcomes prioritized well, it was to get every team speaking the same language.
(That pilot’s momentum is also where a more formal JTBD and Outcome Driven Innovation rollout across Create and Secure started the following year, worth its own post at some point.)
