Review

Even though it seems positioned more toward designers, this is an incredibly important book for product managers. It does a great job of integrating the concepts from Lean Startup with existing methodologies (Design Thinking, Agile, UX design). It’s packed full of principles and practical implementation advice for teams. There’s little in this book I disagree with.

Key Takeaways

The 20% that gave me 80% of the value.

• Lean UX = Lean Startup + Design Thinking + Agile + User Experience Design
  • Reduce waste, encourage team participation and have an experimentation mindset
• Show work early
• Deployment of code isn’t the measure of success, impact is.

• Lean UX is an approach, not a set of rules.

Foundations of Lean UX

• User Experience Design / Design thinking
  • Using design methods on every aspect of the business
  • Consider human needs
  • Close collaboration 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 method
  • Build-Measure-Learn
  • Minimum Viable Products
  • Reducing waste
  • Increasing frequency of contact with real customers
  • Testing assumptions as soon as possible
• Definition of Lean UX
  • A design approach
  • Collaborative, cross-functional and user centered
  • Brings the true nature of a product to light faster
  • Builds a shared understanding of:
    • the user + their needs
    • our solutions + definition of success
  • Prioritizes continuous learning to build evidence for decision making

Principles of Lean UX

• Team organization:
  • Cross-functional → best to tackle a problem with different points of view
  • Small, dedicated and colocated → for communication and focus
  • Self-sufficient and empowered → free to optimize their process, faster learning, can engage with the market
  • Problem-focused → give teams ownership of a problem, so they can find the best solution. The definition of done becomes solving the problem
• Culture:
  • Moving from doubt to certainty → Everything is an assumption until proven otherwise. Validate assumptions as quickly as possible. Enthusiastic skepticism.
  • Outcomes over output → Outcome = a measurable change in human behavior that creates value. Predicting what features will work is speculation. We’re bad at predicting if something will work in the market. By measuring progress toward outcomes we gain insight into efficacy of the features we’re building.
  • Removing waste → anything that doesn’t contribute toward improved outcomes is waste. Eliminate waste to move faster.
  • Shared understanding → so you can cut through the noise and work out what to do next
  • No rock stars, gurus, or ninjas → prioritize team cohesion over individual egos
  • Permission to fail → teams need to experiment, team members need to feel safe to take risks and fail. Experimentation breeds creativity, which yields innovative solutions.
• Process:
  • Beware of phases → research, design, test, build and deploy continuously
  • Iteration is the key to agility → expect to design and test your work multiple times until you get it right
  • Work in small batches to mitigate risk → create only what’s necessary to move the team forward. Large batches leave you exposed to false assumptions and potential wasting of work
  • Embrace continuous discovery → engage customers throughout the development process. Make customer research frequent and regular. Increases empathy, create a shared understanding, validate product ideas
  • Get out of the building → go where they are, observe what they do, engage with them, understand what they’re doing, trying to achieve and why.
  • Externalize your work → transparency and shared understanding.
  • Make over analysis → there’s more value in creating version 1 that discussing its merits
  • Get out of the deliverables business → focus on the output not the documents. Documents don’t solve customer problems. Good products do.

• Prioritize results over documentation and artifacts
• Only make things that generate the outcomes we want
• Focus on the value we’re trying to create, test solutions until you achieve the outcome
• Definition of an outcome: a change in human behavior that creates value.
• Shifting focus from outputs to outcomes changes your definition of done
  • To measure outcomes we must ship and observe (validation)
  • Often requires iteration, don’t expect to get everything right on the first attempt
  • Build-Measure-Learn (Lean UX) or Inspect and Adapt (agile)
  • No more one-and-done

• The Lean UX Canvas is designed to facilitate conversations with the team, stakeholders, clients etc
  • helps build a shared understanding

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 of 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.

• Three levels of 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? Will they introduce you to others?
  • Money: Would they purchase?

• Low-fidelity means everyone can contribute and maintains malleability of the work
• Don’t go into a sprint thinking what can we build? Think about how to solve the problem
• Research should inform the decisions the product team is making
• Making sense of research as a team
• Test what you’ve got → test whatever is ready on testing day
• Create a 360 view of the customer from research and information sources

• From the agile manifesto: we value responding to change over following a plan
  • Embrace learning, be humble, change your plan based on what you learn

• Redefine done as validated (not finished)
  • Scrum uses acceptance criteria and a definition of done
  • Lean UX adds:
    • Did people find it?
    • Did they use it?
    • Were they successful?
    • Did they return to use it again?
    • Did they pay us for it?
  • Validation starts with customers
• Remove hand-offs. Don’t hand designs over to developers. Creates loss of context and wastes time producing materials
• Dual-Track Agile is the best. Teams do discovery and delivery. Works best when its one team.

• Measure exposure hours: the amount of time each member of your team is directly exposed to users (Jared Spool’s concept). Should be at least 2 hours every 6 weeks.

• Use risk dashboards and outcome-based roadmaps
• It is not an abdication of vision to admit that the complexity and uncertainty of your situation means that you can’t predict the shape of the most successful product at the start of the quarter

• Lean UX is a mindset
• Changing culture:
  • Be humble
  • Embrace new skills
  • Create open, collaborative workspaces
  • No heroes
  • Fall in love with the problem not the solution
  • Evolve agency culture (don’t focus on deliverables, focus on outcomes, be one team)
  • Be realistic about your environment
• Shifting Team Organization
  • Think competencies over roles
  • Create cross-functional teams
  • Create small teams
  • Work with distributed teams
  • Build flexibility into third-party vendor relationships
• Shifting process
  • Plan work using outcomes, not output
  • Beware of BDUF (Big Design Up Front) sneaking into Agile environments
  • Embrace speed first, aesthetics second
  • Tackle UX debt (plan for iteration, present rework as debt)
  • Rethink documentation practices
  • Manage up and out (to compensate for outcomes not features)