Design Sprint
Nearly 500 upvotes. A clear feature request. A team ready to build. Everything said: build template sync so updates flow from templates to change requests (CRs). We almost did.
I flew to Sydney to run a 5-day design sprint with the engineering team. By Day 5, the feature was dead.
What we found
We put the prototype in front of users and discovered three groups who all wanted the opposite of what we were building.
Executors
“Fork it, finish it, forget it.”
Use templates to create CRs, then never look back. Don't want upstream changes disrupting an in-flight process.
Creators
“My template is the source of truth.”
See published templates as stable, vetted artifacts. Don't want to be responsible for disrupting active deployments.
The System
“Updating breaks trust.”
Certification is tied to a specific template version. Any update revokes it. Re-certification is slow and manual.
The catch-22
109 people asked for it. Nobody would use it.
Creator updates template
Fix error or improve process
Bar-raised status revoked
All downstream CRs lose certification
CRs can't execute
Teams blocked on re-certification
Re-certification is slow
Manual review by senior engineers
Nobody updates templates
Templates ossify to avoid disruption
Creator updates template
Fix error or improve process
Bar-raised status revoked
All downstream CRs lose certification
CRs can't execute
Teams blocked on re-certification
Re-certification is slow
Manual review by senior engineers
Nobody updates templates
Templates ossify to avoid disruption
The feature was technically sound but behaviorally dead on arrival.
“In five days, we learned something that would have taken us months to discover after shipping.”
Impact
7 people, 1 flight, research, prototype, test
4 engineers, build, ship, discover low adoption, pivot
Prevented the wrong feature
The team paused work on template sync, avoiding 3-6 months of engineering investment in a feature users wouldn't adopt.
Validated the sprint format
One week of structured research prevented months of misdirected effort — especially valuable for teams without dedicated PMs.
Methodology adoption
Shared the sprint process across the org, inspiring adoption of design sprints for strategic planning.
Process
How we got there
Why a sprint
The engineering team was in Sydney. I was in Seattle. A 2-hour daily overlap made iterative collaboration nearly impossible. The team had no PM — they were self-prioritizing based on upvote counts. Without the sprint, the next step would have been engineering tickets, not research.
Seattle
PST (UTC-8)
Sydney
AEDT (UTC+11)
The sprint
| Day 1 | Understand Mapped the template lifecycle, interviewed experts, generated How Might We questions. |
| Day 2 | Ideate Lightning demos, Crazy 8s, independent solution sketches. |
| Day 3 | Decide Structured critique, dot-vote prioritization, storyboard for prototype. |
| Day 4 | Prototype High-fidelity interactive Figma prototype. |
| Day 5 | Test User feedback sessions. The twist. |
Manly Beach, Sydney — after the sprint.