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.

You Might Also Like:

Lean Analytics

Lean Analytics is an incredibly insightful, data-driven approach specifically designed to rapidly assist startups in building superior products. Expertly co-authored by Benjamin Yoskovitz and Alistair Croll, this book serves as an invaluable guide to understanding the most effective way to measure progress. It empowers businesses to ask the most impactful questions and discern what vital information can be gleaned from the data to make swift and informed decisions in our ever-changing market. This book is absolutely essential for entrepreneurs, data analysts, and product managers who are determined to leverage data to drive their product strategy.

andrewclark.co.uk

Book Review and Summary: Hacking Growth by Sean Ellis and Morgan Brown

Get a comprehensive review and summary of the best-selling book "Hacking Growth" by Sean Ellis and Morgan Brown, the growth experts and authors. Learn about the key principles and practices for driving rapid and sustainable growth in your business

andrewclark.co.uk

The Lean Startup

This is a hugely influential book in the product management community. The Lean Startup codified how to take a scientific approach to create and manage startups. The author also explains why traditional firms have such trouble navigating uncertainty. The Lean Startup emphasises the importance of learning, and validating assumptions. This book popularised a number of concepts that are now considered foundational in product management (e.g. build-measure-learn, pivot, minimum-viable-product). It’s a must-read for anyone building digital products.

andrewclark.co.uk

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 centred
• Brings the true nature of a product to light faster
• Builds a shared understanding of:
• the user + their needs
• our solutions + definition of success
• Prioritises continuous learning to build evidence for decision making

Principles of Lean UX

• Team organisation:
• Cross-functional → best to tackle a problem with different points of view
• Small, dedicated and colocated → for communication, focus and camaraderie
• Self-sufficient and empowered → free to optimise 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 behaviour 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 → prioritise 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.
• Externalise 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.

• Prioritise results over documentation and artefacts
• 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 behaviour 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

• 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? socialise 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 handoffs. 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 Organisation
• 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 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)

Deep Summary

Longer form notes, typically condensed, reworded and de-duplicated.

Preface

• Lean UX is the junction of the Lean Startup methodology and user experience design. Three principles that come across:
• Reduce waste → do just enough design to move the conversation forward, de-emphasise artefacts
• Team participation → cross-functional team, encouraged to take part in the process
• Experimentation mindset → a shift toward validated learning, experimentation and measurement.
• Lean UX: Lean Startup + Design Thinking + Agile + User Experience Design
• Design thinking brings team-wide empathy for the end user
• Agile brings shorter cycles, regular delivery of value and continuous learning
• We ensure we’re solving a real problem for real customers in a meaningful way
• Show work early. Overcome the feeling that we’re showing work that’s unfinished or ugly:
• First attempts require revision. Better to know what revisions sooner.
• Waiting too long is wasteful.
• The more effort that the team have put in, the harder it is to admit it needs to change
• Deployment of code isn’t the measure of success, impact is.

Part 1: Introduction and Principles

Chapter 1: More Important Now than Ever Before

• Radically reduced cycle times allow rapid feedback and continuous improvement in a way that was unthinkable for physical goods. We can now discover and deliver the product at the same time.
• Production of physical products is expensive, so design happens up front.
• When interaction design was introduced (in the early days of digital) it still happened that way. Distribution was via floppy disks and CDs
• We are no longer limited by physical manufacturing process. We can get software to customers at pace. This changes everything.
• Lean UX allows teams to exploit this new reality. Maximise learning, continuous discovery of the best path forward while amplifying the voice of the customer.
• Foundations of Lean UX:
• Deeply collaborative and cross-functional
• Continuous engagement
• De-emphasise deliverables in favour of shared-understanding
• Spend more time gathering insight
• From features to outcomes (customer, business and user goals)
• Measure, learn and adjust

Chapter 2: Principles:

• 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 centred
• Brings the true nature of a product to light faster
• Builds a shared understanding of:
• the user + their needs
• our solutions + definition of success
• Prioritises continuous learning to build evidence for decision making

Principles of Lean UX

• Team organisation:
• Cross-functional → best to tackle a problem with different points of view
• Small, dedicated and colocated → for communication, focus and camaraderie
• Self-sufficient and empowered → free to optimise 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 behaviour 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 → prioritise 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
• Don’t do the same thing faster (when adopting agile)
• 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.
• Externalise 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.

Chapter 3: Outcomes

• How we used to think about software projects:
• defined by their deliverables
• requirements didn’t need context
• Lean UX instead sets a team’s direction by tasking them with positively affecting behaviour to create an outcome.
• Prioritise results over documentation and artefacts
• 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
• If you’re asked to deliver a feature, work with your stakeholders to understand why
• Definition of an outcome: a change in human behaviour that creates value.
• We are using an inherently human-centred idea to define success
• The Logic Model: From the Kellog Foundation
• Resources → Activities → Outputs → Outcomes → Impact
• Who is getting value from the behaviour in question? Value depends on your point of view. Every outcome is expressed from a point of view.
• Aligned Value: creating value for users in a way that creates value for your organisation
• No system can be described by a single outcome statement. There are often different people, behaviours and points of view. So framing and prioritisation of outcomes is important
• 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

Part 2: Process

• Lean UX canvas can guide you through the Lean UX process

Chapter 4. The Lean UX Canvas

• Assumptions are the new requirements
• Requirements assume we know what we need to build
• Requirements often mean ‘shut up’
• Our world is unpredictable, unstable, uncertain and inconsistent.
• Somethings are easy to say and hard to build
• Humans are complex and unpredictable
• Instead: Recognise that requirements are assumptions expressed with authority
• Let’s be humble, and admit we’re guessing and that predicting human behaviour is hard
• Let’s include experimentation, research and rework into our approach
• Reduce our attachment to our ideas, and increase our flexibility
• Instead ship, sense and respond.
• Express ideas as testable assumptions
• The Lean UX Canvas is designed to facilitate conversations with the team, stakeholders, clients etc
• helps build a shared understanding

• Designed to guides the conversation
• 1,3 = now
• 5 = how we get there
• 2,4 = later
• 6,7,8 = how we will find out if we’re right

• Encourage the team to use it and get involved in discovery work
• It’s a good way to kick-off a project
• Don’t have to use it to do Lean UX
• On facilitation:
• Be inclusive
• Use the 1-2-4-all Pattern:
• 1: Ask people to generate ideas themselves, (set aggressive time limit) and share back with their sub-group / table
• 2: Ask people to work in pairs, present work back to the table/subgroup.
• 4: Get each group/table to work together, and produce a simple presentation
• All: You can ask the whole group to develop a single idea:

Chapter 5. Box 1: Business Problem

What problem does the business have that you are trying to solve? Hint: Consider your offering, how it delivers value, changes in market, channels, competition and customer behaviour)

• Give teams a problem to solve not a solution to build
• Use business problem statements to reframe in a way that forces product discovery
• Business problem statements should:
• Provide a challenge to solve (not features to build)
• Anchor the team on customer-centric success
• Constrain the team (make it clear what’s in or out of scope)
• Provide a clear measure of success (through a KPI or customer outcomes)
• Not define a solution
• Three parts to the business problem statement
1. Current goals for the product
2. Why the goals aren’t being met now
3. A quantified request to improve the product
• Template for existing product:
• [Our product] was designed to achieve [these business / customer goals and deliver this value].
• We have observed [in these ways} that the product/service isn’t meeting these goals, which is causing [this adverse effect / problem] to our business.
• How might we improve the product so that our customers are more successful as determined [by these measurable changes in customer behaviour]
• Template for new product:
• The current state of [domain we’re working in] has focused mainly on [these customer segments, pain points, workflows].
• What existing products/services fail to address is [this gap or change in the market place]
• Our product/service will address this gap by [this product strategy or approach]
• Our initial focus will be [this audience segment]
• Facilitation:
• Provide context and background
• What have we observed and measured that leads us to believe there’s an issue
• Who are we targeting?
• How does this fit into the strategy?
• What is the impact of fixing and not fixing this problem on company health?
• Write a draft in small groups (30 minutes)
• Come back as a team, critique, feedback and ask clarifying questions about each draft
• Combine into larger groups until you’ve got one view
• What to watch out for:
• Don’t specify the solution
• Get the level right. The team must be capable of solving it.
• Be specific →
• set clear business-level success criteria for the team. If in doubt push for specificity
• be clear about what you’re addressing

Chapter 6. Box 2: Business Outcomes

How will you know you solved the business problem? What will you measure? (hint:what will people/users be doing, consider success metrics)

• Be clear about the behaviour changes you’re seeking
• Success criteria tend to be KPIs or impact metrics (revenue, profit, customer satisfaction)
• Work together to uncover the leading indicators of those impact metrics
• What will people be doing differently if our solution works?
• Should start with a verb:
• Something customers do, and we want them to do it more
• Something customers do, and we want them to do it less
• Something new that we’d like them to start doing
• The goal is to visualise flow through the product in a way you can talk about the most important parts, identify specific behaviours, and determine outcome metrics that indicate success
• Using the user journey:
• Find the valuable user behaviours you want to focus on
• What are people doing today?
• What’s difficult?
• What’s not productive?
• What new valuable behaviours could we unlock?
• User journey mapping
• Pirate Metrics or Metrics Mountain
• Pirate Metrics: AARRR
• Acquisition: getting customers to the product (downloads, sign up)
• Activation: using the product (accounts created, follows, likes, purchases)
• Retention: using it beyond first use, coming back, frequency, time spent
• Revenue: payments, purchases, conversion, paid vs free, average lifetime valure
• Referral: referring friends, writing reviews,
• Alternatively you could build a service journey may or user story map
• Outcome-to-impact mapping → a technique to visualise the connection between impact metrics and the tactical outcome you hope to see in your customers
• Visualises leading and lagging indicators
• Impact metrics are often lagging
• Lower-level metrics are often leading
• A download is a leading indicator of somebody spending money on an app
• There are often many leading indicators to one or two impact metrics

• Exercise/Facilitation:
• Write down the strategic goal
• List out the measures of success for that strategy
• Draw lines protruding away from each one
• Fill out the line below, with customer behaviours that drive those metrics (leading indicators)
• Now have the team do another row below the last one, showing the customer behaviours that drive those
• Dot vote to get the team to pick where they think they should focus first
• Demonstrates that there are many ways to achieving the goal
• Create a baseline and a goal → assign the goal to the team
• What to watch out for
• Stick to measures of customer behaviour
• Things will get messy and there’s often not a one to one relationship
‣
Real Example

Chapter 7. Box 3: Users

What types of users and customers should you focus on first? Hint: Who buys your product? Who uses it? Who configures it?

• Keep the user at the centre of your thinking
• Be careful of creating personas from lengthy research
• They are viewed as untouchable
• If a 3rd party created them, then there will be a knowledge gap
• Persona creation is an ongoing process not a one-time activity
• Start with assumptions, validate with research
• Call them proto-personas initially
• Adjust hem as you learn more
• How proto-personas help:
• They form a shared understanding. Allow the team to replace ‘the user’ with a persona in conversations makes things more precise
• Help us remember we aren’t the user, and build empathy.
• Don’t put an overemphasis on demographics
• instead focus on behaviours, goals, and needs
• Focus on information that predicts behaviour
• Only write down the differences that make a difference
• Users rarely need features, they’re wanting instead to achieve a goal

‣

Example proto-persona focuses on needs and obstacles and goals:

• Facilitation:
• Brainstorm, create a list of types
• Narrow down the ideas to a list of 3 or 4 (that best describe the target audience)
• Differentiate the personas around needs and roles (not demographics)
• Have the team complete a proto-persona template for each (break into groups that each focus on one persona)
• Revise each persona based on feedback
• Early validation:
• Use personas as recruiting targets to begin research
• Does this customer exist?
• Do they have the needs and obstacles you think?
• Would they value a solution to this problem?
• Don’t stop at the initial exercise.
• Keep going back to them, make them living documents

Chapter 8. Box 4: User Outcomes / Benefits

Why would your users seek out your product or service? What benefit would they gain from using it? What behaviour change can we observe that tells us they’ve achieved their goal?

• 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?
• If there’s a difference between the buyer and the user, be sure to consider both their needs
• As well as behaviour change, there are often emotional goals
• All of them should be called out, emotional ones are hard to quantify, especially in metric driven teams. But they’re still important, don’t forget them
• Facilitation:
• What is the user trying to accomplish?
• How does the user want to feel during and after the process?
• How does our product or service get the user closer to a life goal or dream?
• Why would your user seek out your product?
• What behaviour change can we observe that tells us they’ve achieved their goal?
• Thinking about outcomes in these terms, can help you find both task-oriented outcomes and emotional experience-orientated outcomes
• These assumptions are great for helping you with copywriting (for marketing and advertising)
• Don’t write down features in this section.

Chapter 9. Box 5: Solutions

What can we make to solve our business problem AND meet the needs of our customer? (product and feature enhancements)

• The process deliberately delays thinking about solutions until this point
• Treat the previous sections as constraints, that restrict your solution space (business problem, outcome, user definition, user outcomes)
• Time to get specific on what could get you from the current condition to the target condition
• Facilitation / Exercise:
• Affinity Mapping
• Simple and easy way to get the team working together
• Question: What solutions can we design and build that will serve our personas and create their desired outcomes?
• Individually brainstorm ideas that solve business problem, outcome and user outcomes for your target user (5 minutes)
• Generate as many ideas as possible (one per post-it note)
• Share ideas with each other, group similar ideas.
• Dot vote which approaches they believe stand the greatest chance of success
• Collaborative design / Design Studio
• This approach helps bring your team together and build trust. The goal is to visualise potential solutions to a design problem
• Gather the team for a block of time in a dedicated space (best with wall space to post up work as you go)
• Works best for 5-8 people (split into teams if you have more)
• Sections:
1. Problem definition and constraints (15 mins)
• Share the work on the Lean Canvas to date
2. Individual idea generation (10 mins)
• Give each team member a 6-up template
• You can label each box with a persona and pain point if it helps
• Give everyone 5 minutes to generate 6 low-fidelity sketches of solutions for each persona/problem pair on their sheet
• Can be UI sketches, workflows, diagrams but not written words
3. Presentation and critique (3 minutes per person)
• Presenters should state who they’re solving a problem for and which pain point they’re addressing
• Provide critique and feedback to the presenter. Team members should focus their feedback on clarifying the presenters intentions
• Asking questions is better than opinions
4. Pair up to iterate and refine (10 mins)
• Pick the best ideas
• Refine them
• Make some decisions and get more specific
• Bring everyone together and do the critique again
5. Team idea generation (45 mins)
• The goal is to now converge on an idea
• To select the ideas that have the best chance of being successful
• The ideas will become hypothesis in the next step
• Sketch the workflow or components together in larger form
• Expect compromise and wrangling to get to consensus
• Prioritise and pare back features.
• Have a parking lot for good ideas that don’t make the cut
6. Design studio outputs can feed into hypothesis and experiment design
7. Keep the output visible, post it on a wall
8. Photograph everything to keep it in an archive folder
9. Try to keep participation even, facilitation is key

Chapter 10. Box 6. Hypothesis

Combine assumptions from 2,3,4 &5 into a hypothesis statement matching the template below:

• A hypothesis is a supposition made on the basis of limited evidence as a starting point for further investigation
• Our goal is to gather the assumptions, gather them into a unified statement, so that we can begin our research and testing process.
• Template:
• We believe we will achieve [the business outcome]
• if these [personas]
• attain [this benefit/user outcome]
• with [this feature of solution]

• If you can’t put together a compelling hypothesis for a solution, then it doesn’t deserve to go beyond this stage. Use a table for all your solutions:
• A compelling hypothesis has a clear user, who gets an obvious benefit from the feature, and the subsequent behaviour change helps solve a business problem.
• Solutions can serve multiple personas, or you might have multiple features drive the same outcome.
• Try to refine and focus on one feature, as multiple feature hypothesis are harder to test. Think about testability.
• Prioritise hypothesis:
• What’s risky and needs testing?
• What’s not risky and thus easy to start?
• You can use a hypothesis prioritisation canvas to help, but that’s essentially risk vs perceived value
• Test those that are high risk, high value
• Build high value, low risk
• Discard high risk, low value
• Build if table stakes/expected else ignore low value, low risk
• Avoid writing hypothesis that are too big to test!

Chapter 11. Box 7. What’s the most important thing we need to learn first?

For each hypothesis, identify the riskiest assumptions. Determine the riskiest one right now. Focus on risks to value not feasibility.

• Goal is to highlight major risks for each hypothesis
• What’s the most important thing we need to learn first about this hypothesis?
• Uncover what could break your hypothesis → focus on assumptions that will render the hypothesis invalid and allow us to move on quickly if we’re wrong
• 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
• If you can’t reach consensus, you might need more information. To get more information, you might need to make a decision and move forward to experimentation

Chapter 12. Box 8. MVPs and Experiments

What’s the least amount of work we need to do to learn the next most important thing?

• A lean principle is to do the least amount of work
• What’s the least amount of work we need to do to learn the next most important thing?
• The faster you find out if your idea is something you should continue working on the better. You’ll waste less on bad ideas, and teams will be more agile as they’d have invested less
• The experiments in this box can be Minimum Viable Products
• Definition from Lean UX: A small and fast way of learning something.
• Your primary concern is not to create value but to learn something
• One of the key things you’re trying to learn is what the market finds valuable
• How to create an MVP to Understand Value:
• Get to the point. Focus on the core value proposition
• Use a clear call to action
• Measure behaviour
• Talk to your users. Analytics tell you what people did, conversations can tell you why.
• Prioritise ruthlessly, ideas are plentiful. Let the best ones prove themselves, don’t hold onto the ones that fall short.
• Don’t reinvent the wheel. Think about the fasting way to test, leverage other platforms
• Some other principles:
• It’s not easy to be pure, you’ll find that it’s not always possible to test only one thing at a time
• Be clear about your learning goals → make sure that you know what you’re trying to learn, and make sure you are clear about what data you need to collect to learn
• Start small → regardless of your desired outcome, but the smallest MVP possible
• You don’t necessarily need code
• The Truth Curve → the amount of effort you put into your MVP should be proportional to the amount of evidence you have that your idea is a good one.
• If you don’t have a lot of evidence, put less effort into your MVP. Anything more is a waste.
• The truth curve is a reminder that big investments aren’t warranted unless the facts dictate it

• Examples of quick MVPs:
• Feature Fake / Button to nowhere
• Landing page test
• Wizard of Oz
• On prototyping:
• Prototyping is a way to approximate an experience, it allows you to simulate what it’s like to use the product or service
• Minimise the effort of creation
• Be clear on why you’re creating it
• Who will be interacting with it?
• What do you hope to learn?
• What you already know to be true?
• How much time you have to create it?
• Defining the intended audience for your prototype, allows you to create the smallest possible type that will generate meaningful feedback
• Focus on the core workflows that let you test the biggest risks in your hypothesis

Types of Prototype

Chapter 13. Bringing it all together?

• If you’re testing something new, you want to get a commitment from customers.
• Not just nice words
• We look for 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? socialise it? take it to their boss? Will they introduce you to others?
• Money: Would they purchase?
• Be guided by outcomes, propelled by evidence-based decision making and kept on track with short cycles
• Autonomous team + outcome-based mandate

Part 3. Bringing it all together

Chapter 14. Collaborative Design

• Ultimately, the user experience comes from all of the decisions your team make about your product or service
• The product is created by the team, so the design should be collaborative
• Bring your team together in co-creation
• Collaboration based design yields better results than hero based design
• It gives designers more ideas (as they ideate and refine)
• It increases the sense of ownership the team has
• It increases shared understanding
• Collaborative design allows the team to design together
• A collaborative design session:
• Sketch together
• Critique work as it emerges
• Converge on a solution they feel has the best chance of success
• Designer will facilitate (and participate)
• Outputs from the session:
• Low-fidelity sketches and wireframes
• Low-fidelity means everyone can contribute and maintains malleability of the work
• Conversation is the primary mean of communication among team members
• have them early and often, the team is aware of everyone’s ideas and can get started on their own work earlier
• Find ways to have more
• Design Sprints:
• Lean UX is a cookbook → 5 day design sprints are a single recipe
• Design sprints are great if you want to build something new or shake things up
• They’re great for building momentum and alignment
• Good for starting a new project
• Don’t go into a spring thinking what can we build? Think about how to solve the problem
• Use your hypothesis as an input to your design sprint
• Design Systems:
• A single source of truth for the presentation layer of a product
• Don’t skip past the ‘fat marker’ stage of sketching things out
• High-fidelity designs sparks feedback on details.
• With a sketch there are no details to comment on
• Instead, people respond to the concept
• Collaboration with distributed teams
• Level the playing field → go all remote, or all in person
• Create social connections → take a little time at the beginning to get to know each other
• Create a team working agreement:
• An overview of the process that you’re using
• Ceremonies and rituals
• Communication tools
• What sort of culture do we want? What will we do when there’s conflict?
• Working hours: who works where? When are folks in the office?
• Requirements and design: How do we handle requirements definition, story writing and prioritisation?
• Work in progress limits?
• How are you going to deploy/release?

Chapter 15. Feedback and Research

• Research with users is at the heart of UX design
• Lean UX implies that research should be both continuous and collaborative
• Make it bite-sized and do it every week
• Distribute research activities across the team → reduces handoff between researchers and team members, increases quality of learnings, saves time (on deliverables)
• Create a rich shared understanding across the team
• Collaborative discovery: work as a team to test ideas in the market
• Gets the team out of the building
• Meet with and learn from customers and users
• Include a researcher on your team if you can
• Steps of collaborative discovery
• Review questions, assumptions, hypothesis and MVPs. Decide what you need to learn
• Decide on your research method - decide who to speak to / observe
• Create an interview guide to guide conversations
• Interview in pairs, one takes notes, one interviews
• Begin with questions, conversations and observations
• Hold demos of prototypes until the end of the session
• Give the note taker a chance to ask questions
• Ask for future interview referrals at the end of the session
• How to sequence an interview:
1. Find out if they are your target audience
2. Confirm they have the problem / need you seek to serve
3. Show concepts / prototypes at the end
• Don’t let scrum disrupt your research. Try and deliver value every sprint, but research is never done and should be an ongoing process
• Research should inform the decisions the product team is making
• Schedule customer interviews every week → it takes the pressure of decision making, reduces the time to validation.
• Research should be continuous, share your work, deliver value each week, be honest about what you know and what you don’t
• Research Week:
• Monday: Agree a plan and recruit
• Tuesday: Write the script / prototype
• Wednesday: finalise recruiting / prototype
• Thursday: run the tests / debrief findings
• Friday: plan next steps
• Making sense of research as a team:
• Ask everyone to read their findings to one another
• Write individual ideas on post-its
• Sort into themes
• The process of reading, grouping and discussing gets everyone inputting
• Look for patterns, place outliers in a parking lot, verify with other sources
• Test what you’ve got → test whatever is ready on testing day

	What you can learn
Sketches	Vale of concept, conversation prompts.
Static Wireframes	Information Hierarchy and layout. Taxonomy, navigation and IA
Clickable mock-ups	Simulate workflow, observe interactions,
Coded prototypes	Real simulation, test with real data, integrate with other systems.

• Think about the best way to gather the data you need:

Chapter 16. Integrating Lean UX and Agile

• 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
• Scrum has been around longer than agile, originally it didn’t think about design (references were added in Nov 2020)
• Deliver value at the end of short cycles
• Hold a daily planning meeting
• Hold a retrospective after every cycle. What’s been working well? What hasn’t been working well? What are we going to change going forwards?
• 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 handoffs. 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.

• Each team needs a dedicated designer
• Include design and discovery work on the backlog
• Encourage cross-functional participation in learning activities
• 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 product goals. A multi-sprint theme that guides the work you’ll do. Your measure of success for there should be outcomes.
• Prioritise and visualise discovery work (against delivery work)
• Include experiment stories
• Hypothesis + tactics + who + level of effort
• Bring findings back to the team
• Stakeholders and Risk Dashboard
• Communicate proactively to your stakeholders
• Make sure they know your plans and progress
• Nicole Rufuku’s risks dashboard:

Major outstanding risks	Current Assessment	Plans
Users might not value our service enough to pay for it	Trending positive	Price testing underway
Users may need service only occasionally	Not enough data	Longitudinal study in progress
Users maybe confused by branding	TBD	To be evaluated

• Outcome-Based Roadmaps:
• Strategic theme: product strategy direction
• Quarterly OKR goals: KRs should be customer behaviour metrics, definition of done
• Feature/product hypotheses: best guesses about what will help
• Have checkins quarterly.
• Measure progress by changes in customer behaviour

• On SaFe:
• designed for product not discovery
• optimises for flow of output and minimising changes to requirements
• rigid not agile
• missing key concepts: continuous learning, customer centricity, humility, cross-functional collaboration, evidence-based decision making, experimentation, design and course correction to name a few
• optimises for compliance, predictability, conformity and compliance

• Across teams make sure that everyone has the definition of the success metric

Part 4. Lean UX in Your Organisation

Chapter 17. Making Organisational Shifts

• 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 Organisation
• 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 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)
• It is not an abdication of vision to admit that faces with complexity and uncertainty you can’t predict the shape of the most successful product
• Designers:
• Open up the process to others
• Get better at facilitating team activities
• Take a leadership tole

Chapter 18. Lean UX in an Agency

• Get out of the deliverables business
• Can’t be measures of success, or what determines if you’re paid
• Collaborate to find a solution to a customer problem
• Have a fixed rate for the team not the individuals
• Every touchpoint is an opportunity to set expectations about how working with you is different
• Compound expectations with public writing, blogs, publications and on social media
• Be clear about how you’ll work together
• Nobody wants to buy experiments. Lead your sales pitch with outcomes not experimentation. Lead our sales pitch with the outcome, proved to be a far more successful way of working
• Move away from fixed scope → toward outcome-based contracts, or value-based pricing