Design Thinking at Scale
From Bottleneck to Self-Sufficient Teams
Role: Director of Product Design
Partners: Product Management, Engineering, Product Design Team
Impact: 3 facilitators → 18+ facilitators across design and product; every portfolio self-sufficient
Overview of the Design Thinking practice and artifacts
The Problem
We didn't have enough designers to facilitate all the workshops the organization needed.
As a few designers started running design thinking workshops, word spread. Teams saw the results: better alignment, faster decision-making, and solutions grounded in real problems. Suddenly everyone wanted to run workshops.
But they'd have to wait weeks — sometimes months — to get a designer available to plan and facilitate. By the time a designer was free, the moment had passed. Teams either moved forward without the workshop or made decisions in silos.
The bottleneck was real: only 3 designers knew how to facilitate effectively. Everyone else was hesitant because they didn't know where to start, which format to use, or how to structure the session.
I started building resources for our design team to upskill in workshop facilitation. Then I realized: why should this be a designer's job only? PMs and engineers collaborate in these workshops — they could learn to facilitate too.
If we could teach the entire product org how to run design thinking workshops, every portfolio could be self-sufficient instead of waiting for design capacity.
How I Approached It
I created the Design Thinking Toolkit — a practical resource for anyone in the product org to plan and facilitate design thinking workshops.
The Field Guide Document: Step-by-step guide covering what design thinking is, when to use it, how to prepare, how to facilitate, and what to do with outputs.
Workshop Templates: Ready-to-use Miro templates for common scenarios — problem framing, ideation, prioritization, journey mapping, user story mapping, etc.
Decision Flow: A simple flowchart helping teams choose the right workshop type based on where they are in the process, what problem they're solving, who needs to be involved, and how much time they have.
The key was making it practical, not theoretical. No academic frameworks. Just clear guidance: "If you're trying to solve X, run this type of workshop, here's the template, here's how to facilitate it."
The Decisions That Mattered
1. We Made It For Everyone, Not Just Designers
The original plan was to upskill designers. Expanding it to PMs and engineers meant writing for a broader audience and stripping out design jargon. That extra work paid off—product people adopted it because it spoke their language.
2. We Built Templates, Not Just Principles
Giving people templates eliminated the blank-page problem. They didn't have to invent workshop structures from scratch—they could adapt proven formats to their specific needs. Teams needed tools they could use Monday morning, not theory they'd bookmark and forget.
What Changed
We went from 3 designers facilitating workshops to 18+ people across the organization (12+ designers, 6+ product managers). Every portfolio had at least one person who could facilitate workshops without outside help.
Teams stopped waiting for design capacity. With product, design, and engineering together in these sessions, portfolios gained alignment faster and built shared understanding before jumping to solutions.
The executive board took notice. Design Thinking as a Practice became a highlight during an Executive Board Meeting — evidence that the product org was maturing in how teams approach problem-solving.
What I Learned
Capability scales faster than capacity. I could have hired more designers to meet facilitation demand, but teaching the entire org how to facilitate meant every team became self-sufficient.
Democratizing skills doesn't diminish them. Some designers worried that if everyone could facilitate workshops, design would lose its value. The opposite happened — teams appreciated design thinking more because they understood it, and they called on designers for more complex challenges.
Make it practical or it won't get used. The Field Guide worked because it solved Monday's problem ("what do I do right now?") not a theoretical one. Tools that answer immediate questions get adopted. Philosophy documents get bookmarked and forgotten.
|
My Contributions
|
Team Credits
|