Most folks who read Lean UX or take a training course with us come out motivated and ready to try this new way of working. With a near equal sense of trepidation they always ask some variation of this question, “How do I get my company to try working with a Lean UX mindset?” We got this question so often we actually wrote a whole book about it. One of the ways we recommend teams start introducing Lean UX and product discovery into their ways of working (and this works for any change you’re implementing like OKRs, Scrum, etc) is to think of the process change like a product and apply the Lean UX process to de-risk it and increase it’s likelihood of success.
Treat your process like a product
In Lean UX we treat features and products as assumptions that need to be proven before we invest heavily in them. We can treat our process changes the same way. We make assumptions that our teams will benefit from a new way of working. We then define success as a positive change in the behavior of the “users” of the process (our teams, leaders, stakeholders). We form hypotheses from those assumptions to help us present our ideas in a way that reflects both the risk of implementing it and a clear definition of success that illustrates the benefit of running this experiment.
A process hypothesis can look like this:
We believe that implementing a Lean UX way of working will help designers, product managers and software engineers (the product team) get closer to their customers, increase their efficiency and spend less time on ideas that don’t drive customer success.
We will know we are successful when each product team has an outcome as their measure of success and is making evidence-based kill/pivot/persevere decisions on each of their backlog items.
Create process experiments to mitigate risk
Experiments reduce the risk of building something customers don’t want. Process experiments reduce the risk of implementing a way of working that won’t be successful at your organization. This is one of your stakeholders’ biggest concerns. Rolling out a new way of working is highly risky. How can we help build evidence for this change?
A process experiments takes the same questions we use in product development and focuses them on ways of working:
- What’s the most important thing we need to learn first?
- What’s the least amount of work we need to do to learn it?
Given our hypothesis above, one of the most important things we need to learn first is whether or not a team can even practice continuous learning within our current culture and what obstacles stand in the way of their success. We can design an experiment to help us learn that. It will be small and low-risk but significant enough to give us a sense of what we’d need to, org-wide, to get Lean UX (or any other process change) to take hold.
To learn what actual challenges Lean UX faces in our organization, one process experiment we can run is a pilot team. We take 5-10 people and form a small cross-functional team. We give them a timebox of 8-12 weeks. We challenge them to achieve a specific outcome – measurable change in human behavior – within that time frame using Lean UX as their primary way of working. In addition to the outcome goal we use other team health metrics to get a sense of whether this new way of working is impacting the team positively.
The pilot team begins to work in the new way. They are left alone and whole for the entirety of the experiment. Their responsibility is to figure out the new way of working and to report back, regularly on their progress, their learnings, their pivots and their challenges. Over the course of the experiment the pilot team will reveal the organizational blockers to Lean UX taking hold. They will collect evidence that illustrates the impact this new way of working is having on their productivity, efficiency and camaraderie.
Assessing the results of the experiment to determine next steps
At the end of the experiment we assess the data we collected. How did the team do against their outcome goals? How do their team health metrics fare? Do they want to continue working this way? What would it take to scale this to a 2nd team? A 5th team? A 20th team? Based on the data your stakeholders can now start to make informed decisions on this new way working, how to scale it and what they will have to do on their end to ensure its success.
By treating the process like a product we can introduce Lean UX to an organization in a way that mitigates the risk of a broad rollout. We use evidence to invest more heavily in the process and to justify broader implementation. We adjust the approach based on what the pilot teams learn and continue to discovery and solve new challenges as we scale. In this way we get our organizations to adopt Lean UX gradually with a focus on ensuring team health and productivity rather than a blind adoption of a new way of working.