• Project Management Approach: Business owners decided what to build. Discovery happened infrequently (with the yearly planning cycle.) Projects with fixed timelines were assigned to engineering teams. Project managers managed the work, budget and schedule
• Challenges: Software development is unpredictable. Often over time and over budget. Needs of the business trumped needs of the customer. Teams learn late that customers don’t like their product. Lots of waste.
• Agile and UX Approach: Projects were too big and teams were building the wrong stuff. Agile advocated for shorter cycles, sustainable pace, maximum flexibility, simplicity. Rise in the adoption of Scrum and Kanban. Growth of user-experience design and user research → to collect customer feedback
• Benefits: Shorter development cycles, Better product metrics. Better at usability. Better at iteration and starting small.
• Challenges:Leaders didn’t want to give up discovery. Stakeholders cling to their ideas still. Teams are bad at estimating. Typically the whole organisation didn’t become agile - stuck in old cycles. Teams weren’t allowed to fail - had to deliver on time and on budget even if they know their thing wasn’t valuable. Usability testing done late, user research outsourced, teams measured by what they delivered not value created.
• Still too much time was wasted. Teams learned after shipping code they’d built the wrong stuff. Instrumentation showed us that our new stuff didn’t work
• The future: Product teams adopting continuous discovery habits. Engaging with customers to understand their wants and needs. Co-creating products with them. Teams bridge the gap between what’s possible to build and what customers need.

Starting with the business need means everything is in service of the business. Filtering by customer opportunities ensures everything is in service of the customer.

Stops the team settling on the first or most obvious solution. Helps the team generate more options (How else might we solve this problem?). Opinion battles don’t encourage collaboration, the tree does. Builds a shared understanding of the options.

Helps break down a project (outcome or opportunity) into smaller chunks. Teams can focus on solving one thing at a time. Which helps deliver value every sprint

• Stops you bouncing from tactic to tactic, you can take a more strategic approach to selection

• Inspires a compare and contrast mindset - not a whether or not mindset. Which of these customer needs is more important for us to address right now? What else could we build?How else might we address this opportunity?
• Good discovery only reduces the chance of failure - be prepared to be wrong - balance having confidence with doubting what you know.
• Visualises the decision making process

Helps us know if we’ve gone wide enough, if we are doing enough assumption testing, if we have enough solutions mapped.

Helps justify decisions to leadership. Show your work. Shares the right amount of detail with leadership.

• Might be OK for a junior team
• Might be OK for mature products with proven traction metrics (previously done discovery)

• Specific, measurable, achievable, relevant and time-bound goals
• Teams that set specific, challenging goals outperform those that don’t
• They create focus, inspire effort and persistence and help surface relevant organisational knowledge
• Caveats
• They have to believe they can achieve it
• They need to be committed to the goal
• Teams need to be involved in their own outcomes
• If the team doesn’t have the strategies for how to achieve them, they can be demotivating
• Internal learning goals are more effective than performance goals
• Getting teams to do their best, was more effective than setting specific goals
• Unless you can give them the strategies they need
• Start with a learning goal - discover opportunities and drive engagement
• Then task with a performance goal
• E.g → Learn what leads to churn → Start to tackle it
• OKRs are one way of managing based on outcomes

• Map out your own perspective first
• Explore everyone else’s perspective - together you’ll have a richer understanding
• Merge them into a shared experience map
• Make explicit what you know, what you don’t, what your hunches are
• Note where you have open questions for customer interviews

• The map will guide your customer interviews
• Help you structure the opportunity space

• Start with the desired outcome - focus on a question
• E.g: what’s preventing our customers from completing their application today?
• The outcome constrains what you capture
• Think about how broad or narrow to go
• If focused on optimisation - narrow is OK
• If focused on open-ended outcome - expand the scope
• E.g for Netflix: increase hours watched - set broad scope
• Not as broad as ‘entertainment in general’
• But as broad as through satellite, twitch, YouTube and competitors
• Constrain scope, but not too much

• People struggle to answer direct factual questions accurately
• People give answers that align to their identity not behaviour
• We have a tendency to rationalise our behaviour - your brain summons a compelling reason and it feels like the truth
• Be wary of a coherent story, told by both the thought leaders in our space and by our customers themselves

• Speak to customers occasionally, you’ll have to ask them about everything. Speak to them weekly, you can ask about what you need to learn about in that moment. I call this concept just in time learning and it’s great - I do it with books
• Balance each interview…
• Broad exploration into needs, pain points and desires
• Diving deep on the specific opportunities that are most relevant to you
• Don’t explore anything that isn’t valuable to your customer!
• Primary Research Question: What needs, pain points and desires matter most to this customer?
• Memories about recent instances are more reliable than our generalisations about our own behaviour or our answers to direct questions.
• Tell me about the last time you did x. Asking about a specific instance better reflects actual behaviour, not perceived behaviour
• Think about how broad your question should be. Do you care about your product or also your competitors? Or tangential products and experiences
• Narrow is good for optimising your product. Broad is good for new opportunities.

• If you ask a short question, people will give short answers. They’ll match you.
• Use Temporal prompts - Start at the beginning, What happened first?
• Where were you? What happened next? What happened before that? Who was with you? What problems did you face? How did you overcome that challenge?
• Bring them back to this instance, instead of letting them generalise. In this specific example, did you face that challenge?

• Let the participant talk about what they care about most
• Don’t force it. The stakes are low. It’s OK if you don’t get what you need. Especially if you’re interviewing regularly

• Interviewer Snapshots turn detailed notes into insights. A one page synthesis of what you learnt in each interview
• Interview Snapshot
• Name
• Photo
• Quick facts - Customer Segment etc
• Insights - weaker signal opportunities, turn into opportunities over time
• Opportunities - need, pain point or desire
• Memorable quotes

• Experience map will help guide each interview
• Is their story the same or different to your experience map?
• Draw the underlying structure of the stories that you hear - the nodes and the links

• Helps explore an ever-evolving opportunity space
• Needs change
• Markets change - competitors, products
• A digital product is never done - the opportunities space is never finite or complete
• Just because you chose a target opportunity to build, doesn’t mean that you can stop interviewing
• As it assumes you chose the right one - and you’ll be able to address it
• Interviewing is not a step in a linear process - instead our goal is to interview continuously
• Enables you to revisit the opportunity solution tree
• It’s mush easier to maintain a habit than to start and stop it

• The goal is to wake up with a weekly interview scheduled without you having to do anything
• The goal is to make it easier to interview, than to not, by the use of automation

Recruit participants while they are using your product or service

• Do you have 20 minutes to talk with us for £20?
• Or ads to drive traffic to a landing page

Ask your customer-facing colleagues to recruit

• Agree triggers
• Customer calls to cancel
• Customer has a question about feature x
• Customer requests a customisation schedule an interview

Interview your customer advisory board

• If hard to reach, or you have a small market, or their time is too valuable…
• Setup a customer advisory board
• Use them as participants
• Offer an ongoing incentive
• Scale it to suit the the number of interviews you need

• Get all the trio to do it - don’t have a single person be the voice of the customer
• You’ll each hear different things - different perspective

• Relying on one person to recruit interview participants
• Asking who, what, why, how and when questions. Use story based instead
• Interviewing only when you think you need it
• Sharing what you learned by sending out pages of notes or a recording - use snapshots instead
• Stopping to synthesise a set of interviews - just keep interviewing at a sustainable cadence

• Listening to users will help you list countless needs, pain point and desires
• Looks for gaps between expectations and how the world works
• How do you know which ones to action? Take inventory of the opportunity space
• helps you find the best path to the desired outcome
• Gives you structure to evaluate things
• Most product teams bounce from one opportunity to the next. Our job is not to address every opportunity
• It’s to find and address those that drive the desired outcome
• This is how we create value for for customer
• Focusing and limiting work to opportunities that might drive our desired outcome is what ensures that our products are viable
• The Aim is to address the customer opportunities that will have the biggest impact on our outcome first
• Start by taking an inventory of the possibilities - explore options
• Compare and contrast impact of addressing one opportunity against the impact of addressing another
• Rephrase opportunities that aren’t specific enough
• Group similar opportunities together
• Requires critical thinking - help to ensure that we are always addressing the most impactful opportunity.

• We might ask … what are some other reasons why customers say “I can’t find anything to watch”
• Parent Problem - I can’t find anything to watch
• Child problem - I’m out of episodes of my favourite shows
• Child problem - the show I was watching was no longer available
• Child problem - I can’t figure out how to search for a specific show

• The idea of distinctness is key - each opportunity has to be unique and self contained
‣
Your experience map can help you
• What customers do to address their needs today helps inform user research and helps give structure to the opportunity space
1. Your user research can help you
• You can analyse by distinct moments in time
• Or identify key moments from research
• Map frequently occurring nodes to your top-level opportunity space
• The key is to make sure there’s no overlap between the moments in time - overlap prevents you from working on one at a time
• Streaming moments example:
• Deciding to watch something
• Choosing something to watch
• Watching something
• The end of the watching experience

• Review interview snapshots for opportunities to add
• Frame opportunities as a customer need or pain-point (not a solution)
• Make sure it’s common across customers - not unique to the one you spoke to
• It must feasibly affect the outcome if you address it
• If it feels like it can live under one or more branches...reframe it to be more specific OR split it into multiple distinct opportunities
• Example: “the interface is hard to use” ❌  This is too vague!
• I can’t figure out how to find a show I have in mind ✅
• I don’t like typing out the show name ✅

• Group similar opportunities together - and nest them under a new parent opportunity (don’t fret if your parent label wasn’t mentioned in an interview)

• Or combine them into one - if they are actually the same thing
• As you group siblings together, you end up with mini trees.

• Opportunity mapping looks deceptively simple - but it requires critical thinking
• Examine each opportunity to check its framed well, it’s clear, and can move the desired outcome
• Expect to spend more than 30 minutes, but don’t spend more than a day
• Get enough structure to the picture - but not so much that you’re overwhelmed by detail
• Structure is done, undone and redone.
• revise your tree often
• reframe opportunities as you learn more
• do just enough to capture what you already know - trust that it will continue to grow and evolve overtime

• BAD: framing opportunities from your companies perspective (frame as the customer instead)
• BAD: vertical opportunities = a parent with one child, who has one child in a single stack - collapse or add siblings
• BAD: opportunities have multiple parent opportunities - if top level opportunities represent distinct moments in time - then no opportunity should have two parents
• BAD: opportunities are not specific
• BAD: opportunities are solutions in disguise - distinguish an opportunity, by asking is there more than one way to solve this problem? if not → it’s an opportunity
• BAD: capturing feelings as opportunities - look for the cause of the feeling

Deconstruct large opportunities into smaller solvable ones. Adopt an agile mindset. Work iteratively and deliver value over time. Limit work in progress and explore multiple solutions.

Focus on assessing opportunities at the top level (or highest level possible) saves time comparing everything. Compare and contrast each set of parent opportunities against each other. Once you’ve picked the highest impact opportunity, you can ignore the others. Move down the levels until you have an opportunity with no children (A leaf node).

• Don’t quantify everything (1-5 etc). That’s treating an ill-structured problem as if it were well structured - and will lead you to believe there’s one right answer. There isn’t.
• Balance having confidence in what you do - and leaving room for doubt in case you are wrong
• Make data-informed, subjective comparison for each set of features

• Balance data-informed vs analysis paralysis. You learn more from doing and observing that from thinking your way to perfect decisions

• Jeff Bezos on reversibility. Level 1: Hard to Reverse: Be cautious. Level 2: Easy to Reverse: Move fast, try and learn.
• Also known as one-way door or two-way door decisions
• Prioritising an opportunity is reversible. You’re making a commitment of the next few days or weeks. You’re not committing to addressing that opportunity.
• Discovery decisions are reversible decisions. Thinking of them as such frees us from confirmation bias.

• Delaying decisions until there is more data
• Over-relying on one set of factors as the cost of others
• Working backwards from your expected conclusion

• Once you know your opportunity (pain point, need or desire) where do you start?

• Innovate where there’s a strategic opportunity (generate several ideas to ensure you uncover the best ones) don’t reinvent the forgotten password flow

Putting it all into practice

• Review your target opportunity - context - make it distinct
• Generate ideas alone
• Share ideas across your team
• Repeat steps 2 and 3 until you have 15-20 ideas for the target opportunity

1. Remove ideas that don’t solve the target opportunity (this happens!)
2. Dot-vote as a team to get down to three ideas (how well does the idea address the target opportunity?)
• Everyone gets 3 votes - Can spend them how they like
• Do multiple rounds if needed:
• Remove the winner
• Get people to go again
• Go until you have 3 left

• Not including diverse perspectives
• Generating too many variations of the same idea
• Limiting ideation to one session
• Selecting ideas that don’t address the target opportunity

• Confirmation Bias: Seeking out evidence that confirms our beliefs
• Confirmation bias escalates with investment. The more we invest, the more committed we become

• explore why your ideas won’t work
• working with a set of ideas!

• There isn’t enough time to A/B test or prototype everything
• INSPIRED - the best product teams complete a dozen or more discovery iterations per week
• This is only possible if you test ASSUMPTIONs - NOT ideas
• Assumption testing is quicker than idea testing -
• pace helps us with ‘escalation of commitment bias

• Start by assuming the solution already exists (and that you’re mapping out what end-users will do to get their value from the solution)
• Identify the key actors - who needs to interact with who for it to work?
• Map out the steps each actor has to take for anyone can get value from the solution
• Sequence the steps horizontally over time (if steps are optional list them as such)
• Put actors on rows

• Every time you assume that an end-user will do something, you are making assumptions of different types (desirable, viable, usable, feasible, ethical) - you may have a few for each
• Example - Our subscriber comes to our platform to watch sports
• Desirability: Our subscriber wants to watch sports.
• Desirability: Our subscriber wants to watch sports on our platform.
• Usability: Our subscriber knows they can watch sports on our platform.
• Usability: Our subscriber thinks of our platform when it’s time to watch sports.
• Feasibility: Our platform is available when our subscriber wants to watch sports.

• Imagine its six months into the future, you launched, and it failed. What went wrong?
• Phrase question as if the outcome is certain.

• Data, addiction, accessibility, inequality, privacy, trolls, user-user harm, brand, customer expectations, opportunity cost
• Front Page Test

• Use a 2x2
• How much do we know? (about this assumption)
• How important? (is this assumption)
• Test Leap of faith assumptions
• Make the mapping relative to other assumptions
• do we have stronger or weaker evidence?
• more or less important than x assumption?

• Not generating enough assumptions
• Phrasing assumptions such that you need them to be false (positive framing is easier to test. Customers will remember their passwords)
• Not being specific enough
• Favouring one category at the cost of others

Our goal is to collect more evidence on the assumption:

• Collect data about what people do in context (not what they think or say they do)
• Simulating an experience is a strong test - we hope the participant will behave as in the situation we emulate
• Choose the moment to simulate carefully
• Account for shortcomings of the simulation when evaluating results
• Set specific with your evaluation criteria (or hurdle rates in advance)
• If our assumption is true, what would we expect the participant to do?
• Log how many do, and how many don’t
• helps you align as a team
• helps you guard against confirmation bias
• You can’t prove it works - the burden of truth is too high. If your assumption holds true - you’ve reduced risk though.
• Key outcome is to agree as a team on the smallest assumption test you can design that still gets you results that the team feel comfortable acting on

• We don’t want to invest time, energy and effort into an experiment if we don’t have an early signal we’re on the right track
• Rather than starting with a large scale experiment or A/B test - you’ll be surprised how much you can learn from getting feedback from a few customers
• Each round of testing helps you inform what’s the next most important assumption to test
• You stop testing when you feel comfortable

False negatives

• you want a representative sample - the smaller the sample, the more chance you’ll get a false signal by selecting one type of person too much
• false negatives shouldn’t matter, if your testing your assumption in a few ways
• use a mix of research methods to better understand the assumption your testing
• False negatives are often not that bad, there are always more ideas and we can always try again

False Positives

• Either move to test another assumption OR move to a bigger experiment

You need to get better at quickly executing assumption tests

Tools to help:

• See UX for Lean Startups - for a longer list of methods

• Instrument what you need to evaluate your assumption tests
• Define evaluation criteria for each assumption - measure it
‣
Specific Advice:
• Count #people who do an action (not #actions) if one person doing many actions isn’t as valuable as many people doing actions
• On search results - measure the position in results - measure the ratio of views to conversions

• Measure what you need to evaluate progress toward your desired outcome
• If your product doesn’t go across the whole user journey - you might not know the end outcome you’re trying to influence
• incentivise people to tell you what happened - survey them
• JUST BECAUSE SOMETHING DOESN’T HAPPEN ON YOUR PLATFORM, DOESN’T MEAN YOU SHOULDN’T MEASURE IT
• Don’t be afraid to measure hard things

• You don’t want to wait to have the final answer before iterating - find leading measures
• Run a small test on one day - see if you move your metric that day - for those that engage

• Getting stuck trying to measure everything
• Hyper-focusing on your assumption tests and forgetting to walk the lines of your opportunity solution tree
• Forgetting to test the connection between your product outcome and your business outcome

• Sometimes you’ve got a need that can be solved, but nows not a good time, so you can push it back on the roadmap
• Balance short with longterm - low hanging fruit, with harder long term problems
• You can use your discovery work and quick win tests - to make the case to go after harder solutions

• Overcommitting to an opportunity
• Avoiding hard opportunities - don’t confuse quick testing and iterative delivery with avoiding hard solutions - the longer we spend building - the more we should de-risk
• Drawing conclusions from shallow learnings
• Giving up before small changes have time to add up

• stakeholders have thoughts on solutions, not grounded in discovery
• the hippo is going to win

• Don’t start with conclusions
• Show your opportunity solution tree
• Start at the top
• Remind stakeholders what the desired outcome it
• Highlight the top-level opportunities (you can invite them to add more opportunities)
• Share how you assessed the priority of the space
• Share the context about your target opportunity - customer pain point
• use the snapshots to back that up
• Share the solutions you generated
• Share the set of 3 solutions you plan to move forward with (ask them if they’d have chosen different)
• Share the assumptions and how you prioritised them
• Share assumption tests - and data - repeat

• Telling instead of showing
• Overwhelming stakeholders with all the messy details
• Arguing with stakeholders about why their ideas won’t work
• Trying to win the ideological battle instead of focusing on the decision at hand

• Focusing on why a strategy won’t work - instead of focusing on what is within your control
• Being the annoying champion for the right way of working
• Waiting for permission instead of starting with what is within your control