A better way to build products
Lean UX: Applying Lean Principles to Improve User Experience
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?
Rethinking Requirements
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.
Design Thinking
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
–Tim Brown
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.
Lean UX
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?
Product Hypotheses
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?)
Measuring 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
