Shared Understanding Before Speed

The situation

Coming out of the gap analysis, I had something rare: agreement. Leadership had endorsed the diagnosis and encouraged a pilot, so I had room to try a better way of working with a real team.

The teams had also started reaching for the right vocabulary. People were referencing Lean UX and the design sprint; the words were in the air, and leadership was leaning that way. What was missing was not the ideas. Anyone can attend a course or read a book. The missing piece was the part nobody owned: how a cross-functional team actually does the work together. The teams kept defaulting to sprint cadences with no discovery and no shared understanding of the goals underneath the work. And shared understanding, as Gothelf puts it, is the currency of team collaboration; without it, speed is just motion.

The approach

I deliberately did not invent a new method. The teams were already gravitating toward Lean UX and Jake Knapp's design sprint (the one Google Ventures helped popularize), so I met them there. I took the methodologies leadership was already trying to adopt and built the layer that was actually missing: the part that turns a book on a shelf into a team doing the work.

I had come to this through Jared Spool's UX Outcomes course, which led me back to Jeff Gothelf's Lean UX, and then to Knapp's Sprint; I read the sources rather than the summaries. Then I adapted them for how we actually worked. I took the Lean Strategy Canvas, the Lean Product Canvas, and the Hypothesis Prioritization Canvas and built a staged workshop around them, designed so each day's work compounded into the next: determine the team and how they collaborate, set the goal and strategy, define the business problem, users, and outcomes, then generate and prioritize the hypotheses worth testing.

The Lean foundation came first on purpose. It is what forces a team to surface the shared understanding (especially the business goals) that everything downstream depends on. From there, the model flowed into a design sprint, adapted for distributed teams, to take one prioritized feature from problem to tested prototype. The foundation had to come before the sprint.

What I built

An integrated, staged operating model, and the facilitation toolkit to actually run it: a preparation guide for setting the stage, a two-part Lean workshop, and a design sprint adapted to follow it. The adaptation is the point. Each workshop day took a canvas and broke it into a sequenced, time-boxed set of activities a distributed team could actually run together, not a template to fill in alone. Not a deck about methods; the working materials a team could sit down and use.

From the Lean foundation, the model flowed into an adapted design sprint, scoped for distributed teams, to carry one prioritized feature from a shared map through sketching, deciding, and a tested prototype.

The outcome

I piloted it with a willing cross-functional team. The pilot surfaced the precondition the whole model depends on: a team cannot align on solutions until it shares an understanding of the business goals, and that understanding has to be supplied, not facilitated into existence. It also exposed an expectation mismatch; the workshop was built to produce shared understanding and a tested direction, not a finished prototype to present upward, and that gap ended the pilot early.

It did not lead to org-wide adoption. But that is the most useful thing it produced: concrete proof that no amount of process manufactures the alignment a team needs when the foundational goals aren't there to build on. It is a lesson I carry into how I sequence this work now; establish the foundation, and confirm leadership can actually supply it, before asking a team to sprint.