Review
Product managers tend to skip this one because the cover says "UX." That is a mistake. Lean UX synthesizes Lean Startup, Design Thinking, and Agile into a coherent working approach, and the framework applies just as naturally to product decisions as it does to design ones. The book is dense with practical implementation advice, the kind that holds up when it meets real teams. I came away agreeing with almost all of it, which is a high bar for a book this prescriptive. The Lean UX Canvas and the hypothesis structure are the two things I return to most.
Key Takeaways
The parts worth keeping
Foundations of Lean UX
- Lean UX draws from four disciplines:
- Design thinking: apply design methods across every aspect of the business; center human needs; collaborate closely with non-design roles
- Agile software development: individuals and interactions over processes and tools; working software over documentation; customer collaboration over contract negotiation; responding to change over following a plan
- Lean Startup: Build-Measure-Learn; minimum viable products; reducing waste; increasing contact frequency with real customers; testing assumptions as early as possible
- User experience design: the discipline that ties the other three together in practice
- The goal: a collaborative, cross-functional, user-centered approach that surfaces the true nature of a product faster and builds shared understanding of the user, their needs, and what success looks like
- Lean UX is an approach, not a rulebook. Adapt it.
Principles of Lean UX
- Team organization:
- Cross-functional: tackle problems with multiple perspectives in the room
- Small, dedicated, colocated: better communication, sharper focus
- Self-sufficient and empowered: free to optimize their own process and engage directly with the market
- Problem-focused: give teams ownership of a problem, not a feature. The definition of done becomes solving the problem
- Culture:
- Move from doubt to certainty: treat everything as an assumption until proven otherwise; validate as quickly as possible
- Outcomes over output: an outcome is a measurable change in human behavior that creates value. Predicting which features will work is speculation. Measuring progress toward outcomes gives you real insight into what you're actually building
- Remove waste: anything that doesn't contribute to improved outcomes is waste; eliminate it to move faster
- Build shared understanding: it cuts through noise when you need to decide what to do next
- No rock stars, gurus, or ninjas: prioritize team cohesion over individual egos
- Permission to fail: teams need to experiment; people need to feel safe taking risks. Experimentation breeds creativity, which yields better solutions
- Process:
- Beware of phases: research, design, test, build, and deploy continuously rather than sequentially
- Iteration is the key to agility: expect to design and test multiple times before getting it right
- Work in small batches: create only what's necessary to move forward; large batches expose you to false assumptions
- Embrace continuous discovery: engage customers throughout development; make research frequent and regular
- Get out of the building: go where customers are, observe what they do, understand what they're trying to achieve and why
- Externalize your work: transparency drives shared understanding
- Make over analyze: there is more value in a first version than in debating its merits
- Exit the deliverables business: documents don't solve customer problems; good products do
The Lean UX Canvas
The canvas is designed to facilitate conversations with the team, stakeholders, and clients. It builds shared understanding and deliberately delays thinking about solutions until the surrounding context is clear.
| Business Problem | 1. Current goals for the product 2. Why the goals aren't being met now 3. A quantified request to improve the product |
| Business Outcomes | What will people be doing differently if our solution works? Outcome-to-impact mapping: a technique to visualize the connection between impact metrics and the tactical outcome you hope to see in your customers |
| Users | Don't put an overemphasis on demographics; instead focus on behaviors, goals, and needs Focus on information that predicts behavior Only write down the differences that make a difference |
| User Outcomes | Empathy is key to making great products Declare assumptions about what users are trying to do, as outcomes and benefits Put yourself in the shoes of the user: what are they trying to achieve? |
| Solutions | The process deliberately delays thinking about solutions until this point What could get you from the current condition to the target condition Question: What solutions can we design and build that will serve our personas and create their desired outcomes? Generate as many ideas as possible |
| Hypothesis | Hypothesis structure: • We believe we will achieve [the business outcome] • if these [personas] • attain [this benefit/user outcome] • with [this feature or solution] Prioritize based on risk vs perceived value |
| What to learn | The biggest risks are usually related to the value of the solution. ◦ Do people need it? ◦ Will they look for it? ◦ Will they try it? ◦ Will they use it? ◦ Will they find value in it? Feasibility is only a limiting factor if the above are true |
| How to learn | Prioritize ruthlessly; ideas are plentiful. Let the best ones prove themselves, don't hold onto the ones that fall short. If you don't have a lot of evidence, put less effort into your MVP. Anything more is a waste. |
Research and validation
- Three levels of user commitment:
- Time: can you get 30 minutes of their time to discuss the problem? If not, the problem isn't worth solving
- Social (reputation): will they endorse it? Socialize it? Take it to their boss? Introduce you to others?
- Money: would they purchase?
- Low fidelity means everyone can contribute and the work stays malleable
- Research should inform the decisions the product team is making; test whatever is ready on testing day
- Redefine done as validated, not finished:
- Did people find it?
- Did they use it?
- Were they successful?
- Did they return to use it again?
- Did they pay?
- Remove handoffs: don't hand designs to developers; it creates loss of context and wastes time producing materials that replace direct shared understanding
- Dual-Track Agile is the target: one team doing discovery and delivery in parallel
- Measure exposure hours: the amount of time each team member is directly exposed to real users (Jared Spool's concept). Aim for at least 2 hours every 6 weeks.
- It is not an abdication of vision to admit that the complexity and uncertainty of your situation means you can't predict the shape of the most successful product at the start of the quarter