A better way to build products
Lean UX: Applying Lean Principles to Improve User Experience by Jeff Gothelf with Josh Seiden
Lean UX identifies the lack of objectivity as one of the fundamental causes of product failures. A subjective approach results in a closing off customer discovery and relies on individual opinion. Many companies and products serve as clear warnings as to why this approach does not work. In Lean UX, authors Jeff Gothelf and Josh Seiden outline the Lean UX approach which blends agile software development with design thinking and the Lean Startup method. By using continuous discovery and “replacing requirements with assumptions,” they seek to remove the waste that traditional product development entails and causes. Viewing requirements as assumptions removes many of the risks that subjective, siloed, and documentation-centric product development methods struggle with. Once you frame your requirements as assumptions to be verified with your target market against objective business outcomes, you take the first step to a faster and more effective way to validate and develop new products.
Why products fail
In this UX London presentation, Gothelf dissects the failure of plancast by elaborating the founder’s post mortem on the company. Contributing factors to the service’s demise were:
- not checking whether there was a market for their product outside early adopters
- using vanity metrics
- ignoring clear signals from their customers that their value proposition was not important
- believing that it is not possible to perform market validation with social products
- the team only discovered key information about their product market after launch
- using subjective opinion rather than objective information to make feature decisions
Implied in these factors were several key questions the team needed to answer:
- How long do we wait before launch?
- How do we define the right requirements for our product?
- What signals are we looking for from the market to indicate that we have product/market fit, that we have traction, that we’re retaining users, and that we’re activating users?
Requirements are actually assumptions
Although requirements may be well researched and educated guesses, they are still just assumptions about the product and its design, and target market and their needs. After the analysis and rigorous thinking are done, a product manager (or similar role) has to make a subjective decision about which feature to invest in. Regarding requirements as assumptions entails a cultural shift from certainty and large, front-loaded planning efforts to experimentation and objective measurement. With experimentation inevitably comes failure; however, if the experiment is small and focused, the scope of the failure will be small and the payoff will be knowledge about the product and the market. Embracing failure is hard–how can you get your organization to embrace it?
Once requirements are seen as assumptions, “what we know” becomes “what we believe” and “let’s build it!” becomes “let’s test it!”
So before we spent millions of dollars and hours of our time making sure the infrastructure can handle a button that no one is going to click, let’s see if they’ll click the button first.
As a style of thinking, it is generally considered the ability to combine empathy for the context of the problem, creativity in the generation of insights and solutions and rationality to analyze and fit solutions to the context
Design thinking, popularized by IDEO, does not define a discipline and does not constrain who can participate in design. It is an inclusive activity which involves the whole team.
Inspired by Lean Startup and Agile development theories, it’s the practices of bringing the true nature of the product [user experience] to light faster, in a collaborative, cross-functional way with less emphasis on deliverables and greater focus on a shared understanding of the actual experience being designed.
When put together, these three approaches (Agile, Design Thinking, Lean UX) lead to prioritizing learning over growth. This is a variation on “nail it, then scale it”. Once you know what works for your customers, your product, and your business, then you can begin to scale and grow.
Product Definition Assumptions
Getting alignment on a product key is critical. Ask these questions to understand whether the product team is on the same page:
- Who is our customer?
- What pain points do they have related to our product or service?
- How will our product/service solve their pain points?
- What features are important?
- What is our differentiation?
- What is our business model?
Take the answers to the questions above and phrase them as a hypothesis to shift from “go build this!” to “we think this will work–we’re going to test it first”:
We believe that
[building this feature]
[for these people]
will achieve [this outcome].
We will know we are successful when we
see [this signal from the market].
Case Study: TheLadders.com
When Gothelf worked as Design Director for TheLadders.com the CEO came to them with an epiphany: personal representatives would be assigned to each paying customer in order to increase acquisition and retention. Nine months later, the product launched and failed.
The requirement was: Provide each paying customer with a personal job search assistant available via email and phone
Turning this into a hypothesis yields: We believe that providing a personal assistant to each customer will drive up customer satisfaction, renewals and retention rates
When the team asked themselves How could we have better defined our products?, they determined that there were several areas for improvement:
- Articulated our assumptions
- Defined our hypotheses
- Run lightweight tests to validate the need
- What outcomes were we targeting?
The team needed to start with the archetypical question: What problem are you trying to solve?
- How will you solve it?
- How do you know it will work? (what is the measure of success?)
The measure of progress changes from outputs to outcome (from “build me this feature” to “achieve this business outcome”)
Gothelf advises to focus teams on outcomes they can actually affect, rather than metrics they can only impact, such as revenue and customer satisfaction.
Changing the way we make products
When objective experimentation, business metrics, collaborative design, and iterative releases are combined, Gothelf’s mindshift can be achieved:
- Requirements are assumptions
- Focus on outcomes
- Work together to come up with ideas
- Test those ideas ruthlessly