CASE STUDY / PRODUCT DISCOVERY / FACILITATION / ORGANIZATIONAL ALIGNMENT
How an innovation workshop created a new direction for project discovery
A cross-functional design sprint helped our consulting team turn recurring delivery
problems into a repeatable, outcome-led discovery system: the Clarity Canvas.
The Clarity Canvas — a repeatable discovery process used across multiple client
engagements
01 / THE CHALLENGE
One week to understand an organization and start delivering.
Starting a new product engagement creates an unusual tension. Teams need to move
quickly, but the decisions made at the beginning can shape everything that follows. At
Rangle, we practised Scrum and limited Sprint 0 to a maximum of one week. That gave us
very little time to understand a client's organization, align stakeholders, identify the
right problems, and prepare a team to deliver working software.
SOME CLIENTS ARRIVED WITH
Little more than an idea.
OTHERS BROUGHT
Detailed specifications containing months of assumed requirements.
In both cases, the same risks appeared.
THE SAME RISKS, EVERY TIME
01
Stakeholders held different definitions of success.
02
Features were prioritized before outcomes were understood.
03
Important users or decision-makers were missing from early conversations.
04
Assumptions about technology, users, and workflows went untested.
05
Teams committed to more than the available time and resources could support.
When projects struggled, the cause could often be traced back to the beginning: the team
had started delivery without enough shared clarity. We needed a better way to begin.
02 / REFRAMING THE PROBLEM
Not faster requirements. The smallest shared understanding.
That distinction changed the direction of the work. A traditional requirements process
might produce a long list of features. We wanted a discovery process that would help the
team understand the outcome, the people, the journey, the assumptions, and how to
sequence around value. It also had to fit within a one-week Sprint 0 and work across
organizations with very different levels of preparation.
OUR INITIAL QUESTION WAS NOT
How can we collect requirements faster?
IT WAS
What is the smallest amount of shared understanding a team needs to begin delivering
the right value?
WE WANTED A PROCESS THAT HELPED THE TEAM UNDERSTAND
01
What outcome the organization needed
02
Whose behaviour or experience had to change
03
Which journey the product needed to support
04
What assumptions could derail the project
05
How to sequence work around value rather than feature volume
FITS A ONE-WEEK SPRINT 0
WORKS WITH ANY LEVEL OF CLIENT PREPARATION
03 / USING A WORKSHOP TO CREATE THE NEW DIRECTION
We treated the discovery process itself as a product.
Rather than designing the process in isolation, we brought the team together for an
innovation workshop based on the structure of a design sprint. We examined where
previous projects had lost alignment, generated alternatives, and used time-boxed
note-and-vote activities to identify the most important information a delivery team
needed.
DESIGN-SPRINT STRUCTURE
EXAMINE PAST PROJECTS
GENERATE ALTERNATIVES
NOTE
GROUP
VOTE
PROTOTYPE THE PROCESS
THE FORMAT CHANGED THE QUALITY OF THE CONVERSATION
WRITING INDIVIDUALLY
reduced the influence of the loudest voice in the room.
SHARING AND GROUPING
exposed recurring patterns.
VOTING
forced the team to make trade-offs.
CO-CREATION
gave the direction shared ownership rather than a procedure imposed from outside.
PARTICIPANTS
The people responsible for strategy, design, technology, and delivery: strategists,
product designers, developers, and delivery leads.
The workshop gave us more than a list of ideas. It created a common understanding of
the problem and enough confidence to prototype a new way of working.
04 / THE RESULTING CONCEPT
The Clarity Canvas: a facilitated discovery process organized around four questions.
The workshop produced the foundation for what became the Clarity Canvas. Each quadrant
asks one question, surfaces one kind of disagreement or gap early, and produces
artifacts that feed directly into delivery.
01
PROJECT GOALS
What outcomes should this product help the organization achieve?
We began by asking stakeholders to define success in business and customer terms.
This surfaced competing priorities early: a sales demonstration, scalability,
long-term operational efficiency. Making the differences visible allowed
stakeholders to negotiate scope while they still had meaningful control over time
and resources.
THE DISCUSSION PRODUCED
A shared project-goal statement
Business success measures
Important milestones
A strategy for prioritizing work
02
TARGET USERS
Whose cooperation or behaviour is necessary for the project to succeed?
We mapped both the people who would use the product and the stakeholders who could
influence its success, capturing goals, concerns, and relative priority. It also
revealed missing voices: if customer service, operations, or compliance was absent,
the team recorded that gap as a risk rather than treating the available perspective
as complete.
THE DISCUSSION PRODUCED
Primary users vs. internal stakeholders
Goals and concerns per group
Relative priority
Missing voices logged as risks
03
USER JOURNEY
What must happen for the most important user to achieve their most important goal?
Instead of beginning with screens or features, we mapped the activities and tasks
required to reach an outcome. The hierarchy of goals, activities, and tasks defined
the problem space and became the backbone for story mapping, usability scenarios,
analytics events, and release planning.
THE DISCUSSION PRODUCED
Goals → activities → tasks hierarchy
Backbone for the story map
Usability scenarios and analytics events
"Which complete flow delivers the most value next?"
04
RISKY ASSUMPTIONS
What would prevent the project from succeeding if our current understanding proved
wrong?
Throughout the workshop, we marked information the group was not confident about.
These uncertainties became an explicit list of assumptions and follow-up activities.
Uncertainty was no longer hidden inside a specification. It became visible work the
team could plan and manage.
DIFFERENT RISKS, DIFFERENT VALIDATION
Stakeholder risks → alignment conversations
Technical risks → spikes or prototypes
User risks → interviews, testing, analytics
Product-market risks → lean experiments
Timeline risks → prioritization and time budgets
05 / FROM WORKSHOP OUTPUT TO OPERATING SYSTEM
The canvas fed directly into delivery.
The canvas was not intended to be a workshop artifact that disappeared after the
session. Its outputs fed directly into delivery, creating continuity between discovery
and execution. The reasoning behind the roadmap remained visible rather than being lost
between the kickoff and the first sprint.
CANVAS OUTPUT → DELIVERY USE
PROJECT GOALS & SUCCESS MEASURES
Prioritization
USER JOURNEY
Backbone of the story map
RISKY ASSUMPTIONS
Research and technical-validation activities
MILESTONES
Sequencing releases around immediate business needs
A COMPLETED CANVAS PRODUCED
A shared project-goal statement
Business and product success measures
A prioritized set of users and stakeholders
A hierarchical journey of goals, activities, and tasks
A list of assumptions requiring validation
A focused set of preparation and research activities
A strategy for sequencing delivery
06 / WHAT CHANGED
Not a new canvas. A new starting point for product work.
Over multiple engagements, the process was refined into one or two focused sessions. Its
repeatable structure made it easier to bring the right stakeholders together, transfer
organizational context to delivery teams, and prepare new facilitators to lead the
process.
INSTEAD OF
Treating discovery as requirements collection
WE
Treating discovery as the creation of shared context
INSTEAD OF
Measuring progress by the number of features defined
WE
Focusing on the problems and outcomes that mattered most
INSTEAD OF
Allowing uncertainty to remain implicit
WE
Turning assumptions into a visible research and delivery agenda
[ADD VERIFIED EVIDENCE — number of projects, reduction in discovery time, stakeholder
feedback, delivery improvements, or examples of avoided risk]
07 / WHY THE INNOVATION WORKSHOP WORKED
It addressed both the process and the people who needed to adopt it.
Five conditions made the workshop more than an idea-generation exercise. Each one
converted a common failure mode of process change into a source of alignment.
01
It brought the whole system into the room
Product problems are rarely owned by one discipline. Including the people responsible
for strategy, design, technology, and delivery exposed conflicts that would otherwise
have surfaced later.
02
It made disagreement useful
Differences in goals and priorities were treated as information, not disruption. The
workshop gave the team a structured way to turn disagreement into explicit choices.
03
It converted assumptions into artifacts
The group left with more than shared enthusiasm. Goals, journeys, priorities, and
risks were recorded in forms that could guide subsequent work.
04
It created participation before adoption
The people who would use the new process helped design it. That participation produced
understanding and ownership before the process was introduced to client teams.
05
It treated the process as a prototype
The first workshop did not need to produce a perfect methodology. It needed to produce
something coherent enough to test. Running it on real projects created the feedback
required to improve it.
08 / MY LEADERSHIP CONTRIBUTION
Framing a facilitation problem as a systems-design challenge.
I helped frame recurring delivery problems as a systems-design challenge rather than a
facilitation problem. I continued refining the process through its use on client
projects and through feedback from facilitators and delivery teams, turning a workshop
concept into a repeatable practice that could be learned, applied, and improved by
others.
The workshop was the catalyst, not the complete solution.
Innovation workshops are particularly valuable when an organization knows its current
approach is not working but has not yet agreed on what should replace it. Their value is
not simply idea generation. The real impact came from connecting the output to everyday
delivery, testing it in real conditions, and continuing to improve it as the
organization learned.
01
Build a shared understanding of the current problem.
04
Create enough alignment to test a new direction.
02
Surface assumptions and conflicting priorities.
05
Turn discussion into artifacts that support action.
03
Give every discipline a meaningful role in shaping the response.
06
Establish collective ownership of the change.
10 / CLOSING
Clarity and ownership to move in a new direction together.
The Clarity Canvas began with a need to start projects faster and with greater
confidence. An innovation workshop helped us step back from the existing requirements
process, involve the people closest to the problem, and imagine a different way forward.
The result was a shared discovery system that connected organizational goals, user
needs, delivery priorities, and uncertainty.
That is what makes innovation workshops powerful: they do not merely produce new ideas.
At their best, they give a group the clarity and ownership required to begin moving in a
new direction together.