Download the DDRSM checklist for digital product initiatives.
DDRSM stands for Dream, Define, Recommend, Solve, Measure.
It’s a way of working I developed over time because I kept running into the same situation. Teams want to do the right thing, but they often start without enough clarity. Everyone is moving, but not always in the same direction.
DDRSM helps slow things down just enough to understand what we’re solving, and then move forward with purpose.
Why I use it
Every project is different, but the patterns are often the same:
- unclear goals
- unclear users
- unclear success criteria
- lots of opinions
- lots of assumptions
- very little alignment
DDRSM brings structure without being rigid. It creates space to think, align, and make better decisions before moving too quickly into execution.
Over time, it’s helped teams:
- get aligned
- make more confident decisions
- build with intention
- connect the why to the what and how
A few principles that guide the work
For this method to work, a few things need to stay true throughout.
- The right people are involved at every stage
Each function or team has a seat at the table - Everyone understands the direction
Not just at a high level, but clearly enough to explain it and act on it - We don’t move forward with ambiguity
If something is unclear, we stay with it until it isn’t - Progress requires more than agreement
It requires intent and conviction
The Five Stages
This is where it starts.
There’s always a need behind it. Something isn’t working the way it should, or something is missing.
That need turns into a simple, direct thought:
“This should be better.”
“I would love…”
“I wonder if we could…”
From there, the idea begins to take shape. We give it direction, start sharing it, and bring others into the conversation. The goal is not to solve everything yet, but to build enough shared understanding and momentum to move forward.
It can be as simple as deciding what to eat, or as complex as rethinking how a system works.
This is where things become clear.
Once there’s agreement to move forward, we take the time to understand what we’re actually working with and what it means in practice.
What do we know?
What don’t we know yet?
Who’s involved?
What are the constraints?
This is where assumptions are surfaced, research is brought in, and business rules begin to take shape. The goal is to move from a general idea to something that is clear, grounded, and ready to act on.
By the end of this stage, the direction should feel understood and committed. Others can step in, engage, and know what’s being proposed and why.
Recommend is where that direction becomes a decision.
With a clear understanding of the situation, we begin to outline how the need can be addressed.
What are the options?
What fits within the constraints?
What is most likely to work?
This is where designs are proposed, systems are considered, and paths forward are evaluated. The goal is to arrive at a recommendation that others can review, challenge, and align around.
This is where the work becomes real.
With a clear direction in place, we move into building, testing, and refining.
What are we creating?
How does it behave in the real world?
What needs to be adjusted as we go?
This is where the recommended direction is brought to life. In the context of digital products, this is where software is built, tested, and launched.
The goal is not just to execute, but to do so with intention, staying grounded in what was defined and recommended.
It can be as simple as preparing and serving the meal, or as complex as building and launching a new system.
This is where we step back and assess.
After something has been delivered, we take the time to understand what actually happened and how it compares to the original intent.
Did it work?
Did it make things better?
Did it fulfill the dream?
This is where results are evaluated, feedback is gathered, and outcomes are understood. The goal is to learn from what was done, understand the impact, and determine what should happen next.
It can be as simple as tasting the meal and deciding if it delivered on what you were hoping for, or as complex as measuring performance, adoption, and impact across a system.
How it shows up in my work
I use the DDRSM method across different types of work, from small UX improvements to larger product and service design efforts.
It’s helped teams bring clarity to complex systems, align across functions, and move forward with more confidence.
One example is the Employee Initiated Move (EIM) application, where this approach helped uncover real pain points, shape a clearer experience, and measure meaningful improvements. (You can read the case study if you’re curious.)
DDRSM keeps the work grounded in what matters: the problem, the people, and the outcome.
If you want to go deeper
I’ve written more about this approach in a series of articles:
Most teams don’t struggle because they lack ideas. They struggle because they move too quickly from idea to solution.
Understanding DDRSM Through a Simple Night Out
Find the antidote to chaos and avoid headaches.
Kick Ass Process Part 1: Dream, Define, Recommend, Solve, Measure (DDRSM)
How Toyota Became So Successful by Implementing a Process
Kick Ass Process Part 2: A Tale of Process Success
If you’re trying to bring structure to something complex, I’m happy to take a look.
Get in touch
Book a chat with Luis
contact@luisbarriga.com
LinkedIn Profile