Passionate Product Leadership

Using Agile, Design, and Lean Thinking to Create and

Continuously Improve Products that People Will Love

Mar 2019 Edition

Photo courtesy of Boltmade, Waterloo, Ontario, Canada

Workshop Instructor:

Jeff Patton
[email protected]
twitter: @jeffpatton

Download this handout, quick reference guides, and other course material
at: http://jpattonassociates.com/handouts
Table of Contents
About this workshop ......................................................................................................................3

Product Thinking and Process .......................................................................... 6

1. Focus On Outcome and Impact .................................................................................................6
2. Understand the Whole Product Lifecycle .................................................................................7
3. Continuously Evaluate and Improve Your Whole Product Development Process .................12
4. Organize Product Teams around Product, Product Areas, and Product Missions .................16
5. Map & Evaluate Your Product Team .......................................................................................20
6. Product Teams Must Collaborate Effectively ..........................................................................25
7. Use Stories and Story Driven Development Throughout the Product Lifecycle ....................29
vUser Stories Quick Reference ..................................................................................................33
Sense and Focus ............................................................................................. 35
8. Use Data & Customer Interaction to Find Opportunities .......................................................35
9. Use Vision, Strategy, & Product Metrics to Focus Prioritization ............................................38
Form a Hypothesis .......................................................................................... 42
10. Frame Product Improvement Opportunities ........................................................................42
11. Organize What You Understand About Customers and Users Today ..................................46
vSketching Personas Quick Reference ......................................................................................49
12. Map User Experience.............................................................................................................51
vStory Mapping Quick Reference ..............................................................................................55
13. Focus and Ideate to Consider Many Possible Solutions .......................................................58
vDesign Sketching Quick Reference ..........................................................................................61
14. Map and Envision Solutions with a Story Map......................................................................63
15. Identify Small Successful Product Releases ..........................................................................65

Respond with a Test ....................................................................................... 67

16. Identify & Design Tests ..........................................................................................................67
vPaper Prototyping and User Testing Quick Reference ............................................................77
17. Use a Lean Canvas to Distill Hypotheses and Identify Your Next Test .................................79
18. Interview and Test to Gain Empathy and Insight ..................................................................80
vUser Interview & Observation Quick Reference .....................................................................85
vConstable’s Tips for Customer Development Interviews ........................................................87
19. Keep Learning from Each Test Visible ...................................................................................89
20. Release to Learn Before You Release to Earn .......................................................................92

Respond at Scale ............................................................................................ 94

21. Create a Development Strategy to Minimize Development Risks........................................94
22. Plan and Workshop Stories Ahead of Development (AKA backlog refinement) ..................95
23. Support the Team Through the Sprint ............................................................................... 100
24. Evaluate Your Product’s Release Readiness....................................................................... 102
Balance Continuous Discovery and Development ........................................ 103
25. Continuous Discovery and Delivery in Parallel Tracks ....................................................... 103
26. Plan Discovery AND Delivery .............................................................................................. 111
27. Standup to review and plan every day ............................................................................... 114
28. Review Sprints with the product team............................................................................... 116
29. Review product team progress with the organization and stakeholders ......................... 119

About this workshop 1

 Agile, Scrum, and What You Really Need to Know About Process ............... 122
Effective Process Uses Simple Values & Principles ...................................................................122
Scrum’s Simple Agile Process Framework.................................................................................124
Reading List ................................................................................................................................132
vAgile Product Development Lifecycle Quick Reference ........................................................133

Warning, this document may include typos and grammatical errors. My apologies for that. It’s a constant work in
progress with changes made monthly. Please let me know about any suggestions you have for corrections or
improvements at: [email protected] You can always find a most current version at:
http://jpattonassociates.com/handouts

About your instructor

Jeff Patton, author of User Story Mapping
Jeff Patton helps companies adopt a way of working that’s focused on
building great products, not just building stuff faster. Jeff blends a mixture of
Agile thinking, Lean and Lean Startup Thinking, and UX Design and Design
Thinking to end up with a holistic product-centric way of working. Jeff has
worked in software development for over 20 years in a variety of roles
include product manager, engineer, project manager, coach, and consultant.
Find out more about Jeff here: www.jpattonassociates.com
See what he as to say on Twitter @jeffpatton

2 About this workshop

About this workshop
Passionate Product Leadership is a workshop focused on the concepts and practices that help
teams create successful products. Even if you don’t think what you make is really a “product” –
because you don’t package and sell it commercially, my hope is that you come to see it as a
product. And, once you do that you’ll begin to see that applying product thinking helps you and
your team create something you’re truly proud of, something that really makes an impact on the
people who use it.
This workshop qualifies as a Certified Scrum Product Ownership course. But, what’s important
to know is that this isn’t just a course about filling the product ownership role in Scrum. It’s a
course that teaches the practices you and your team needs to create successful products.
That’s a mouthful of jargon and hype. But the impact we're focused on bringing about is:

You apply new thinking and practices to the things you

make and those things are more successful than ever
before.
That’s a lot.

This workshop is for the whole product team

Too often organizations adopting agile approaches and Scrum are lead to believe a single person
in a product owner role is responsible making all the decisions about the product down to the last
detail. The result is a stressed overworked product owner that’s become a bottleneck for
everyone else in the organization. Others with critical input and valuable skills are often shut out
of the process. In the end the product being built gets worse, and people in the company are less
happy than ever before.
But that’s not the way agile development is supposed to work. This class is about an approach to
agile product ownership that does.

While a Single Product Owner may lead, product

ownership and product success is a whole team
responsibility
This workshop is for:
You’ll be practicing a team-based approach to product ownership where a product owner leads a
small focused product discovery team and together they collaborate with delivery team
members, customers, users, and business stakeholders.
§ Product managers, business stakeholders, and product marketing
professionals: to understand the practices that lead to valuable products
§ User experience practitioners, and business analysts: to understand the
practices that lead to usable and desirable products
§ Senior engineers: to understand the practices that lead to feasible products
§ Project managers, Scrum Masters, and agile coaches: to understand how to
guide successful product discovery and delivery

Workshop learning objectives

Ultimately the impact I’d like to have weeks and months after you’ve attended this course is that:

You and your team work together with your company to

create more successful products

About this workshop 3

 While this course covers the details you’ll need to fulfill or support the Scrum Product Owner
role, we believe that understanding the role and its requirements isn’t enough to be successful.
In this course you’ll engage in a process simulation that models a different way of working; a way
that emphasizes working collaboratively with others using a user-centric product design
approach. At the end of this course you’ll be able to:

• Envision and describe the day-to-day work practice of a

Product Owner and a Product Team
• Draw from a variety of effective product design principles
and practices to support product discovery and delivery
• Gain enough hands-on experience with product ownership
practices that you feel comfortable trying them in your
workplace

Workshop Instruction
Workshop instruction will be a mixture of discussion and hands-on exercise.

The class is fast-paced and interactive. Wherever possible you’ll be engaging in practice with
others. If you didn’t come with other members of your team at work, I promise that you’ll wish
you had.

There are no slides, well not many…

I’ll use slides primarily to show pictures and examples, and sometimes figures that are difficult to
draw by hand. Throughout the class I’ll use words and pictures to explain key points. What you’ll
see is my hand projected as I talk and draw through key points.
It looks like this:

4 About this workshop

One of the key points in the workshop is that communicating is much more effective with words
and pictures. And, that if you draw pictures yourself, it’ll help you remember, and others
listening to you remember.

Take notes, and draw along

Use the open space in this workbook to write and draw
along.
Yes, I’ll share all the drawings I make during the
workshop. I’ll post them on the wall as the workshop
proceeds, and then share them back to you in a Dropbox
folder. For public workshops, you can find them at:
http://jpattonassociates.com/handouts For workshops
inside a company, I’ll email a direct link to your photos after the workshop.

Pay attention to your takeaways

A good friend of mine says that teaching is like “pushing
string” – which sounds impossible except that learners
can pull the string put before them. You can pull on
interesting strings by listening, and asking questions.
Make note of your takeaways – the ideas you find useful
or valuable. Some call these light bulb moments
because it feels light a light bulb turning on when you
hear an idea that you can really use, or a concept that
resonates with you.

Write down your takeaways to share

You’ll share them by posting them on sticky notes, or during a 1-word share out that we often
end the day with.

You’ll be working collaboratively in small teams

One of our first activities will be to form small balanced product ownership teams.

This handout is a work in progress, and always will be

Please forgive typos and grammatical errors. Often, content is added at the last minute to tailor
this handout for your group, or to incorporate new ideas.
I’d love your comments and feedback on its usefulness.
You can download the most recent version of this guide, and any handouts used in this workshop
at: http://jpattonassociates.com/handouts

About this workshop 5

 Product Thinking and Process
1. Focus On Outcome and Impact
Effective product development is focused on maximizing outcome
and impact
The curious thing about product development is that if you focus too much on the product, you’ll
fail. In fact, your goal isn’t to get the perfect product built, as a product management and design
professional, your goal is to change the world.
Here’s how:

Q: How does your organization measure output?

Q: How does your organization measure product outcomes & impact?

Q: Which does your organization pay more attention to measuring and

improving: output, or outcome and impact?

6 Product Thinking & Process

2. Understand the Whole Product Lifecycle
A complete product development cycle begins and ends with your
product. It balances time spend learning about and from your
customers with time spent building your product.
The whole product development cycle starts before, and continues long after, any single product
or feature delivery. While a project may be considered completed at delivery time, the life of a
new product or feature begins at delivery. And, if you’re with a product company that already has
a product, which most of you are, you know this cycle is continuous and overlapping.
As a product team, you’ll need to be aware of the whole process. As messy as this drawing looks,
it’s much simpler than a product development cycle really is.

Messed up MVP
Before we can talk about product development, we need to first get a couple terms strait.
The term Minimum Viable Product, MVP for short, is one of the most misused and abused
concepts in software development. During this workshop I’ll discuss 3 definitions for the term.

Minimum Viable Product is officially a messed up term.

If you use it, be clear about what you mean.

Robinson’s smallest successful release

Frank Robinson of SyncDev originally coined the term in 2001:
http://www.syncdev.com/minimum-viable-product/
Frank was encouraging product teams to identify the smallest product that could be successful in
their desired market. Frank pointed out that the way to identify what that smallest successful
release could be was to use discovery work. By that he meant understand your customers deeply,
and use iterative prototyping and testing to validate that your solution really would be viable.

Robinson coined the term and used it to describe the

need for a smallest successful release.
When Robinson coined the term he used it to describe that smallest release that maximized
return on investment for the company that made it. By now you understand that to get ROI we’ll
need to ship something that lots of people will see, use, keep using, and say good things about.

Ries’s next best test

Eric Ries redefined how we use the term today in his 2011 book The Lean Startup. He used the
term to refer to the smallest thing you could make or do to test your hypothesis. By 2011
products were commonly built and released on the web. It was much more common for a
product to release and evolve continuously. By changing the definition, Eric moved focus from big
releases to learning faster.
Eric Ries described Validated Learning, the process we use to declare our hypotheses, identify
risks and assumptions, then create tests that help us reduce risk. Eric leveraged lots of concepts
from Steve Blank and his book Four Steps to Epiphany, although Steve has more recent and
better books out today.

Product Thinking & Process 7

 We’ll talk through validated learning. Make your own notes as we do.
Eric was right that the biggest risks in product development aren’t that we can’t get software
built on time. Rather, the biggest risks are that we’re building something that really addresses a
customer need. And, that enough customers need it for it to be a viable product for your
organization. But, referring to our next best test as a “minimum viable product” only resulted in
lots of confusion for people that understood the term before, or who hadn’t read Eric’s book.

Eric Ries moved focus to the next best test – although

calling that next best test a viable product left some
people confused.

When only output matters, you’re left with bloated crappy

releases
If you didn’t know who Frank Robinson was, or hadn’t read Eric Ries’s Lean Startup and you heard
the term MVP, you might be confused about what people mean. Sometimes they mean test, and
sometimes they mean that something users really want and will use. That’s why you might
sometimes hear terms like Minimum Loveable Product, or Minimum Marketable Product.
Robinson originally meant lovable and marketable.
But, when only shipping as much as you can on time matters, that’s when we end up defining
MVP with variations of “the most we could ship on time” which we all know really means the first
crappy release.

MVP shouldn’t mean first crappy release, although often

it does.

8 Product Thinking & Process

Understand the whole product development cycle
Together we’ll discuss this whole product development process. It’s actually not a process so
much as naming the parts of product development every company does. I promise your company
does all these things. The question isn’t if they do these things, but how well they do them.
This model is built keep Gothelf and Seiden’s book Sense and Respond in mind. They describe
that for a contemporary product company to be successful, it must continuously listen to its
customers, sense, and then respond with improvements.
The 4 parts of the process are:
1. Sense and Focus
2. Form Hypotheses
3. Respond with Tests
4. Respond at Scale

1. Sense and focus

If you have a product in use by customers and users, your organization will need to be deliberate
about sensing if that product is performing as expected. You’ll need to listen for opportunities to
improve the product. You’ll need to listen for insights that could lead to whole new products, or
sunsetting mature products. You’ll do that listening by collecting data on your product’s use, and
by engaging directly in conversation with customers and users.
Use metrics and data to understand how your customers use your product today.
Use face-to-face conversation to collect subjective data to get the “why” behind the more
objective data.
All this listening will result in a pile of ideas for improvement, or problems to solve. I call that
ever-growing pile an opportunity backlog.

Product Thinking & Process 9

 Listening to customers and users isn’t the only source of ideas.
Your company’s vision should give guidance on where you’d like to be years into the future. And,
that vision should describe something your customers aren’t likely asking for today.
If vision is where you’ll be years from now, your company's strategy should give guidance on the
stepwise approach you’ll use to get there. Your strategy will say more specifically where you
intend to go next quarter, and maybe the quarter after that. Your current strategy will add
opportunities to your backlog too.
An OKR is a good way to make your current strategy visible and measurable.
Use OKRs (Objectives and Key Results) to clearly state what your current product goal is and
specifically how you’ll measure product outcomes.

OKRs, or target product outcomes, drive the

prioritization of opportunities.
Your company will likely have a roadmap that supports its strategy. Be sure that it doesn't just list
the features you’ll build and when. Make sure your company’s roadmap also describes the target
outcomes and how you’ll measure success. You may have to help your company articulate these.
Make sure your company listens and learns from your customers to see if the strategy expressed
in its roadmap is really working in the real world.

Use discovery work to identify and validate product

improvement ideas
Discovery is the work we do outside a traditional Agile delivery process like Scrum. Often Scrum
thinking alone is optimized for predictable delivery velocity.

Discovery is about Learning Velocity

Unfortunately, we don’t yet have easy ways to communicate learning velocity like we do delivery
velocity.
Discovery has two basic parts:
1. Forming strong problem and solution hypotheses
2. Focus on risk and uncertainty and use small tests to reduce that risk

2. Form hypotheses
In traditional processes, we’d seek to collect the requirements for the product or feature we’ll
build. We’d estimate time, and then create a plan to deliver it. In a discovery process we’ll still do
that, but focus our work here on:

Building shared understanding within the product

team of the problems we’re solving, the solution
we believe will solve them, and how we’ll measure
success after delivery.
Most importantly we recognize that our solution idea is a hypothesis, that product outcomes
aren’t guaranteed. We’ll need to ask ourselves:

How wrong are we willing to be?

If we’re confident that we’re right, we can proceed with development – respond at scale. If not,
we may want to engage in the second part of discovery work, testing our hypotheses.

10 Product Thinking & Process

3. Respond with a test
To test your hypotheses you’ll engage in a variety of activities like interviewing and observing
customers and prototyping and testing solutions with customers. Your development team may
aid in creating prototypes used in discovery, or even creating versions of your product to release
to small audiences. But never forget that these are tests. Their benefit comes from learning.
Don’t expect your organization to get big financial benefit until you scale the solution to be part
of the product you ship to all your customers.

4. Respond at scale
When it’s time to deliver a solution into use by all your users, you’ll need to pay extra attention to
quality and scale.

Don't build products to scale until you’re confident that

you’ll get the outcomes you expect.
Don’t over-invest in prototypes by building them at
production quality.
Delivering your solution to all your customers is your last, most expensive, bet. And this is where
the cycle restarts.
You’ll need to sense how well your solution did using metrics and face-to-face customer
engagement. Despite our best efforts in product discovery, we still release solutions that don’t
perform as well as we expect.

Product Thinking & Process 11

 3. Continuously Evaluate and Improve Your Whole
Product Development Process
Use a quick collaborative process reflection workshop to
evaluate and improve your process
Why?
To become more effective as a product organization, you’ll need to pay attention to how you’re
doing things and find small ways to continuously improve. Improvement may mean adding new
practices into your process, or turning up the volume on things you’re already doing.

When?
Evaluate your whole process routinely to reflect on how you’re doing.
When adding new team members or reorganizing, stepping back and reflecting on how you do
things will help everyone build shared understanding around how you work, your strengths and
weaknesses, and where you’d like to improve.

How?
Use a quick collaborative activity to evaluate your current process.

Who participates:
Involve your whole product team.

You’ll need:
§ A whiteboard or large flipchart paper
§ Sticky notes
§ Markers

For each of the 4 process parts:

1. Discuss
Briefly discuss what “ideal” means. Review the qualities described under the process area.
§ Are there qualities you don’t understand? Discuss them with your team members
§ Are there qualities you disagree with? If so, strike them out.
§ Are there qualities missing? If so, discuss and add them.

2. Rate
Everyone give their own subjective rating on a scale of one to five, where 5 is best. You’ll
disagree with each other, which is ok. You all see things from different perspectives.
To rate fast, do it “rock-scissors-paper” style: Everyone think of their rating, then count to 3, then
hold up a hand with one to five fingers up.

3. Discuss highs and lows

For those with lower ratings, 1 or 2, ask:
§ What do we do poorly? What lowers our evaluation?
§ Discuss and note the deficiencies that could benefit from your attention.
For those with higher ratings, 3 to 5, ask:
§ What do we do well? What raises our evaluation?
§ Discuss and note the competencies that make you great.
No matter what your rating, join in on the discussion of what you do well, and how you can
improve.

12 Product Thinking & Process

4. Discuss small changes you could make to improve your ratings
Together discuss the smallest simplest changes you could make that would improve your product
development process.
Focus on small continuous changes. You and your team likely can’t change your organization and
culture all at once. But, I suspect you can find one small thing you could do to improve things
today. Do that. Then check back in a few weeks and see how it worked out. Then repeat the
whole process. The secret to big improvement is making lots and lots of small improvements.

It’s impossible to have all these qualities

For each quality I can cite an organization that has it. You might be able the think of examples
too. However, even in the organization having the quality, it’s likely inconsistent. For example one
area may have great metrics on the use of their product, while another area may have none. And,
while I can cite an organization that does have many of the qualities below, I’m sure there isn’t an
organization with all of these qualities. Finally, some of these qualities may not make sense given
the kind of product your organization creates. When self-evaluating, trust your intuition and
disregard things that don’t apply.

High ratings don’t equal product success

When evaluating your organization, don’t expect to be perfect. It’s likely impossible. And, here’s
the really bitter truth, even if you were, it wouldn’t guarantee your success. In fact, you may
already be wildly successful even though you might score yourself low on this scale. Customers
don’t care if you follow the right process. They only care if your product is awesome. Doing some
of these things make it more likely you’ll build an awesome product. Nothing replaces experience
and insight. And, sometimes just luck and timing.

Process parts and qualities:

This, likely oversimplified process, breaks product development down into four different and
broad parts. Under each part are a number of qualities. Each quality describes an ideal way of
doing things in a technology product company.

Product Thinking & Process 13

 Sense and Focus
1. Product Metrics: You have usage metrics on your product down to the feature level and
a subset of them are key performance indicators you monitor and discuss routinely with
your team.
2. Frequent Customer Contact: You and your team build domain knowledge and empathy
with your users through routine customer and user contact.
3. Reflect on What You’ve Released: You and your team reflect on both the effort and
outcome of what you release. You improve or remove under-performing product
features.
4. Monitor Technology Health: Your organization and team monitors the health of the
underlying code and technology your product is built on. It routinely identifies technical
improvements to make, or technical date to pay down.
5. Strategic Research: Your organizations does some research to understand the market
your product is in, competitors, and market trends. Your team leverages that research
when it supports your work. If growth is important, your organization searches for new
types of customers, or new problems to solve for the customers it has now.
6. Strategic Product Planning: Your organization focuses product strategy on what
customers and problems it will solve when, what technologies it might apply to solve
them, and how both customers and competitors might respond. Strategic roadmaps
describe longer term bets your organization is taking, and the expected market
outcomes it’s betting on and not just the features it hopes to ship.
7. Focus: Target metrics or OKRs look ahead 1-3 months to help product teams prioritize
their work.
8. Budgeting Time: Your org and team budgets time for strategic product improvements,
responsive improvements based on routine measurement and learning from customers,
and technical improvements.

Form Hypotheses
1. Problem Analysis: We understand who our customers and users are and the challenges
our goals our solution address. We identify different customer types by focusing on the
differences that make a difference in their needs.
2. Customer Focused Solutions: We design solutions that address specific user needs. We
design for usability aspects like learnability, memorability, and efficiency. For
functionality with visual user interface, we strive for visual design that inspires
confidence and is consistent with our brand.
3. Smallest Successful Release: instead of large solutions that take a long time to build and
deliver, we strive for small solutions narrowly focused on specific customers and needs.
We know we’ll learn from this release and follow with subsequent releases that improve
our solutions incrementally.
4. Hypothesis and Success Metrics: For a proposed solution, we declare specifically the
customer and need we’re focused on, how we expect they’ll use it to get benefit, and
how our organization might benefit as a consequence. We identify metrics that will help
measure this benefit after release.
5. Visualization and Shared Understanding: We use visualizations and prototypes to show
our solution and storytelling to help explain it. This helps build shared understanding in
and outside our team.

14 Product Thinking & Process

Respond with Tests
1. Identify Riskiest Assumptions: We expose assumptions, risks, and questions in our
solution ideas, identify the riskiest, so we can focus on the most important thing to learn
next.
2. Right-sized Tests: We identify the fastest and most effective way to test our
assumptions, or learn what we need to learn next. If we spend more time and money to
learn, we may get better data, but we also risk more money and slow testing our
solution. We focus on right-sizing the tests scaling what we spend as our evidence and
confidence increases.
3. Visible Learning: After each test we reflect on what we’ve learned, specifically what we
were wrong about and new information that changes our hypothesis. We track what
we’ve learned and use it to change our problem and solution hypotheses. What we
learn changes our assumptions, risks, and questions, which changes our next best test.
4. Defer and Kill Ideas: We routinely reflect on solutions we’re testing. If testing and
evolving our solution doesn’t increase our confidence in building at scale, we routinely
defer or kill ideas. If the cost of the solution is low, and risk to damaging our customers
or reputation is low, we may choose to release and measure, but then pull back the idea
if it doesn’t perform as we expected.
5. Variety of Learning Approaches: We have a variety of tools we can use to learn such as
ways to talk to customers frequently and remotely, various ways to prototype solutions
quickly and at different levels of fidelity. We continue to invent new ways to test as
technology and our experience progresses.
6. Technology Supports Learning: Our technology stack allows us to use testing
approaches such as split testing, feature toggles, or releasing functionality to a small
subset of customers. When appropriate, we build technology that allows us to rapidly
create live-data prototypes using our data and infrastructure. We can gather metrics on
the use of our products and tests. Data also helps us identify candidate users to test our
solution.

Respond at Scale
1. Predictable Delivery: Given a reasonable description and visualization or prototype of a
solution, our development teams can reasonably predict the time it takes to build.
Where there is uncertainty, our development teams have strategies for identifying and
addressing risk early in development. We use what we learn early to adjust our
predictions and our solution to best hit deadlines.
2. High Quality: We rarely find bugs in production. When we do, they can usually be
addressed quickly.
3. Technology Stack Supports Quality and Speed: Our technology stack supports fast
testing and release. We use automated regression testing to be reasonably confident
new functionality doesn’t break existing functionality. We continuously integrate and
deploy code. We can release unfinished functionality “dark.” We can release at a team
and feature level.
4. Small Targeted Releases: We release production code into use frequently. We can
target releases at specific groups of users. We can gently roll out big releases by region
or customer group.
5. Match Engineering Rigor to Scale: When releasing smaller “releases to learn” to a small
audience, we defer adding functionality to address unneeded scale, performance, or to
address unnecessary operational concerns. We identify this “work not done” so that if
and when it comes time to scale the functionality, we have a starting point to begin that
work.

Product Thinking & Process 15

 4. Organize Product Teams around Product, Product
Areas, and Product Missions
Product managers and owners lead balanced core product teams.
Together with whole dedicated product teams they focus on creating
successful products.

The client-vendor anti-pattern separates those with problems

from those who solve them

In this model the client is responsible for the value, and the vendor is responsible for time, cost ,
and quality. Together they must agree on scope.
§ When they client gets more “scope” at a lower price, the client wins.
§ When the vendor does less work at a higher price, the vendor wins.
§ When the vendor finishes the work, the client owns the resulting product.
You can see these two groups motivations aren’t exactly aligned. You can see the client is
responsible for value, and ultimately owns the product or result of the work.
Sadly, we often apply this model inside our own company. And, doing it breaks our working
relationship. Since neither party gains when we try to negotiate a lower price. And, when we
build technology products for ourselves, we all own the resulting product. A real outside vendor
would transfer ownership to their client upon completion of the work. But, IT doesn’t transfer
ownership to the business on completion. They still support and maintain what they’ve built.
While this idea may serve us in the outside world, it hurts us inside our organization. It even hurts
us in the outside world when both parties form an adversarial relationship.

The client-vendor anti-pattern finds its way into the

Scrum “Product Owner – Team” relationship.
But, product teams can’t work that way.

16 Product Thinking & Process

A product team brings decision makers AND executors together
on the same team
Product teams include both decision makers, and
executors. While they work with people outside their
team to understand the outcomes they’re striving to
achieve, they’re responsible for creating, and
continuously improving their product.

Good product decisions balance

value, usability, and feasibility
Valuable for our business:
§ Helps our business sustain itself
§ Furthers or businesses vision and strategy

Valuable for our customers (those who choose to buy & adopt the product):
§ For business products, has a value proposition that helps them sustain their
organization
§ For consumer products, it offers a similar value proposition, or is desirable as a luxury
or indulgence
§ Is better than competitor’s offerings or other
alternatives

Usable:
§ Users can easily try it, use it, and incorporate it into
their lives or work

Feasible:
§ We can build it given the time, tool, technology,
and team we have

A product team is composed of the people that have all

the skills they need to identify and build a valuable,
usable, and feasible product.

Product Owners lead core product teams

It’s rare that a single person has the experience and
skills necessary to make good product decisions
alone, so an effective product leader must work
closely with others. For small product teams, 5 or
less, the team may collaborate on most product
decisions. For larger teams, a smaller core product
team collaborates more frequently to make decisions
faster, and involves the whole team wherever
possible.

Product managers and product owners must act as

strong collaborative leaders.

Product Thinking & Process 17

 In traditional Agile processes like Scrum, the role of product owner is often misunderstood. The
PO is often seen as the sole decision maker about what goes in the product. This responsibility
can extend to creating the backlog and defining every item in it in detail. This simply doesn’t
work. To hold a single person or role responsible for doing all the work that leads to identifying a
successful product:
§ Creates a single point of failure around a person that can’t easily possess the skills and
experience needed to identify a best solution
§ Doesn’t match the real-world constraints where product ideas and needs come from
others in the organization
§ Doesn’t allow the team to step up and take ownership of product success

Think back to a product, feature, or capability you released successfully.

Q: Whom did you work closely with to make product decisions? Was your
relationship formalized as a core team, or informal?

Core product teams orchestrate collaboration with everyone

Core product teams must collaborate with a wide variety of people to be successful. They must:
§ Build ownership and accountability within the whole product team
§ Become successful advisors and co-creators with business stakeholders
§ Build deep understanding of empathy with customers and users
§ Look for and leverage the experience of outside experts when it’s needed

User Experience practitioners have a variety of specialties

There are lots of misconceptions about what user experience work is and what a UX professional
is. All products have user experience, event though they may not have a graphic user interface
that appears on a screen. Some of the user experience may be handled by live people. If you build
a technical API or service, the users are often developers, and the UI is the API you design for
them.
I’ll simplify UX to these three concerns: utility, usability, and aesthetics. Add your own notes to
the model as we discuss it.

Aesthetics

Usability

Utility

18 Product Thinking & Process

Map product teams to your portfolio of products
In the simplest of situations, a single digital product is supported by a dedicated, collocated
product team. Ideally the team is small, 5-10 people total. But, for a company of any size, getting
to ideal is challenging.

Identify the products in your organization’s digital portfolio

Those products may face external users and customers. Or, they may be products where
customers and users work for your company.

Ideally one team maps to one product

Many similar small products may be grouped and mapped to a single team
Larger products are often cut up into product areas
As products grow in size it takes larger teams and more teams to keep up with ongoing
development.

Large products are cut up into

product areas each lead by a core
product team.
Whole products are often lead by a head of product or chief
product owner.
In larger companies, I imagine a whole barnyard of products in a portfolio. But to keep that
barnyard of products healthy, common services to keep them fed and supported are necessary.

Identify common platform services or components and treat them as products

A platform service might be common services that provide access to data, logging, or metrics.
Other services might support continuous integration or deployment into production.

Customer experiences can be thought of as a product

For organizations that blend digital products with service offerings either on the web or in brick
and mortar stores may look at a whole experience as a product. For example, if your organization
sells cars, the whole “car buying experience” end-to-end may be thought of as a product that
crosscuts several digital products like mobile and web experiences. But, also in-store experiences
for test-driving and financing.

Identifying your products and leadership for each

product is always a challenge.
Expect lots of trade-offs when doing this. You’ll never get it perfect. As your products and teams
grow, expect change and reorganization. As your organization grows or repositions in its
marketplace, expect change and reorganization in your product teams.

Product Thinking & Process 19

 5. Map & Evaluate Your Product Team
Map your product team
Use a product team map to visualize your product team, the product they’re responsible for, and
who they must work with outside their team to succeed.

Why?
Working together as an effective team relies on everyone knowing their other team members’
skills and strengths. When a problem or question arises, a team member should go directly to the
person who can help solve the problem. This is a different way of working than a traditional
command and control organization where all problems are taken to “the boss,” a team leader or
project manager. In an effective team, all roles collaborate.

When?
Create a map when chartering a new team, or reorganizing teams.
Use a product team map to help orient a new team member.

How?
Use a quick collaborative activity to expose what you know, or don’t know, about your product
team.

Who participates:
Involve your whole product team.

You’ll need:
§ A whiteboard or large flipchart paper
§ Sticky notes
§ Markers

1. Create a product team canvas

Using a whiteboard or large sheet of flipchart paper, draw a canvas that looks like this:

2. Identify your team:

On the top, write your team’s name if you have one.
Write down the product or product area your team is responsible for, which for some
organizations is the same as the team name.
If your team is responsible for an area of a larger product, write down the name of the parent
product.

20 Product Thinking & Process

3. Identify your team members and their skills:
Each member of the team write your name on
a sticky note.
Place your sticky note somewhere in the Venn
diagram in the middle of the map.
Think about your skills and interests: Are you
more business focused? User experience
focused? Technology focused? A mixture of
some of these?
For example: If you’re an engineer or tester,
you may place your sticky note in the
technology area. If you’re a front-end
developer you might place your sticky note in
the intersection of user experience and
technology.
Let participants place their sticky notes where they feel most appropriate. You may be surprised
where people put theirs. Look for gaps in skills you’d need to have a balanced cross functional
team.

4. Identify eternal deciders, experts, and executors:

Outside leadership are the executives, heads of product management or others that provide
guidance for vision and strategy. Write names if specific people in your organization that supply
your team with high-level vision and objectives that your team must leverage in order to make
good product decisions.
Think about people or groups in your organization you must work with in order to release your
product and continue to support it. In some organizations they’re referred to as “go to market”
people. Write them on sticky notes and place them on the left side of the map.
For example: you likely must work with
sales and marketing at release time.
They’ll need to know what you’ve
released and when so they can sell it to
customers. Customer service likely needs
to be aware of what your team is releasing
before it releases so that they can support
it in the field.
If your team is responsible for an area of a
larger product, you may have other
product area teams you must coordinate
with to release. Write the names of those
teams down here too,
Outside subject matter experts help fill in knowledge gaps your team might have. You’ll likely
need to supplement your understanding of how your business works, how the market works,
regulatory or compliance rules, or deeper insights on your customers and their needs. Name the
people your team relies on outside the team for expertise.

5. Identify customers and users:

Customers are the people that choose to buy or adopt a product. Users are the people who
actually place hands on keyboards or fingers on touch screens. For some consumer products, they
may be the same. For business-to-business or internal products, they’re likely different.
For example, customers for Netflix might be the families and the head of household is the
decider, and users might include parents and children.

Product Thinking & Process 21

 For a large ERP system, we might name the kinds of companies that buy our product such as large
multinational corporations. These are our customers. But there may be a huge variety of different
types of users such as accountants, administrators, asset managers...
Name each type of customer or user and write it on a sticky. Place the sticky note on the right
side of the map. You’ll find the team members who know their business may be best at naming
customers. You’ll find team members strong at UX can name the users.

Retain and communicate your results

Photograph what you’ve done. Place it in a shared team wiki or just on the wall in your team
area. Adjust it as your team adds or removes members, or as the organization changes around
your product team.

Alternatives and other practices:

Building a team map helps team members understand their team, their product and who they’ll
work with outside the team. It’s a good team chartering activity. But there are others such as:
§ Team working agreement
§ Team mission
§ Key Performance Indicators
§ OKRs
All these help the team work together to achieve their goals.

22 Product Thinking & Process

Evaluate your product team
After you understand your team, where it fits in the larger systems of teams, and who it relies on
to make good decisions and deliver, evaluate the strength of your team.

Why?
A characteristic of contemporary product development process is continuous improvement.
Product team evaluation gives your team some criteria in order to evaluate and continuously
improve.

When?
Use product team evaluation as one of your team and process quality reflection tools. Use it
routinely at an end of development cycle retrospective. Use it when you add or remove team
members, or after reorganizing product teams.

How?
Discuss each of the qualities below as a team.
Individually assess the qualities below on a scale of 1-5 where 5 is a strong “yes” and 1 is a strong
“no.”

As team discuss your answers. If you answered a question with a 1 or 2, but,

other team members answered 4 or 5, discuss your reasons for your rating. Where
possible, try to agree on a team rating. But, it’s not agreement that’s important, it’s the
discussion that is.
After discussing your assessment, ask:

What’s the first simplest things we could change to

improve our overall score?
Together discuss the smallest simplest changes you could make that would improve the
effectiveness of your product team.
Focus on small continuous changes. You and your team likely can’t change your organization and
culture all at once. But, I suspect you can find one small thing you could do to improve things
today. Do that. Then check back in a few weeks and see how it worked out. Then repeat the
whole process. The secret to big improvement is making lots and lots of small improvements.

Product Team Qualities:

1. Balanced Team
Do you have the people on your team you need to make good business, user, and technology
decisions? Do you have the skills necessary on your team to design and create your product?
When your team doesn’t have the expertise that it needs, does it maintain relationships with
outside subject matter experts to help answer questions and help the team build its expertise?
Every team must rely on outside expertise to make good decisions and at times to perform work.
But, if your team often looks to outside experts or outsources execution to other teams or
outside organizations, it may not be well balanced.

2. Mission and Shared Understanding

Does your team understand the product, product area, or platform components it’s responsible
for? Everyone will need to understand who their customers and users are, how those users use it,
and how your organization measure success. This gets messy in larger organizations where it
takes lots of teams working together to build a whole product. Ideally each team understands
their part of the product, and how that part fits into the whole product and product portfolio.

Product Thinking & Process 23

 3. Healthy Leadership
Does your team have a strong inside leadership? A product manager, or product owner that acts
as a collaborative leader is usually critical here. This person works collaboratively with those that
best understand users and technology leveraging others’ experience and expertise to make good
decisions. Do the most capable people work together to make good decisions and strive to
include everyone? Or are decisions handed down without collaboration? Or, sometimes worse,
are decisions made democratically where the majority without experience often overrule those
with experience?
Does your team have a healthy relationship with outside leadership? If your organization is
bigger than a startup, you’ll rely on outside leadership for vision and strategy. Does that
leadership help everyone understand the bigger vision for the product and the immediate
strategic goals the organization is pursuing? Does that leadership focus teams on outcomes to
achieve and not features to build?

4. Minimized & Managed Dependencies

Can your team make changes to its product area routinely with minimal dependency on other
teams? Teams working on larger products and services must work with other teams to make sure
their decisions work for the product as a whole. Given this constraints, can your team make and
act on its own decisions? If your team is usually waiting on other people or teams for decisions or
approval, the answer may be “no.” If your team usually can’t deliver a feature without working
directly with other teams, your dependencies are high.
Does your team have strategies for managing dependencies with outside teams? While we’ll try
to structure teams to minimize dependencies, it’s pretty much impossible to eliminate them.
Does your team have strategies for routinely coordinating with teams you must work with to ship
a new feature or capability? Often a person or small group will look after these dependencies and
orchestrate coordination across dependent teams.

5. Ownership
Does your team own product success? To do this, your team must work directly with its
customers and users to learn about them and how they use the product. Can your team make
changes to the product and deliver them to those customers and users? Can your team learn
from those customers and users if those changes were used and improved their experience? Can
your team take responsibility for the outcomes, good or bad, that come as a result of the changes
it made? If the answer is “no,” “maybe,” or “sort of” to most of those questions, your team may
not be able to take ownership of its product.
In larger organizations this means coordinating with other teams responsible for other parts of
the product, and that often share the same customers and users. Although those other teams
may be responsible for other parts of your users’ journeys, you’ll need to work together with
those peer teams to own the whole product. Ideally leadership one level above the product team
helps a group of teams understand the whole product and how the parts fit together so they can
own their part.

6. Continuous Delivery & Learning

Most mature organizations have some formality around releasing changes to its products. But,
ideally that formality doesn’t slow down release much, especially when making limited small
releases or tests. Given the rules in your organization, can your team ship changes to its products
routinely and easily? If your team can’t ship without coordinating a release with other teams, or
spends lots of time waiting for approval to ship, you may have challenges here.

24 Product Thinking & Process

6. Product Teams Must Collaborate Effectively
Effective collaboration focuses on building shared understanding,
solving tough problems, and creating alignment.
The documents we create help us recall details that emerge during
effective collaboration.
As you worked together collaboratively, you may have noticed a few things you were doing that
made it more effective. Even if you didn’t, I’ll point them out.

Sharing documents, or words alone, doesn’t work

We may name the same features and agree we need them. We may agree on priority. We may
agree on who our customer is. But, we’re often imagining different things.

It’s when we discuss our ideas more using words and pictures to explain our understanding that
we can detect we have different understandings.
It’s not that any one person’s understanding was the right one. We all bring useful information to
the discussion. It’s combining and refining our respective understandings that lead to a common
shared understanding.
In the end we may still name the same features, priority, or customers, but now we actually mean
the same thing when we do.
This is the intangible state of shared understanding. The presence of a document doesn’t
indicate we have it. It’s a critical quality for effective teams.

Shared documents are not shared understanding

Build simple visualizations while collaborating
Making our ideas visible helps us confirm others understand. Then others can
add to them, build on them, and reorganize them. Together you’ll build a
shared understanding that includes everyone’s contribution.

The goal of effective collaboration is shared

understanding
The details in the models and drawings are brief. You couldn’t share them
with someone else and expect them to understand. Keep these drawings,
photograph them, or shoot short movies with participants describing them.

Photos and videos of our simple models work

like vacation photos. They help us remember.

Product Thinking & Process 25

 When you look at your own vacation photos you recall huge amounts of details that aren’t
explicit in the picture. Someone else who wasn’t there won’t.

5 Collaboration Tricks
1. Externalize your thinking in simple models
Represent ideas with simple card models and drawings. Allow everyone to participate in drawing
and modeling. Photographs and video recordings of simple models become mementos, like
vacation photos, that help us remember more details of the conversation than we could ever
record.
To avoid lots of talking with nothing to show for it:

Think-write-say-place
Our usual impulse when we think of an idea in a group is to simply say it. Don’t. Write it on a
sticky note or index card first, and then say it as you place it in the shared model you’re all
working on.

2. Say less
Let pictures, gestures, and the organization of cards do the communication. Finding common and
precise language can slow down collaborative work.
Brainstorm silently: While some people do well when brainstorming out loud, most don’t. Give
everyone quiet time to think and then write or sketch their ideas. After sharing ideas, then build
on and combine other’s ideas.

3. Intuition before analysis

You’ll be able to go faster if you don’t over think or deliberate decision. Trust your intuition,
especially as you begin collaborative work. Don’t spend time during collaboration deliberating or
discussing if you should or shouldn’t add a sticky note, or where to move a card. Just add it. Just
move it. Once you put your idea into the context of the other ideas, it’ll be easier to judge if it’s a
good addition or not. And since your investment is low, it’s quick to remove if you change your
mind.

4. Fewer People
Break large groups into smaller working groups of 4-6 people to discuss and model. Integrate and
review results as a whole group later.
For faster decision making and creating complex work products like UI prototypes, break into
pairs or triads.

5. Time-box and satisfice

Use short time-boxes of 10-25 minutes to do work. At the end of a time-box, stop and reflect. Is
your work good enough to proceed to a next step? If not, how many more time-boxes might you
need?
At the end of a time-box when you ask yourself: “Is this good enough for now?”. This is satisficing.
Design and decision-making work can go on indefinitely. What’s more you’ll find you often need
to revisit early decisions based on what you learn in later activities. Don't over-invest in early
decisions. Satisfice.
Working in small time boxes is
described in the Pomodoro Technique.
Break a larger task down into several
small time-boxes. Use small breaks
between time-boxes to recharge, check
email, get coffee, and reflect on your
progress.

26 Product Thinking & Process

Collaboration is difficult to scale
2-5 people can work together effectively given a goal, a time-box, and
effective workspace that supports creating a shared visualization.
5-12 people need everything small groups do but add facilitation, and a simple
structure to support their collaboration. Common Agile practices like planning
poker are examples of facilitation structures that help groups work together
effectively.
12 or more people will need what medium-sized groups do, and will
likely need to break into smaller groups to work and then merge
results.

Diverge before you converge

The results of collaborative work will be better when you allow time to get more ideas and
information into the room before making sense of the ideas, and converging on specific themes
or solutions. Don’t prematurely shut down the generation of ideas and information. Remember,
the middle is messy. Expect things to be chaotic just before they come into focus.

The divergent to converge flow from the book Gamestorming.

Product Thinking & Process 27

 Plan and run collaborative workshops
Involve a variety of people in short, 60-90 minute collaborative workshops. Together they can
collect and make sense of information, and use that to find answers to problems.
1. Plan workshops to include those who bring information in and those who need to
learn and build empathy. For instance, workshops that include end users should also
include development team members who need to better understand those users.
2. Facilitate workshops with an eye on participants being engaged and feeling
productive. Make sure your workshop produces a visible model that helps build shared
understanding. Photograph or video the results so you can better recall what you
learned.
3. Consolidate what you’ve learned, and share it back with participants. Photograph and
shoot short videos to quickly document. Convert photos to more formal documents as
needed.

A workshop with good wall space to record, and lots of Immediately consolidate and
effective collaboration. record information collected
during the workshop. Your
memory of what was said fades
fast.

28 Product Thinking & Process

7. Use Stories and Story Driven Development
Throughout the Product Lifecycle
Understand the user story and how to use them to discuss,
decompose, and plan delivery
The concept of a “User Story” is used to guide the delivery of your solution iteratively and
incrementally. Use a story driving process to continuously build shared understanding and
encourage problem solving within delivery teams.

Agile Stories solve 2 problems with traditional requirements

driven processes
Agile stories solve two big problems with requirements in software development.

1. Documents aren’t effective ways to communicate:

Effective story conversation builds shared
understanding.
Use conversations to build shared understanding and eventually agree on specifically what to
build.

2. Requirements aren’t the same thing as value:

Focus conversation on minimizing output,
and maximizing outcome and impact.
Focus conversations, especially early story conversations, on understanding users and the
problems we’re solving for them. Strive to come up with the most economical solutions to user
and business challenges.

Stories require changing the way you work, not the way you
document
You may use many traditional requirements specification practices such as use cases, workflow
models, UI sketches or prototypes, or even UML. But use them in support of a conversation. Use
the conversations to build shared understanding. Communicate that understanding with
subsequent conversations.

The moment documents are handed off without

conversation is the moment you’ve fallen back to a
traditional document-driven process.

Product Thinking & Process 29

 You may be making using stories harder than it needs to be
You made have been told that good stories must be written using a specific story template. Or,
that good stories must be small enough so that several of them may be built in a single sprint or
iteration. Or, that good stories should have acceptance criteria so we’re clear on exactly what to
build. But, that’s not exactly true.
Those qualities should be true before development work begins on any single story. But, ideas
don’t come to you in that form. And they’ll get into that form only after lots of discussion and
refinement. With luck, you’ll kill off many of the ideas that come in before they get to
development. But, all those ideas are still stories. No matter how large. No matter how unrefined.
No matter what format they’re written in. And, what’s more, those big vague stories are just right
for early story conversations.

You don’t need to get stories “right” the first time.

It’s story discussions with your team that improve them.
This makes stories the most forgiving of approaches to
specifying what to build.
Stories from Idea to Delivery
Many mistakenly believe that the only good stories are those that are ready for the next sprint. In
fact, guidelines for creating good stories are often misinterpreted to mean that it isn’t a good
story unless it meets all those guidelines.

Stories start as big and vague.

It’s a product owner’s responsibility to evolve, refine,
thin out, and break down stories over time.
The journey of story from idea to delivery is long. As a product owner and product team, you
steward ideas from stakeholders, customers, users, your team, and yourself through this journey.

The hardest part happens long before the stories are built
You and your team are left with the problem of taking big ideas understanding them, and
breaking them down as you move them towards development.

30 Product Thinking & Process

 Use a stories and storytelling from initial idea all the
way to development. Decompose, cut away, and refine
as you and your team work with them.
You’ll use a variety of practices as you work with stories. In this workshop we’ll discuss the
Opportunity Canvas, Story Mapping, and Story Workshops.

Early stories are about ideas or opportunities

The big ideas people bring in or that you think of yourself deserve good story conversations. I call
these early conversations Framing discussions. And, I like using an opportunity canvas to frame a
new feature idea.

Use an opportunity canvas to frame new feature or

capability ideas
Use your framing discussion to make go or no-go decisions where “go” means you’re ready to
invest time to learn more and move the story into discovery.

Break down big stories during discovery

As you explore an opportunity for product improvement the discussions you have will help break
that story down into lots of details and options. The story map is my favorite way to break big
ideas down.

Use a story map to break big ideas down while keeping

your user’s experience with your product in mind.
Use the shape of the map to understand product user and help figure out what risky assumptions
you’ll need to validate in discovery. Use the map to explore different release and development
options.

Product Thinking & Process 31

 Stories become ideal for delivery over time
These INVEST guidelines originate from Bill Wake. Remember:

Good stories don’t start with these qualities. They end

this way only after lots of effort and collaboration with
your team and the rest of your organization.
Independent: The story should be independently buildable and testable, but we know that a
single small story often can’t be released independently and be valuable to users and the
business paying for it.
Negotiable: Which is a bad word for the notion that good story conversations often change what
we thought we’d build, coming into the conversation in favor of minimizing output while
maximizing outcome and impact.
Valuable: Every story when turned into working software has value. But each small story’s value
comes from the learning we get as a delivery team. The really important value comes from the
delivery of many stories in small viable features or releases.
Estimable: We hope to create and finish a piece of work in a small amount of time, so we’ll need
to be able to estimate it.
Sized Right, or Small: We used to just say small, but now we acknowledge that good stories may
not always be small, that they break down in size during good story conversations.
Testable: to really finish a story, we’ll need to verify that it’s done, usually with testing. But we
know that there’s still more testing to do to verify the sum of lots of stories is still high quality.
And, to really validate the sum of the stories we release delivers the outcome and impact we
hope for.

The simple story lifecycle

1. Card: Break your solution up into a
set of small parts written on cards or
sticky notes.
2. Conversation: Discuss each part with
team members who’ll create the
solution. Make sure the discussion
covers who and why, and not just
what to create. Make sure the
discussion includes lots of words and
pictures so that you build shared
understanding.
3. Confirmation: Come to an agreement
of exactly what you’ll create to turn
this small piece into something
finished. The bulleted list of things
you’d check to confirm you were
finished is called the “confirmation” or acceptance criteria.
4. Construction: Create the piece of the solution. Make sure the person doing the creation was
in conversations that built shared understanding.
5. Consequences: Evaluate each small piece and make adjustments to the solution as you go.
Write stories that describe the changes you’d like to make.

32 Product Thinking & Process

Agile Story Essentials
Use cards as the tokens for the conversations you’ll use to plan,
design, describe, construct, and validate your product

Stories are for telling

In the late 1990’s Kent Beck had a simple idea to solve one of the biggest
challenges in software development: communicating the details of what to build.
By simply getting together and “telling our stories” we could build shared
understanding in the minds of everyone involved.
In the conversation we’d focus not only on what to build, but who would use the
software and why. Our goal is to identify the most valuable thing we could most
economically build. Shared Understanding
When we all read the same document or hear the same
Stories get their name from how they’re used discussed, we often imagine different things. It’s describing

!! ?!
and not how they’re written q our understanding with words and pictures, and then
combining and refining our ideas that leads to shared
understanding.
Shared documents are not
shared understanding

Kent Beck, author of

Extreme Programming
!! !!
Explained

What I was thinking of was the way

users sometimes tell stories about the
Card Conversation Confirmation
cool new things the software they use Write your Discuss your ideas with others. Let Bring models, personas, UI
does: product ideas them ask lots of questions. Work drawings or whatever you like
on cards, one together to come up with ideal into the conversation. Identify
“I type in the zip code and it per card. solutions. The goal is to build ideal solutions and draw new
automatically fills in the city shared understanding. models. Work towards
agreement on what to build.
and state without me having Record that agreement as a set
to touch a button!” of confirmation tests.
I think that was the example that
triggered the idea. If you can tell
stories about what the software does
and generate energy and interest and
!!
!! ?!
a vision in your listener's mind, then
why not tell stories before the software
does it? !! ?!
A story is a token for a conversation

Vacation Photos
The information, drawings, and models you
Consequences record during conversations are mementos that
help you remember many more details than you
Now we’ve got working software to learn
from. Those who originally asked for it and can capture. People that weren’t there won’t
the builders evaluate. But, the software remember – just like they wouldn’t recall
was likely for other users. You’ll need to anything when seeing your vacation photos.
For every story in your backlog, put in test the working software with them to see
three cards. The first is what you if it meets their needs. The goal is learning.
want, the second one is there to
remind you to fix the first one. The
And your ideas for improvement start the
cycle again. Construction
third is to remind you to fix it again. Developers, testers, and others equipped with information
You’ve got to iterate or you’re not from conversations and the shared understanding that
doing it right. comes with it build and test the software.

What’s on the card “Talk & Doc” Before you build, agree on
Use story cards, or items in backlogs they way you might You’ll have many discussions around stories with team
cards in a library card catalog. Write just enough members in a variety of roles. Draw pictures and record details what you’re building
information on them to help you find the rest of the as you do. Before the team makes a commitment to build software
details when you need to. Use the card or list item to described by a story, agree on acceptance criteria for the
organize stories, prioritize, and plan. Bring models like workflow models, use cases, UI designs, or
anything else that helps you explain the story. But, be prepared software. Record the answers to these questions:
On a typical card you’ll find: to modify it during the conversation.
• What will we test to confirm that this story is
Short title! One that’s easy to read in Draw on whiteboards, model with post-it notes, or record on done?!
backlogs and easy say in standup flipchart paper during your discussions.
meetings
Keep models from your discussions as mementos to help you • How will we demonstrate this software at a
If you catch yourself referring to remember the details discussed. product review?!
the story by it’s number, stop it

Description! If the title isn’t enough, write a

description. Try to include who, When writing
what, and why. The template story tests, use
could be handy here. examples. See
Gojko Adzic’s
Specification by
Meta- • Estimated development time
• Estimated value Example for
Information! • Dependencies valuable tips.
• Status Story cards arranged as a map Story discussions supported by Acceptance criteria recorded on
with UI sketches added in. flip chart paper & drawings flipchart paper

© 2014, Jeff Patton • www.jpattonassociates.com

Stories: Concept to Delivery
Progressively split and refine stories as you move them from vague
idea through to working software

Opportunities Discovery Delivery Validation Release

Create an opportunity backlog Use discovery to elaborate, design, During delivery you’ll focus on Review finished software with the After your software is released,
from product ideas, and customer, and validate product ideas. Your designing, decomposing, and team and stakeholders. Validate continue to measure the product’s
user, and stakeholder requests. goal is to identify the smallest viable describing backlog items. product parts with customers and performance relative to its target
product you can. Discovery work users. outcomes. The most valuable
results in a product backlog.! opportunities come after seeing the
product in use.
Slice your possible product
backlog into what you’ll need
for multiple viable product or
feature releases.

Product Team Enough to test Enough to

Planning with users release
The product team meets Stories you complete in a Gather enough validate
routinely to discuss release single sprint might appear product parts that they sum
Product progress, select stories for insignificant to users. Gather up to a valuable product

Opportunity Discovery upcoming sprints/iterations, and

plan the work needed to get
enough finished tested
product parts to validate
release.
Product discovery is the
stories ready for the delivery users can reach a meaningful
Assessment work we do to determine
team. goal before testing.
Before spending time what we should build.
going into details on any Use discovery to answer
idea, discuss who the questions: Story Workshop
product, feature, or 1. What problems are we Product team members meet
improvement is for, what with delivery team member
solving, and for who? MVP
benefit it will bring by regularly to work through story
building it, and how much 2. What solutions will details and agree on
customers and users Target
it could cost if it’s similar acceptance criteria outcome
to other solutions we’ve value?
built. Use the results of this Some call these workshops
3. What are usable backlog refinement or backlog Outcome-
conversation to prioritize centric
solutions? grooming meetings. But they're roadmap
opportunities, and to
make go/no-go 4. What’s feasible to really the story conversations we
decisions. build given the time need to have
and tools we have? Release Strategy
During Discovery, try using a story map to
slice a while product or feature into a
series of viable releases.

When splitting stories, think cake Work like da Vinci to finish on time
Use each story to describe an piece of software you can “taste.” That is, once When managing a release budget, split larger stories into “opening game,” “mid game”
you’ve built it, you should be able to learn something from having done so. Whole and “ending game” stories.
features may have value to customers and users. But, it often takes a few stories
to add up to a whole feature. Try to get the “big picture” as soon as possible. Early versions that are fully formed but
The steps for making software are development tasks. immature allow early functional and performance testing. They allow earlier validation
that your concept is right.
Demonstrable, testable software is the result of those tasks. If the software doesn’t
have user interface, you’ll need to find another way to show that it works.
acquired product knowledge

Stories Delivery Tasks

Stories describe Delivery tasks give the “recipe” – describe
something you can the work someone needs to do to create
delivery and evaluate the story

Decompose
time
Development
Opening Mid Game End Game Strategy
Game Try using a story map to slice
Early stories emphasize Once we’re confident Over time the value of a feature into opening, mid,
iteration and learning. we have the “shape” stories begin to
We need to be sure of the product right, diminish signaling it’s
and end-game parts.
Decompose stories into Smaller stories often have similar recipes, just less of we’re building the we begin to pile in time for release
right product value
smaller deliverable stories any one ingredient. For example all stories will have
some testing, smaller stories should take less time
than larger stories.
 Sense and Focus
8. Use Data & Customer Interaction to Find
Opportunities
Understand how to identify relevant metrics for your product

Product Metrics: How Will You Measure Progress?

The product success metrics you’ll need to pay attention to have little to do with how fast you’re
building, or if your release is on time. Those things are important, but in the end what matters
most is how your product performs in the market.
Simple metrics funnels help you think through what metrics you could use to gauge success. For
more on metrics funnels and metrics in general see Croll and Yoskovitz’s Lean Analytics.

The Pirate Metrics Funnel

The Pirate Metrics Funnel popularized by Dave McClure is one of many approaches to identifying
and measuring outcome and impact.
Annotate this drawing as we discuss it.

Activation
Revenue
Referral
Acquisition
Retention

Sense & Focus 35

 Enterprise class products? Internal products? Rethink the funnel
For enterprise class products or products built for internal use inside your own organization, they
user is usually a different person than the chooser: the buyer or stakeholder. Adoption by users is
often mandated. You’ll need to think through what each step of the funnel means in this context.
Here are a few suggestions for things to measure.

Acquisition: Do your customers find, try, buy, or adopt?

What does it mean to acquire new customers? What might it mean to get existing customers to
try a new feature or capability?
§ Sales cycle length
§ Win/loss rate
§ Competitors evaluated
§ Existing customers reviewing information on new features or capabilities

Activation: Can they get started using the product at scale?

Activation may be all the work it takes to onboard new customers, or even groups in your own
organization.
§ Time to onboard new clients
§ Amount of customization necessary by client
§ Time it takes for all client/org users to begin to use the product
§ Amount of training time needed

Retention: Do users continue to use it as expected?

Users might need to use the product as part of their jobs, but do they use all of it? Do they use it
as you expected they would? Or, do they find workarounds to make their job easier?
§ Client renewals
§ Capabilities still used by client, or group of users within clients
§ Expansion rate of the number users/seats within a client

Revenue: Does the usage of the product have a financial impact?

Do we keep earning money from our product? For things we make for ourselves, are we saving
money or making people’s jobs easier? Try connecting feature usage with revenue or cost
savings. Features that get used a lot likely contribute. Those that don’t may be hurting you.
§ Cost savings by using the software
§ Efficiency – time to complete transactions or process work

Retention: Are users happy with the product? Are choosers?

Your users may continue to use the product and still hate it. But, their level of satisfaction may
signal bigger problems.
§ User satisfaction
§ Buyer or business stakeholder satisfaction

Create whole product funnels, and single feature funnels

You’ll need to think through how you’ll measure outcomes from every release.
Whole product metrics will help you keep an eye on the health of your whole product. But, after
a new feature is released, you’ll need to closely monitor feature specific metrics.

36 Sense & Focus

Focus on metrics that matter
If you start identifying what you can measure, you’ll quickly realize that there’s way too much to
measure. And, you can’t pay attention to all these metrics at once.

Find 1-3 metrics that help you quickly assess product

health and detect if your improvement efforts are
effective.
KPI: a key performance indicator is a metric that you can pay attention to that lets you quickly see
if your product is working as expected in the market. For products like twitter that might be the
number of tweets per week, or average time spent reading tweets per day.
Look at the key uses of your product an identify metrics that help you see the product is being
used as intended.
OMtM: The One Metric that Matters concept from Lean Analytics is valuable here. Depending on
where your product is in its current lifecycle, there are usually 1-3 metrics that you’ll need to
keep a closer eye on. For example, if a product or feature is new, it’s usually important to pay
closer attention to metrics that show the product or feature is sticky – that is metrics that show
the users are moving from activation to retention. Because, if you can’t retain them, then there
isn’t much sense in trying to get more users into the mouth of the funnel.
For guidance on choosing “the one metric that matters” and choosing good metrics in general,
read Kroll’s article: The One Metric That Matters: http://leananalyticsbook.com/one-metric-that-
matters/

Data is exhaust, not fuel

My friend Archie Miller, UX designer for CarMax, said this to me. I’m not sure where he heard it,
but it makes sense. Data alone isn’t enough to provide the insight you’ll need to really improve
your product. You’ll need to regularly spend face-to-face time with customers and users to
understand the way they use your products and the challenges they face that may fall outside the
user interface of your product.

Good data tells you what people do, but not why.
This core product team at Kodak is
responsible for a Kiosk customers use to
print high quality prints of their photos
directly from their digital cameras. They get
the empathy and insight they need by
watching customers use their product and
talking directly to them.

Sense & Focus 37

 9. Use Vision, Strategy, & Product Metrics to Focus
Prioritization
Understand how product vision and strategy inform the choices we
make about our next steps with our product.
Agile development is a good approach to delivery. Later we’ll describe product discovery
approaches that help your team better identify and validate what it should deliver. But, you’ll
need to leverage your product’s vision and strategy to make decisions on where to spend both
discovery and delivery effort.

Product vision and strategy give guidance on what’s

most important to focus on.
Without it, prioritization is difficult at best.
Product Vision: What’s Your Product’s Place in the Future
World?
In 1987 Apple created a short video describing their vision for the future. Today it looks a little
like an old science fiction movie. But in it you can see the seeds of the iPad, FaceTime style video
phone calls, and a way of working with it that feels like Siri does today.
Microsoft’s 2019 concept video produced in 2011 explores lots of touch controls and new ways to
interact with computers we see finding their way into its Surface products today.

Apple Knowledge Navigator Future Vision (1987) Microsoft’s 2019 concept video was produced in 2011
https://www.youtube.com/watch?v=JIE8xk6Rl1w https://www.youtube.com/watch?v=bwj2s_5e12U

Your vision doesn’t need to be as big or as far reaching as Apple’s or IBM’s, but it does need to
say more than how much revenue you hope to generate.

A vision goes well beyond a simple vision statement.

A product vision describes how your product(s) fit into people’s lives in the future. It’s not just the
product’s features, it’s how those features fit into their lives.

Product Lifecycle: What Stage is Your Product in Now?

Every individual product goes through a lifecycle of: market development, growth, maturity, and
decline. This old model introduced by Theodore Levitt in 1965 is still drawn today. Although
today you’ll see lots of folks trying to help you reposition your product into a growth stage, or
extend the cycle.

38 Sense & Focus

Because digital products can evolve quickly, they have the potential
to really extend their lifecycle if they can be responsive to changes in
the market.
But, because digital products often have a shorter development and
innovation cycle than traditional products, they can become
irrelevant faster.

Where is your product in its lifecycle?

Are you trying to move it forward into
“growth,” or keep it from moving into a
“decline” phase?
Product Strategy: How Will You Move Your Product Toward the
Vision?
If you have a future vision for your product, you’ll need to decide how you’ll get there. If we use
outcome and impact thinking, it’s not the features we need to build over time that describe our
strategy, it's the customers and users we’ll choose to focus on, and how we’ll help them that
matter.
If you’ve got an existing product, your directional choices are pretty simple.
1. Grow in your current market. If your product is in growth mode, focus on this. Trying other
things can be a distraction.
2. Bring a new product to your current
customers. If your growth with your current bring%a%new%
product%to%your%
product has plateaued, this is a good idea. current%customers launch%something%
Having understanding, access to, and trust of completely%different%
existing customers will allow you to discover new
new products faster. products
3. Bring your current product to new types of
customers. Your product will likely need to
change. Explore new types of customers and
bring%your%current%
learn how to adapt your product or service. grow%in%your% product%to%different%
current%market kinds%of%customers
4. Bring something completely different to
market. This strategy leverages your company’s
product design knowledge, but puts them back
new
into a startup mode to discover new products. markets
What direction is your
organization trying to expand your product?
In the HBR article “The Big Lie of Strategic Planning”, Roger Martin distills strategy down to 2
simple questions:

1. Where will you play?

What market are you currently focusing on? The sharper the focus, the clearer the strategy.

2. How will you win?

What solutions will you offer this market that’re better than other options it has today?
Good strategy is a bet. There’s risk involved. Using solid discovery practices and the right product
metrics will let you see if you’re making progress towards your strategy.

Sense & Focus 39

 Product Scorecards help make your strategy visible and
measurable
OKRs, or Objectives and Key Results, were popularized by Google and Facebook. Product
Scorecards have long been used by companies like eBay. They both serve to sharpen our focus on
the outcomes and impact we’re trying to bring about with our current product efforts.
A Product Scorecard identifies the 2-6 key metrics that your product team is currently focusing
on. The scorecard will change as your product strategy changes. Expect to revisit scorecards at
least every quarter.
Look at this example eBay Scorecard from Marty Cagan. You’ll see 4 metrics that support an
objective.

Increase the number of high-volume sellers at eBay through

encouraging use of promotional seller tools.
1. Average revenue/seller
Because we want to encourage sellers to sell more goods

2. Average promotional revenue/listing

Because we want to encourage sellers to promote their listings as aggressively as
possible

3. Absolute number of high-volume sellers

Because we want to grow the number of high-volume sellers

4. NPS of high-volume sellers

Because we want the sellers to consider ours their preferred marketplace

OKRs help teams focus and prioritize work

Create OKRs just as you might create a scorecard with 2-6 metrics that support an
objective. Give each metric a specific target. Make the OKR ambitious - a stretch goal.
You shouldn’t be too confident you’ll reach it. For each metric you choose, expect your
confidence to be at 50% when you create it.
Create the OKR for a short time period, usually 3 months. A 3-month or quarterly OKR
should help your product progress towards its longer-term vision. Some organizations
create annual objectives that quarterly OKRs move towards.
Every week or two review your progress towards the OKR.
At the end of the quarter score each metric from 1-10. Then average the score across
all metrics. 60-70% is good. Remember you set metrics with only 50% confidence going
in.
Christina Wodtke’s “Radical Focus” is a good starting point for using OKRs in your organization.

40 Sense & Focus

Focus product teams by giving them a problem to solve
For product teams to take responsibility for the success of their products, they must take
responsibility for successful outcomes. But, there’s a temptation for leadership to simply tell
teams what to deliver based on their own beliefs and assumptions. This steals responsibility for
success from the product team.

Don’t steal the responsibility for success from the team

The goal: frame work as a problem to solve, not a solution to implement
why: solving problems allows product discovery to happen since we’re not dictating a solution to
the teams
how: identify current sub-optimal customer behaviors or changes in the market that could
threaten the business in some way or provide a new opportunity for the business, determine
where the current system isn’t meeting the goals to take advantage of or address these concerns,
ask for improvement to the system/product with “improvement” measures as an outcome — a
meaningful change in customer behavior

Try summarizing the business problem using a problem statement:

This problem statement is borrowed from Gothelf and Seiden’s Sense and Respond.

[Our service/product] was designed to achieve [these goals]

We have observed [in this way] that the product/service isn’t
meeting these goals which is causing [this adverse effect] to
our business.
How might we improve [product/service] so that our customers
are more successful as determined by [these measurable
changes in their behavior]?

Given the product team understands the problem they’re solving, identify
leading indicators of success.
The success criteria in the business problem statement are high-level and strategic — i.e.,
revenue, customer satisfaction, engagement, etc…often these are lagging indicators.
For the team to know if they’re making progress, look at specific customer behaviors that lead to
the lead business benefits. Then identify ways for the team to measure them.

Identifying business problems and leading

indicators of success keep your team focused on the
right problem. The team will make better choices for
user problems to solve and evaluate solution ideas more
effectively.

Sense & Focus 41

 Form a Hypothesis
10. Frame Product Improvement Opportunities
Understand how to frame product improvement ideas in terms of its
value to your organization and its target audience
There will always be more possible products, features, or feature improvements to build than
there is time to build them. Think of these ideas as potential opportunities. Before you begin to
engage in deliberate discovery work with any opportunity, it’s best to size it up in relation to
other opportunities you have.
Framing also helps you constrain your design and discovery process to specific customers, users,
and challenges to solve. Without these constraints, a design process can expand out of control
very quickly.

Canvas approaches
The “canvas” approach to looking at business models described by The Business Model
Generation is an effective way for groups to work together to size up a startup business. You can
use a similar canvas approach to sizing up product opportunities.
Using a canvas approach has real benefits like:
§ Seeing important concerns of an opportunity in a single view
§ Seeing the relationships between these concerns
§ Building shared understanding, ownership, and alignment by working together and
leveraging everyone’s knowledge
As a product discovery team, fill out the canvas initially based on what you understand today.
Use sticky notes to make it easy to change your mind as discussion progresses. Iteratively
improve the canvas as you learn more.

You could proceed through the canvas starting with the first box, and continuing to the last.
However, if you don’t have good answers for a box, record what you do know, or your
assumptions now, and proceed on.

42 Form a Hypothesis
Fill out canvas in one flow, read in another
The boxes in the canvas are numbered in a logical order you could use for discussing an
opportunity. But, if you’re sharing the canvas with someone else, you may want to read it left to
right, and top to bottom. You’ll notice the left to right flow is from “now” to “later” in the output
vs. outcome model introduced earlier. You’ll also notice that top to bottom moves from “users’
needs” to “business needs”.
This isn’t a form to fill out. This is a set of topics to discuss and iteratively refine your
understanding of. Remember: “design by community isn’t design by committee.” Involving lots
of folks helps everyone learn faster. But, ultimately the go/no-go decision to proceed with an
opportunity falls to the product owner. The best product owners leverage their teams to help
make the decision, and usually find that they and their teams are in agreement.

Canvases and abstraction level

Canvases like the Business Model Canvas or Maurya’s Lean Canvas are useful for thinking through
new products. A new product needs to generate revenue, and will have costs associated with it.
It needs to respond to a strong enough need from customers so that they’ll choose to use it. A
new product needs to achieve some amount of product market fit.
With existing products where we already have some degree of product market fit, we’ll look to
improve the product by adding features or capabilities. The Opportunity Canvas described here
works best at this level. Osterwalder’s Value Proposition Canvas is useful for discussing new
features as well.
Many companies create their own variations of canvases tailored to fit their organizations.

The Australian Football League (AFL) has tailored the Atlassian’s Experience Canvas blends ideas from
Opportunity Canvas to meet their need. several canvas styles.

Guidelines for filling out a canvas collaboratively:

1. Work fast
Sketch a canvas in a single sitting: 30-90 minutes with a small cross functional group. Don’t get
caught in long debates over what the right thing is to put in a box.

2. Skip what you don’t know

You should find information you don’t know or can’t even guess at. That’s OK. Just skip the area
for now. Come back to it later.

Form a Hypothesis 43
 3. Guess
If you’re working with a reasonably experienced group, they’ll have educated guesses. Write
those down, but note that they’re guesses. You could use more polite words like “hypotheses” or
“assumptions.”

4. Plan to iteratively improve

If you’re honest with yourself, you’ll have vague items, missing items, and guesses. That’s OK. If
you expected to have nothing to learn, then you’re likely fooling yourself. Make a list of those
things you don’t know, prioritize the riskiest things first, then discuss specific things you can do to
replace missing information or guesses with facts.

Opportunity Canvas
Use an Opportunity Canvas to explore a new capability, feature, or enhancement to a product.

Here’s the flow of spaces in the Opportunity Canvas:

1. Start with User’s Problems or Solutions 4. Business Problem
Ideally we should start with a clear problem we’re What problem for your business is created when
trying to solve. However, the world is rarely ideal. users have the problems you described above?
We’re often given a feature or enhancement idea
and then need to work backwards to understand the 5. User Value
problem. Start with what you have. If your target audience has your solution, how can
they do things differently as a consequence? And,
Solution ideas how will that benefit them?
List product, feature, or enhancement ideas that
solve problems for your target audience. 6. User Metrics
What user behaviors can you measure that will
Problems indicate they adopt, use, and place value in your
What problems do prospective users and customers solution?
have today that your solution addresses?
7. Adoption Strategy
If you’re building a product for entertainment like a How will customers and users discover and adopt
game or tool to share fun stuff on a social network, your solution?
they may not have a real “problem” to solve, just a
desire to be entertained. 8. Business Metrics
What business performance metrics will be affected
2. Users & Customers by the success of this solution? These metrics are
What types of users and customers have the often a consequence of users changing their
challenges your solution addresses? behavior.
Look for differences in users’ goals or uses that
would affect their use of the product. Separate users
9. Budget
How much money and/or time would you budget for
and customers into different types based on those
discovery and validation?
differences that make a difference. It’s a bad idea to
target “everyone” with your product. How much money and/or development would you
budget to discover, build, and refine this solution?
3. Solutions Today
How do users address their problems today? List
competitive products or work-around approaches
your users have for meeting their needs.

44 Form a Hypothesis
Ash Maurya’s Lean Canvas
Use a Lean Canvas to evaluate a new product idea. Lean Canvas is a more customer-centric
alternative to the Business Model Canvas.
Brainstorm multiple customer types and fill out a lean canvas for each. Use a Lean Canvas to
evaluate opportunities from the perspective of different customer types. Fill in a Lean Canvas
collaboratively as a group to build shared understanding about why you’re building your product.

Ash Maurya’s Lean Canvas model was adapted from the Example Lean Canvas constructed with sticky notes on
Business Model Canvas found in the book: “Business Model whiteboard. Example from Scott Torrance:
Generation” www.startitlean.com

Components of the Lean Canvas:

I’ve shifted the order Ash suggests you discuss these, placing cost and revenue last.
Remember that discussions of all these details are iterative. While you may discuss them initially
in a particular order, each discussion may drive the need to learn more. Don't stop filling in the
canvas if you don’t have an answer. Write what you do know, then come back with details when
you have them. Iteratively improve the canvas.
1. Target Customers: Specifically who is this product for?
Top 3 Problems: What are the top 3 problems your product solves for your customers? How
do they solve those problems today?
2. Unique Value Proposition: Single, clear, compelling message that states why your product is
different and worth buying.
3. Solution: What are the top 3 features that make your product compelling to its target
customers?
4. Channels: Who will market and deliver the product to your customers?
5. Key Metrics: Name 3-5 key metrics that help you measure product success.
6. Unfair Advantage: What unfair advantage do you have that makes it difficult for your
product to be copied or bought elsewhere?
7. Cost: What will your solution cost to create, host, support, acquire customers…
Revenue: What revenue will your solution generate? What are drivers for generating that
revenue? How do increases in revenue affect increases in cost?

Form a Hypothesis 45
 11. Organize What You Understand About
Customers and Users Today
Learn to use simple profiles, and personas to describe facts and
hypotheses about your customers and users

Segment your audience using differences that make a difference

What differences in users’ goals and behavior would change the way they
choose to buy and use your product? Use these differences as a basis for
segmenting your audience.
There are many ways to segment your audience. Look for:

Differences that make a difference

Differences in the way people would use your product to meet their goals.

Types –> profiles –> personas

Segment your audience into types. Types could be based on job
roles for business software, or the primary activities and goals
people engage in for consumer software.
Add information that you understand today about each type.
This collection of information helps profile each type.
Create an example user, customer, or company that uses your
product by selecting representative data from your profiles.
These examples are called personas for users and customers, or
orgzonas for companies.
Consider the product design implications of the information in
your personas and the profiles you communicate.

If a detail in the profile or persona doesn’t impact the

design, leave it out
Leverage what you know today
Sketch personas that leverage what you understand today. Create them collaboratively, involving
team members and others inside your organization that have past user experience.

Call out your assumptions clearly so that you can plan

your research to validate them.
Personas and persona hypotheses
Personas we build based on assumptions and anecdotal experience are considered hypotheses. In
practice a persona is never pure hypotheses or pure fact. In most product organizations, teams
start with a mixture of data and hypotheses. After creating personas, discuss and identify what
information is hypothesis, what the riskiest hypotheses are, and what you could do to validate
these hypotheses.

46 Form a Hypothesis
Characteristics to consider when gathering information:
Use your intuition to help you choose relevant details to: plan to learn during research, collect in
user profiles, and to describe in user personas. These general categories of information may help
give you ideas.

General characteristics and demographics

General demographics about this user Domain or subject matter experience
constituency How much can the software assume this user
How many people occupy this user type? Are they knows about their business domain or the
mostly male, female, or a mixture? What education subject matter the software deals with? Is the
and economic background do they come from? software responsible for "teaching" the user or
can we freely sprinkle the software with jargon
Technology skills and concepts understood by experienced
people? For example: if we’re talking about an
How skilled is this person using computers and
application for finding movie information, how
software in general?
much can we assume they know about the
movie business?

About users’ activities or jobs:

General activities or responsibilities Collaborators
If this user type uses the application as a part of Who does this user work with or speak with on a
their job, then what they do in it is likely their job regular basis? Does this user need to collaborate
responsibility. Using the application may be with someone to achieve their goals with the
personal choice or further a personal goal. It may be software?
just for fun.
Other products, tools, or reference
Usage locations material
Where will the user likely use this software? Is it a What other pieces of reference material, tools,
single place, or a variety of places? On what kind of or other products does the user likely have at
device will it be used – desktop computer, their disposal? Do they rely on these tools to
notebook, iPhone? complete their work? – To be successful?
Software & tool ecosystem Expected frequency of use
What other hardware or software products does How frequently do we think this type of user will
this user consistently use? use the software we're considering?

Users’ goals & Pains

Success goals & Joys Pain points
How does this user evaluate success? What’s the What causes this user trouble outside the
reward that motivates this user to use our software or inside the software they currently
software? use? What common trouble does the user hope
to avoid by using this software?

Form a Hypothesis 47
 Create a persona sketch that describes your target user
As a group, discuss the audience segment that has a need that you believe you can address.
Create a simple persona sketch:
§ Consider the list of profile characteristics above.
§ Use information you heard when talking to others as well as assumptions and
anecdotal information.
§ Speak in examples. Instead of saying “tech savvy” say “Uses an iPhone that he’s jail
broken in order to run software not available through iTunes.”

Contextualize personas for each new opportunity

If your organization has invested in building well researched personas, use short persona
sketching conversations with your team to contextualize them for the feature or opportunity
you’re exploring right now. What information, activities, and needs are most important to
consider? What solutions or consequences are there for those?

48 Form a Hypothesis
Sketching Personas
Simple relevant user personas created collaboratively
A persona describes an example user of your application.
Use a persona to communicate relevant data about
different segments of your audience.

Ideal personas are created based on user research.

However, effective personas can be created from the
anecdotal experience, expertise, and assumptions of
members of your organization. This type of person may
be called a persona hypothesis [Cooper] or an
assumption based persona [Pruitt & Adlin].
Lightweight persona sketches
A persona sketch is a simple persona sketch created
collaboratively in a workshop setting. The creation
process leverages subject matter expertise, experience,
and assumptions from workshop participants. If you've
got solid research data, bring that into the discussion too.
"Fully&dressed"&persona
Pragma2c&persona&sketch

Anatomyof a Pragmatic Persona Sketch

Name, role, & picture
You'll find team members alternate between referring to types of
users by name and role. I prefer choosing a name that helps others
remember the role.

Over time the picture will be all it takes to remind team members of
relevant persona details.

Context:
Use this space to place to say who the user is, and how they've come
to use the software. Try the form "[persona name] uses [product
name] to…"

About
Through discussion or by assembling known data into a profile,
choose information about this user type relevant to the design of your
product.

General stuff about these kinds of people

▪ technology skills
▪ subject matter expertise
▪ relevant demographics (ages, genders, professions...)
Activities they'd use your product for
• General responsibilities or activities they'd use your product for
• How do they accomplish their activities today with your current
product or without your product?
• Where are they when they use the product?
• Frequency of use - how often are they likely to use the product?
• Collaborators or other participants
• Software or tool ecosystem: what other products do they use for
this activity, or generally?
Pains & Joys
• What motivates them to use your product instead of another
product?
Further reading • What makes them happy? (“tell me about a good day.”)
Pragmatic Personas, Patton, Stickyminds.com • What makes them mad? (“tell me about a bad day”)
http://www.stickyminds.com/s.asp?F=S15793_COL_2
A simple article describing the pragmatic persona, and how to create it.
Implications or Values
The Persona Lifecycle, Pruitt & Adlin, Morgan Kaufman, 2006 For each item in the about, consider the implications to your
Thorough treatment of personas through their entire cycle of creation to eventual retirement.
product's design such as:
Yahoo's Approach to Keeping Personas Alive, Spool, 2006 • Feature opportunities
http://www.uie.com/brainsparks/2006/05/18/yahoos-approach-to-keeping-personas-alive/ • Product characteristics such as ease of learning, efficiency,
Examples of concise, relevant personas, and how Yahoo uses them in an agile context.
reliability, necessity for proficiency or accuracy, etc.
How to Understand Your Users With Personas, Colbow, 2009
http://carsonified.com/blog/design/how-to-understand-your-users-with-personas/
Cool comic that describes what a persona is and what it's used for.

© 2014, Jeff Patton • www.jpattonassociates.com

Collaborative Persona Sketching
Simple relevant user personas created collaboratively
Build personas collaboratively in a workshop that includes people with experience and subject
matter expertise.

Prepare for a persona building workshop

Plan for a 90-minute to 2-hour For a product workshop you'll need to invite:
workshop. Any longer will leave • Information suppliers: people with subject matter
participants exhausted and less expertise or past experience with users.
than effective. • Information acquirers: key members of the delivery
team who are passionate about the product and
You'll need flip chart paper & can help socialize the outcomes.
markers. • Facilitator: someone with facilitation skills and
Try to keep the workshop small - understanding of how personas are created and
5-8 people why.

Facilitate the persona creation

Post the workshop objective where everyone can see it.
Post a parking lot - a sheet of flip chart paper labeled "parking
About User Types
lot" where the facilitator can record off-topic discussions or ideas Think of different categories of people as user types.
that come up during the workshop. • College students
• Business professionals
Get started building personas:
Think of the relationships users might have with your

Identify types of users

product as user roles. For restaurant locating software
1 the types above might be described as these roles:
Use sticky notes or index cards to brainstorm types of • Late night pizza buyer
users, one type per card. Remember the first rule of • Daytime lunch seeker
brainstorming is no discussion or criticism.
After brainstorming slows, cluster types that are similar
together. 2 [Optionally]
For each cluster choose a name for that type or role
that best describes the types clustered there.
Profile user types
Identify characteristics, or categories of data
Discuss and add any missing roles. that you believe are relevant to your users and
For a typical product it's common to end with 5-10 roles. the product you're designing. (Try starting with
the items mentioned for the "about" section on

3 Personify user types the other side of this page.)

Starting with the most important user, For each
For each type of user, the facilitar leads a discussion type of user and each category of data record
about that user. information and assumptions from the group of
Give the user type a name and picture collaborators in the workshop.
Discuss the context where the user would experience
your product. Socializing(simple(personas(in(a(team(at(Yahoo!
Discuss characteristics of the user most relevant to
design.
For each characteristic, discuss it an pair it with one or
more design implications.

4 Plan further research

As you discuss each user type, you'll notice that some of
the information you need for profiling and personifying is
tacit in room, and some isn't. In fact, for much of the
information you need to finish a persona you may be
guessing.
For each type of user discuss what information is missing,
what the risk to the product design will be if you don't
know, and how you might acquire that information.
Sketch a preliminary research plan for getting it A(simple(list(of(persona(
characteris9cs(a:er(a(

Socialize & Leverage personas

workshop/style(discussion

Post the hand created personas where they're visible to the team.
Persona(quick(reference((
Convert the hand-built personas to higher quality electronic visualizations.
/>(3(personas(each(side
See the Yahoo! example of socializing personas.
12. Map User Experience
Understand the concepts and essential practice of mapping user
experience as a story map
We’ll build a simple model using sticky notes. We’ll build this model to practice and learn
concepts. When we’re done, we’ll discard it.

1. Silently list all the steps you took to get ready to come here
today
Grab some sticky notes and a marker.
You’ll need at least 20 or 30 stickies.
Think back to the moment you woke up
this morning.
Then, write on sticky notes everything
you did from the moment you woke up,
until the moment you left your home.
For instance, my first sticky note usually
says, “hit snooze.” Then my next says
“turn off alarm” and then “stumble to
the bathroom” and so on. Mine look
like this:

Write only one step per sticky note. And,

make sure you use a marker so that
when we combine these with others’
notes, they’re easy to read.

When you’re done, we’ll discuss the following concepts:

• User Tasks, Steps, or Actions
• Task Goal Level
• How differences in people’s goals and contexts affect
their choices of tasks
2. Organize into a map
Work together to organize the tasks written by everyone at your table into a single left to right
flow where things on the left happen early, and things on the right happen later.

Do this silently
Organize stickies without talking. If you disagree with where a sticky is placed, no need to talk,
just move it. Of course, others can move stickies you’ve placed as well.
You can stack duplicates on top of each other. You may choose to place some sticky notes in
columns if they seem similar but not identical. Don't think too hard about where you place them.
Just do what seems natural.

Form a Hypothesis 51
 When you’re done, we’ll discuss the following concepts:
• Narrative Flow
• Sub-tasks, alternative tasks, & details
3. Distill to identify activities
As you look across the map left to right, you’ll notice that there are groups of stickies that seem
to go together. That is they may seem directed at a similar, but larger goal.
Using a different color sticky note, mark each “activity.” Together decide what to write on this
sticky note. Use a short verb phrase.
You may find that some of the tasks may need to be reorganized when you try to come up with
an activity name. It’s OK to move sticky notes, rewrite them, or split sticky notes that contain two
ideas.

When you’re done, we’ll discuss the following concepts:

• User Activities
• The Backbone
3. Fill in your map
We’d like a map that does a good job at describing how people typically get ready in the morning.
Let’s check to make sure it’s complete. And, let’s consider mornings other than just this one.

Add tasks you missed

Now that you can see the whole picture, you may realize there were steps you’d missed.

52 Form a Hypothesis
Take a minute and add in sticky notes for tasks you did to get ready, but didn’t initially write
down. Then, add those tasks into your team’s map.

Add tasks you do on other mornings

Now think back to yesterday. Were there things you did yesterday that you didn’t today?
Think of weekend mornings, or other special mornings. What tasks do you do on those days that
aren’t typical?
Think of mornings when things have gone wrong. What tasks did you do then?
Think of mornings that are ideal. What do you do on those days that make them ideal?

Add all these tasks into your map

Write the tasks down, and then say them out loud to others in your group before placing them in
the map.
Try to make it a habit to write before you speak. Don't let your ideas vaporize. Make sure they’re
included in the map. Keep this mantra in mind:

Think it – write it – say it - place it

You may need to reorganize the map a little to support the additional tasks you and others in
your group are adding.

4. Identify pain and rewards

As you look across this map you’ll see a flow that describes how people in your group typically get
ready in the morning.
Think about what the most challenging or painful parts of this story are. On a pink sticky note,
write a pain, say it out loud, and place it in the model. Identify several.

Remember: Think – Write – Say - Place

Think about what makes your morning fun or rewarding. On a green sticky note, write it out loud
and place it in the model. Write several.

5. Add in solutions and improvement ideas

Look across the whole map. Especially look at the pains and rewards. What could you do
differently or change that would result in less pain, or bigger rewards?
Use a different color of sticky than you’ve used already, maybe bright orange, and write, then say
and place your ideas for:
§ Things you could do to solve problems
§ Things you wish you’d done
§ Things you’d like to try

6. Slice out a minimal “getting ready” workflow

Let’s pretend for a moment that this morning you didn’t have to turn your alarm off because it
didn’t go off at all. Pretend you woke up late and you only have a few minutes to get ready and
get out the door.

Add a target outcome

Write this outcome on a sticky note:

Get out the door in a few minutes

Place the goal sticky note on the left edge of the map.

Form a Hypothesis 53
 Slice the map
Now imagine a line slicing your map left to right. Place all the tasks below the line that you would
not do to reach the goal hanging to the left of the slice.
For example, you might choose to skip breakfast if you only had a few minutes to get ready. If you
would, move that task below the imaginary line.

Do this silently!
Organizing steps like this goes faster when you allow the placement of the sticky notes to do the
talking for you. It can take a lot of conversation to confirm that we’re in agreement – and that
slows things down. Save your conversations for when you don’t agree.

Add in tasks necessary to reach your target outcome

You may find that when you remove everything you wouldn’t do, there are other things you
would do that aren’t in the map. For example, you might choose to skip breakfast, but you may
choose to grab a snack like a granola bar to place in your bag before leaving. That task to “grab a
granola bar” to eat later may not be in your map now, so add it.
As a team, look at the items in the slice that’ll help you reach your target outcome. Discuss it and
add in the tasks you’ll need to reach that outcome.
A target outcome is specific to a group of people. And, this one is specific to the people in your
group. So, focus on identifying a set of tasks that you can agree on.

When you’re done, we’ll discuss the following concepts:

• Target Outcome
• Minimum Viable Solution
Done!
Did you gain any insights about how people get ready in the morning?

Do you feel like everyone in your groups has a similar understanding of what it
takes to get ready in the morning?

54 Form a Hypothesis
Story Map Concepts
Use simple maps to visualize the stories you tell
about your software

Users User Tasks Goal-Level Activities

A map tells a story about a type of User’s tasks are short verb phrases The actions that users take in order Activities organize tasks done by
person doing something to reach a that are the basic building block of a to reach their larger goals have a similar people at similar times to
goal. Make sure to include them in map. If I ask you what you did goal level themselves that’s tied to reach a goal. For your email
your map along with a little earlier today when using email, user behavior. software activities might include
information about them. you’ll likely respond with tasks like: • Going through my inbox
Summary: lots of tasks done in • Configuring my email client
• Read an email message
Try using lightweight persona support of a bigger goal.
• Respond to a message • Organizing messages into folders
sketches to describe your users. • Mark a message as spam Functional: I’d expect to complete
this task before taking a break.
Sub-Functional: smaller things
done in support of a bigger tasks.
As you read across tasks in the
Backbone backbone, check to make sure
that tasks are of a similar goal
Activities and tasks at a higher goal
level give the story map it’s
level. Narrative Flow
structure. The backbone is The left to right axis in a story map
arranged in a narrative flow. Smaller is organized in the order you’d tell
sub-tasks, details and variations the story about your user to
hang down to form the ribs someone else.
connected to the backbone.
Of course any specific user might
choose to do different things in a
different order. Use conversation to
explain the details and variations.
If you’re looking for the precision
of a workflow model, flow chart,
or UML model, then a story map
isn’t your best choice.

A story map will take lots of

conversation to use effectively. But
then that’s the purpose of stories.

Release Slice Use Details, Details...

r
grea Tasks
Use a tape line to identify slices of tasks that users might use your software Break down high goal level tasks into:
for to reach their goals. The smallest number of tasks that allow your • Sub-tasks
specific target users to reach their goal compose a viable product release.
t sto mak • Alternative tasks

r
itles e
Wr
y
• Exceptions
Use ite short
Use release slices to identify small experiments, minimal viable
product releases, or a “walking skeleton” version of your product. stor
them verb
later phra t • Details

Identify the target outcomes of your slice in a sticky note or card to the left
y
nice templa as you ses on
ly rig t r c
ht a e to writ story tit ards or
! Down in the details of the map, it’s OK to
include details about what UI might look like or
of the slice. fter e de les. stick
“I s If ie what the system might do in the background.
righ want to cription you us s.
t aft
er “s ,” the ac s, the ta e the
o th t iv s k
at… ity fits fits
” nice
ly

Map Now & Later Map the Whole System

Use a map to describe the world as it is today. Inject pains, joys and rewards, Map a whole process as it crosses through a number of types of users
details and observations, and solution ideas.
Story maps are for looking at the big picture
Evolve the map using design and discovery to describe the behavior you
expect users to have in the future.
Story maps are for understanding now, and imagining later.

© 2014, Jeff Patton • www.jpattonassociates.com

Story Map Process
The story map evolves with your understanding of
your users and your product solution

1! Frame
Before mapping, create a short product or
feature brief to frame and constrain what you
map. Think of this as the big story.
What names the product, feature to add to a Why describes the benefit your organization gets
product, or problem you’d like to solve. by building the product or feature. Say what
users do and how their use leads to increased
Who names the different types of users who will
revenue or reduced costs.
use the product, and the “chooser” or customers
who will buy it. For each user and chooser state
the benefit they get from using the product.

2! Map the Big Picture

Focus on getting the whole story. Think “mile- Identify user activities – groups of tasks that
wide, inch deep” The activities and high-level user work together to support a common goal.
tasks that tell the whole story form the backbone Activities often emerge after you see more of the
of your story map. story. !
Start with the user type most critical to your Add in additional users. As you follow the
product’s success. Imagine a typical day in typical use of your product, you may find other
your user’s life with your new product. Map the types of users enter your story. Continue
steps they take as user tasks left to right. modeling their story left to right.

3! Explore
Fill the body of your story map by breaking • Play “wouldn’t it be cool if...” to help think of Involve others. Tell your product’s story to others
down larger user tasks into smaller subtasks and great product ideas. that understand users and use. They’ll find holes
user interface details. During this phase you’ll add • Look for variations: What else might users of in your story and help build it up. Tell your
cards, split one card into two, rewrite cards, and the system have done? product’s story to software developers. They’ll
reorganize them. • Look for exceptions: What could go wrong, point out risky or expensive areas, and add in
and what would the user have to do to recover? great technology solutions.
Use this phase to think “blue sky” about all the
• Consider other users: What might other types
great possibilities. Use this time to think of
of users do to reach their goals?
everything that could go wrong. Don’t worry if
• Add in other product details like: Description
your ideas are “in or out of scope.” You’ll
of proposed UI; Business rules; Data elements
deliberately move things out of scope later.

4! Slice Out Viable Releases

Slice your map into holistic product releases For each release name the target outcomes For each release, identify product success
that span the users and use of the product. and Impact. Outcomes and impact says how metrics. Answer the question: “what would we
These slices form an incremental product release this release contributes to the overall goal in the measure to determine if this product was
roadmap where each release is a minimal viable “big why” that motivates building the product, and successful?” Ideally you’ll find specific changes in
product release. how users will behave in a way that helps us user’s behavior as they use the product the way
reach the goal. your story map imagines.

5! Slice Out a Development Strategy

Slice the first release of your map into three or • Opening Game builds a “functional walking Plan the work necessary to refine stories.!
more delivery phases that allow you and your skeleton” – the simplest possible functional
Workshop stories with developers and testers
team to learn fast and avoid risk. Think of the version of the product. As you finish "Opening
to work through details and agree on
opening, mid, and end-game phases of a chess game" vet the product with users and other
acceptance criteria.!
game. stakeholders. Begin validating performance and
scalability. Plan development and testing.!
This development strategy will help you release
the best product possible in the time constraints • Mid Game complete all major functionality Build and verify parts of working software.
you have. and makes existing functionality richer and more
complete. Continue user testing and leverage
feedback to adjust the product. Continue
testing performance and scalability.
• End Game refines the product in preparation
for release. Continuously assess release
readiness based on your release level product
goals. Count on unforeseen work to emerge
during this last stretch of development.
Now, Map Your Customer’s Journey Today
A story map that describes a customer or user’s journey today is often called a journey map. It
includes the steps they follow, but also questions they have, problems, joys, and other context
that helps us empathize with them.

Create a map to build shared understanding within

your design team of user’s journey today

Use a story map to map your target customer’s and user’s journeys as they are today.
Include in your map:
§ What people do: Steps, actions, tasks, and activities
§ What people think: Questions they have, problems, pains, joys, rewards
§ Context: Where they are, who they’re with, what tools or devices they use, what
information they keep at their disposal

Form a Hypothesis 57
 13. Focus and Ideate to Consider Many Possible
Solutions
Avoid bloated solutions by focusing your solutions on specific
customers, users, and challenges
Understand the concept of ideation, and the design studio practice
for collaboratively ideating
As a design team you’ll need to converge on specific customers and users to focus on, and
specific problems to address.
Here are a few things to try that may help you converge:
§ Discuss and choose a user type that you believe best serves your business concerns
§ Slice the journey map by target user types to find pains, joys, and observations
most relevant to specific user types
§ Dot vote on the problems you think would be most beneficial to solve, or joys that
you’d like to magnify

This still shot from the Google Ventures Design Studio video example shows how they created a
simple journey map, annotated it with information and problems users encountered, then
highlighted the specific problem area in the journey they chose to focus on.

Write a simple focusing statement

Use a Stanford d.school “How might we” madlib

How might we help [type of customer]

To [accomplish some goal or perform some activity]
When [What makes it hard? What makes it rewarding?]

Ideation
Your first idea is never your best, at least not usually.
Ideation is a deliberate activity where you push yourself and your team to think past those first
obvious ideas. You should come up with dozens of ideas, not just 2 or 3. You shouldn’t over-invest
in any one idea – don’t spend too much time to create or communicate it. You’ll find the best
ideas are combinations of multiple ideas from within your design team.

Use a Design Studio approach to sketch and sharing ideas

Take quiet time to independently sketch your ideas.

58 Form a Hypothesis
Push yourself to sketch multiple ideas. Move past your first obvious ideas – because they’re never
your best.
Describe your ideas with:
§ Words – tell a story
§ Pictures – draw user interface, storyboard screens, storyboard a comic

Ideation round 1: write impossible or magical ideas

Take 2 minutes to list as many solution ideas for your target user that would require magic, or
science not possible today. For example, you could use technology that reads minds, or
transports users magically to a new destination.
Review ideas in this round with each other. Ask, is there a way to “dial the idea back?” – to a
version that would solve the problem in a similar way, but be feasible to build.

Ideation Round 2: sketch feasible ideas

Take just 5 minutes to sketch ideas you believe are possible. You could sketch:
§ Thumbnails of multiple ideas
§ Details of one or more ideas
§ A storyboard or comic that shows the steps of your target user using the software

Review ideas to find the best elements

Go around your group, person by person.

When it’s your turn:

§ Explain your best idea in 2-3 minutes
§ Make sure you place what you’ve drawn where people can see. Describe your idea by
telling a story about the user of the product, and how they’d use it to solve a problem.

After you describe your solution, everyone discusses it for 2-3 minutes:
§ Give feedback from the target user’s perspective: “Clair would like this because…” or
“How would that help Clair solve her problem of…”
§ Build on to ideas in the sketch: “If we added this other idea we just talked about, this
would be even better…” or “I could see going even further by…”
§ Mark, or make notes of the ideas you want to keep and leverage in your next round of
iteration, or your final solution.
§ Make sure you record notes and comments on sticky notes as you say them, and tag the
sketches with these notes.
Repeat this person-by-person pattern going around the circle several times until your group hits
the end of your time-box.

Converge and Describe

Your discovery team has deliberately come up with a number of potentially great ideas. It’s time
to combine and refine those ideas and begin to describe the solution you’d like to create.
Work together to combine your best ideas into a visualization that communicates the user
experience of your product and a textual description that begins to chunk up your product into a
backlog of smaller buildable product parts.

Form a Hypothesis 59
60 Form a Hypothesis
Ideate Collaboratively Using
Design Sketching In software development, communicate the product goals and context to the team, then allow
team members a short time to sketch their solution ideas. Use a collaborative workshop involving
the whole team to critique solution ideas and identify the best elements. Synthesize the best
elements into a better product design.
Design Studio was first described as an agile UX technique for collaborative design sketching by
Jim Ungar and Jeff White.
A design studio workshop models the approach often used in a design school or design shop
where participants work independently on product design ideas, then together as a group
critique designs in order to improve them.

Why?
Use a design studio approach to allow the whole product team to consider, sketch, and share
their solution ideas. After a design studio exercise the whole team gains:
• Shared understanding of the problems being solved by the software
• A chance to contribute good ideas to the final product
• A chance to help combine and synthesize good ideas into a finished product solution
• Appreciation for how difficult good user interface design can be
Ultimately the product benefits from a simple form of ideation, or considering multiple possible

Plan
solutions, to a product design problem. The resulting product design is more innovative – better

1 than it would have been otherwise.

Identify the product or product

Further Reading:
Unger & White, Agile user centered design: enter the design studio - a case study,
area to focus on: http://portal.acm.org/citation.cfm?id=1358650
The product area may be the main focus of a next Patton, Consider Multiple Solutions,
release, or a troublesome part of the existing http://www.agileproductdesign.com/writing/ieee/patton_consider_multiple_solutions.pdf
product. Identify the goals or problems to solve with
the new user interface design.

Identify context to provide to

the team:
Describe the purpose of the functionality being built.
2 Perform
Give information about users such as simple personas
Setup:
Setup by posting the goals and agenda for the workshop. (Make sure to give short breaks
that describe typical users of the software, and their
every 60-90 minutes to help keep participant’s energy up.) Supply the room with pens,
goals when using it.
sticky notes, and flip-chart paper.
Describe details about the problem to be solved such
Kick off:
as useful facts, workflow, or problem scenarios.
Describe the goals and the workshop agenda.
Identify details; specifically the kinds of information
users will need in the user interface. Sketch:
Invite the team: If you didn't ask participants to sketch ahead of time, give everyone a time-box for
Schedule the design studio workshop as a half to full sketching now. Some facilitators give as much time as 30 minutes, or as little as 5 minutes. In
day event. 5 minutes participants only have time to rough in their ideas.
Ideally invite the whole team that will implement the
solution. Consider inviting outside stakeholders who
Present:
Ask each participant to present his or her sketch – taking no more than two minutes.
want to weigh in on the design.
It might go a bit like this: “Here’s my sketch”; “This is my vision of the solution”; “This I why I
Communicate the goal for the made this decision, this is why I made that decision…”; “Team, what do you think?”

workshop: Critique:
Communicate the details about the context that After each presentation, the whole group quickly discusses the solution.
participants will need to sketch their solutions. As a facilitator remind participants that: “It’s about critiquing the design, not the designer.”
Provide paper, pens, pencils, or other materials Participants should:
participants will need to sketch. Make it quick and • Point out problems – ideas that won’t work for the target users and product goals
easy to participate.
• Point out great ideas - those ideal for the product's target users
Ask participants to sketch their ideas in advance of
• Recognize new ideas: ideas that come from seeing other’s good ideas, or discussing
the workshop. Tell them to spend no more than an
alternatives to less perfect ideas
hour sketching their solution ideas. -OR- Plan on
giving participants time to sketch during that During the discussion the facilitator captures feedback. Try writing a single idea per sticky
workshop. note. This makes them easier to organize later on.
Watch time. Try to spend only a few minutes per discussion.

Organize the outcomes:

Cluster ideas that are similar together. Watch out for conflicting ideas – ideas that don’t
work well if used together.
Vote on best ideas.

Wrap up & celebrate:

Photograph the output from the session.
Take a short (5 minutes or so) movie of someone explaining the workshop results.
Collect takeaways: go around the room asking each participant to say one thing they got
out of the day.

3 Synthesize
& Design
Those responsible for the final design pull the ideas together
and create a more detailed design sketch synthesizing the
best ideas where possible, and avoiding the problems.
Communicate the design to the rest of the team, along with
thanks for participating.

©2013,
© 2014, Jeff Patton
Comakers • www.jpattonassociates.com
LLC, www.comakewith.us
14. Map and Envision Solutions with a Story Map
Map your product solution
Mapping a solution forces you to imagine your users’ world later, after you’ve released the
solution. Imagine and map how the solution fits into their world.

What will they do with your solution?

How does it address problems they have today?

Create a simple storyboard sketch

Start by using sketching templates to sketch a step-by-step flow of your product idea.
For software solutions, you can sketch screens. But you could also sketch experience from a
user’s perspective as a design comic. This works particularly well for service solutions.

A story map with context illustrations by Josh Seiden & Demian Repucci

Form a Hypothesis 63
 A couple frames from a design comic created by Atlassian

Screen shots from the University of Pittsburgh’s “My Pitt” video prototype:
https://vimeo.com/17887994

Create a solution map that combines words and pictures

Use the sketches you’ve created to help identify user’s tasks when using the software.
Once you’ve got the basic flow completed, play “whatabout”:
§ What other ways might the user go about reaching their goals?
§ What happens when things go wrong?
§ How else might we help our target user enjoy the product even more?
§ What are behind the scenes technical things our system will need to do?
Write story names on sticky notes for each detail you add.

Team members in a classroom beginning to add stories to their storyboard sketch

64 Form a Hypothesis
15. Identify Small Successful Product Releases
Identify a minimum viable product release hypothesis
What subset of your solution idea do you believe is necessary to achieve your target outcome?
Recall in section 6, in the HBR article, “The Big Lie of Strategic Planning”, Roger Martin distills
strategy down to 2 simple questions:

1. Where will you play?

What market are you currently focusing on? The sharper the focus, the clearer the
strategy.

2. How will you win?

What solutions will you offer this market that are better than other options it has
today?
One simple way to identify a focused minimum viable product release is to choose a target
market for your product – a specific type of customer and users. Within that target market, you
could further refine your focus by choosing specific jobs or activities you’ll focus on.
In a story map, slice your map based on your choice of target market.

MVP
Target
market &
outcome
Outcome-
centric
roadmap

Articulate your hypothesis

Try using this template as a starting point:

We believe that
[these customers or users] have [this problem or need],
And if we build/make [this solution/feature/capability]
they will [observable and ideally measurable behavior]
Resulting in [measurable business benefit]

Form a Hypothesis 65
 Build roadmaps organized around target outcomes
For each release in the roadmap, discuss what will happen with the next release if the prior
release doesn’t achieve its desired outcome.
For each release in your roadmap give the release:
o A simple name for the release
o Your releases intent or purpose
o A target audience
o A high-level description of functionality
o Metrics you’ll use to evaluate after release
o The size or target date of your release
o Your plan for measuring AND talking with customers and users after
release to evaluate product outcomes

Decide to continue discovery or start delivery

How confident are you that you’ll get your outcome if you proceed directly to development?
If you’re very confident, proceed to creating a development plan.
If you believe there’s significant risk that customers will value your product, that you can design
something usable, or that your ideas are technically feasible, then invest time into validating your
product hypothesis.

66 Form a Hypothesis
Respond with a Test
16. Identify & Design Tests
Concisely identify your product hypothesis and the assumptions
embedded in it. Use the riskiest assumptions to help you identify
your next product test.
If you believe you’ve got a customer with a problem or need you can address, and a great
solution that will help them and your business move forward, then the next thing you need to do
is to put on your negative thinking hat. It’s usually our confidence, or bias, that’s really our
biggest risk.

You’ll need to be deliberate about exposing risks,

assumptions, and questions and then identifying fast
ways to learn and test them.
Iteratively testing your hypotheses will also help you refine your product design.

We’re focusing on the “build” part of Lean Startup’s Build-

Measure-Learn cycle

We’ll step through the basics of these 5 steps

1. Refine your hypothesis
2. Create or revisit your learning backlog
3. Prioritize risks and assumptions to identify the next most important thing to learn
4. Identify options that will allow you to learn fast
5. Select the options that allows you to learn with the least amount of effort, and plan
your next best test

Respond with a Test 67

 Step 1. Refine your hypothesis
Your hypothesis includes:
§ everything you believe about your customers and users and their needs and
challenges,
§ the solution you think they’ll want and how it looks and behaves,
§ how you believe they’ll used it to get benefit, and
§ how their use of your product ultimately impacts your organization.
That’s a lot.
You’ll usually represent it with lots of visualizations like personas, journey maps, UI wireframes,
and anything else that helps you visualize and build shared understanding in your team.

Use a simple hypothesis statement to distill your

beliefs, and help focus your next iteration around the
validated learning cycle.
Try using this template as a starting point:

We believe that
[these customers or users] have [this problem or need],
And if we build/make [this solution/feature/capability]
they will [observable and ideally measurable behavior]
Resulting in [measurable business benefit]
Wrapped up in the “solution name” part are lots of conversations, sketches, prototypes, and past
experience. But, your team will know what you mean when you write it.

Expect your hypothesis to evolve as you run tests. If it’s

not changing then there’s a good chance you’re not
learning, or you’re fooling yourself.
Your hypothesis includes both problem and solution
In a traditional design process, we’d use deep research to inform our design ideas, and then
validate those design ideas.

In an iterative, Lean Startup influenced process we leverage prior experience, insight, and
assumptions to arrive at our solution hypothesis. Our tests usually have two sides: the first seeks
to validate assumptions we’ve made about our users, the second seeks to validate assumptions
we’ve made about our solution.

68 Respond with a Test

If you’ve been designing for a long time, this approach may seem risky. You might be concerned
that if you interview or observe users when you have a solution in your mind, it’ll inject lots of
bias into what you see or ask them. And, if you’re worried about that, you’d be right. That’s why
when using this approach, we’re deliberate about designing our interview plans and approach to
testing solutions, not to prove we’re right, but to prove we’re wrong. The mantra from people
who do this well is:

Design like you’re right, test like you’re wrong.

The rest of this section will help you test like you’re wrong.

Step 2: Build a learning backlog: identify assumptions, risks, and

questions
The learning backlog is filled with everything that stops you from being confident your solutions
will be a success. It includes:
§ Assumptions
§ Risks
§ Open Questions
You may have a list of these already if you’ve already been around the validated learning loop a
few times. If not, you’ll start from scratch.
To find assumptions ask yourself these questions:

What must be true about our customers, our users, and

our solution for our idea to be successful?
What must happen after our solution is released for it to
be successful?
Sometimes my head works better when I think of risks. A risk is the other side of an assumption.
That is where an assumption might be that your users want your solution, a risk is that they don’t.
Ask yourself:

Why won’t this solution work?

What might go wrong after we release this solution that
will make it unsuccessful?
Brainstorming risks is sometimes called a “Pre-Mortem.” When conducting a pre-mortem,
imagine your product did release and it went horribly wrong. Ask yourself:

“What were the bad things that happened after release

that killed our solution?”
Respond with a Test 69
 Finally, look for open questions:

What open questions do we need to answer before we

commit to building this solution?
Sources for risks, assumptions, and questions
Consider these sources for assumptions and risk – and any others you can think of:

About your customers & users:

§ Problems, pains: do they have the challenges you believe they do?
§ Joys, rewards: Are they delighted by the things you think they are?
§ Activities, uses: Do they engage in the activities you think they do? How often?
When? Where?

About your solution:

§ Value to your customer: Do they recognize your idea as a solution to their challenge?
Can they imagine getting value from it?
§ Usable: Will your customers and users be able to easily use the solution to solve their
problems? Can they incorporate it into their work practice today?
§ Feasible: Does your solution use technology that’s available? Affordable for you to
build, and your customers to buy?

About stakeholders or regulatory compliance:

§ Does your legal department see any challenges with your idea?
§ Is there impact on operations? Customer service? Support? Sales? Marketing?
§ Do business stakeholders see it as aligned with the organization’s vision and strategy?

Brainstorm assumption as a list of sticky notes. Remember: Think-write-say-place.

Cluster your stickies and distill them as necessary.

Step 3: Prioritize risks and assumptions to identify the next most

important thing to learn
What assumptions, if proven false, will invalidate your hypothesis? Look for the big assumptions
that if proven false, topple other assumptions. For example, if users don’t value your solution,
usability won’t matter much. Look for assumptions that you’re not certain about – where it’s easy
to imagine you could be wrong.
What risks will sink your product idea? What are the biggest risks? What are the most likely?
If you brainstormed assumptions and risks on sticky notes, you could try ranking them. Put those
that worry you the most at the top.

70 Respond with a Test

You could also try dot-voting where everyone in a group gets 3-5 votes to choose the risks or
assumptions that worry them the most.

Try this 2x2 matrix to prioritize

Use the top-to-bottom axis for likelihood. For assumptions, the likelihood you’re wrong. For risks,
the likelihood of the risk being real.
Use the left-to-right axis for severity. All the
way to the right means that if this happens,
it’ll kill your solution. Farther to the left means
if it were to happen, you can think of ways to
recover from it without pulling your product
off the market, or your new feature out of the
product.
Like all these 2x2 matrices, it’s the quadrant in
the top right you’ll need to worry most about.
And, those things at the bottom left you
probably shouldn’t pay much attention to.
Choose the riskiest assumption – which could
be assumptions or risks. Sometimes a few are
clustered together because they seem
related. You could consider these one big risky
assumption.

Convert your biggest assumption or risk into a question.

For example if your biggest risk is that your customers won’t buy the solution, reframe that as a
question like: “Will customers buy this solution?”

Step 4: Identify options that will allow you to learn fast

Take your riskiest assumption, or a few
related assumptions and brainstorm ways
you could test them – ways you could
prove these are facts and not
assumptions. Remember that
brainstorming isn’t about finding great
ideas, it’s about finding lots of ideas.
Great comes later.
Try brainstorming in rounds. Take a bit of
silent time to brainstorm individually and
then ask everyone to share-out with the group. Combine, refine, and build on your best ideas.

Build up a toolbox of test ideas

It’s coming up with test ideas where your skills as a product discovery team will shine… or not.
You’ve got a lot of choices for ways to test. And the best teams continuously invent new ideas
and approaches.
Thinking of the type of question you’re asking will help you identify different approaches to
testing. Here are a few ideas, organized by question:

Do we really understand our customers and users? Their problems and needs?
§ Interview users to learn about their challenges and goals today
§ Observe how users solve the problems today with a competitive solution
§ Survey users to ask them specific questions about their habits and preferences

Respond with a Test 71

 Do customers want our solution?
§ Tell a story about how a solution might work and get their reaction
§ Show a simple paper prototype and get their reaction
§ Advertise, or “pitch” the solution and check the response rate (sometimes called a
landing page test)
§ Place a button or access to a feature in the product without actually building the
feature (sometimes called a 404 test or feature-fake)

Can users easily learn to use the solution? Easily incorporate it into their lives
or work?
§ Have users perform a task using a simple paper prototype
§ Raise the fidelity of your prototype to make it more realistic
§ Raise the fidelity of your prototype to incorporate real user data
§ Have users do their work in a more sophisticated live-data prototype
§ Use a “Wizard of Oz” approach to fake parts of the functionality by using you and your
team to do them manually behind the scenes

Can we build it predictably using the technology we have today?

§ Build technical prototypes that explore technical constraints
§ Gather data on possible technical approaches
§ Explore and test your current code base to learn about its limitations

Consider other ways to find users to work with, and other ways
to work with them
Consider alternative ways to find users or test
§ Face-to-face – bring users to you or meet them in a coffee shop or conference room
§ Face-to-face on site intercepts – go to where your users will likely use your product
§ Remote intercepts – use tools like ethn.io to intercept customers using a live website
§ Remote – use a conference call and screen sharing tool to show prototypes
§ Remote asynchronous – use email to have a discussion with customers, or tools like
Usertesting.com to test a prototype remotely and get data back
§ Ask sales or customer service to connect you with your current customers and users
§ Broadcast a request via social media – Facebook or twitter may be a good way to find
people fast
§ Friends and family, or even better, friend of friends. Try asking people at your
company if they know someone who matches your target customers or users.

Co-create with your users to learn about problems and solutions

§ Use collaborative workshops like those found in Innovation Games, or Gamestorming
§ Create a journey map with your customers to explore the way they work today
Take a bit of time to research online what others have done. Teams continue to discover novel
ways to find users and test some very tough-to-test assumptions.

72 Respond with a Test

Step 5: Select the options that allows you to learn with the least
amount of effort, and plan your next best test
Now it’s time choose your next best test or two.
You could just talk about it and choose one, but
my favorite approach is yet another 2x2 matrix.
Use the top-to-bottom access for the “quality of
data.” An A/B test on your current commercial
website can give you highly reliable data. A paper
prototype shown to a few users will give you
some data, but it won’t be as much – and the
quality of data may be lower if the fidelity of your
prototype is lower.
Use the left-to-right axis for speed and cost where
the fastest-cheapest approaches are all the way to the right. An A/B test released into a
production environment may take a little time to execute and collect data. But, a paper prototype
could be super-fast.
The top right quadrant of this model can be pretty lonely. We’ll get fast and cheap usually at the
expense of quality of evidence. But, if you have ideas that are fast and cheap, and get you the
data you need, jump on them!
You’ll find that over time your experiments become a bit more time consuming because you’ll be
tackling tougher problems.

Define and plan the details of your next best test

To move forward you’ll need to sharpen your definition of your assumption. You’ll need to
describe how you’ll test, how you’ll collect data, and exactly how you’ll determine when the test
is done.

A test is done when you create it, run it, and have
collected enough data to determine if your assumption
is or isn’t valid.
In Alex Osterwalder’s book, “Value Proposition Design”, he describes this simple template for
distilling a candidate test idea:

Watch Alex’s video here: https://www.youtube.com/watch?v=cW46ySJmLD8

Respond with a Test 73

 If you move forward you’ll need to identify the work you’ll need to do to create and run the test –
work like:
§ Create an interview plan
§ Find users
§ Design the UI for a prototype
§ Create a prototype
§ Collect metrics
§ Interview users
§ Distill results from interviews
These are tasks your discovery team will need to perform to actually run this test. And, these are
tasks where you might ask for help from your whole team.

Rely on your core product team and your whole product

team to help create and run tests.
Scale your approach to testing as your evidence and confidence
increases
In Giff Constable’s books Talking to Humans, and Testing with Humans you’ll find a simple chart
that shows how increasing the time and money we spend to test increases the quality of
evidence. It looks a little like this:
So, if you want the very best evidence, then
you should spend a lot. In fact, you’ll get
absolutely conclusive evidence that your
hypothesis was valid if you build and ship
scalable software to all your customers.
But, you’ll also risk the most.

Building and shipping

scalable shippable
software to all your
customers risks both
money and reputation.
You as a product team, and your organization must ask yourselves “How confident are we that
we’re right?” and “How much money and customer good will are we willing to risk?”

To use Constable’s Truth Curve, I like adding these additions:

Consider the vertical axis confidence.
Asking “how confident are you?” isn’t always useful.. some people are very confident without
having much evidence at all. Let’s also ask ourselves and others to read the hypothesis statement,
and ask yourself: “What would you be willing to bet that you’re right?” The choices here are
things like:
§ Lunch
§ A day’s pay
§ A weeklong vacation
§ Your car
§ Your house
§ Your job
§ Your right arm

74 Respond with a Test

And finally, let’s give ourselves a little wiggle room and widen Constable’s curve to give us a larger
safe zone. That’ll make it easier to hit.
Now Constable’s Curve looks something like this:

Now here’s how you use the curve. Evaluate what you’d bet on the vertical axis, then follow that
to the right until you hit Constable’s curve. That’s about how much money and time you should
be spending to test your idea.
If you’re currently building scalable shippable software, but you’d be hesitant to bet a day’s pay
that your hypothesis would work, than that puts you well below the curve. Let’s label this area
the “stupid zone” – because it’s stupid to risk lots of time and money on something you’re not
confident in.
I think we’ve all worked on teams and on projects where if someone asked you if this was a good
idea you thought to yourself “no way.” Let’s stop doing that. Let’s expose our risk and uncertainty
and try to stay in the “safe zone.”

Don’t build production software when you’re not

confident you’ll get the outcome you expect.
Don’t overspend to learn.

Respond with a Test 75

 Right-Fi Prototypes
A test is often, but not always, a prototype. When talking about prototypes, Bill Buxton, author of
“Sketching the User Experience”, said:

“The difference between a high fidelity

and low fidelity prototype is stupid;
there’s only right fidelity, and wrong
fidelity.”

-- Bill Buxton, author of Sketching the User Experience

Creating tests is an exercise in finding right-fi.
You’ll recognize this as an application of the concept in Constable’s curve.
The best product teams know how to do the least possible to learn the most possible. The worst,
make the assumption they must build fully functional prototypes, or worse, move directly to
shipping software.

Tests scale over time

You’ll iteratively create and run test tackling one or a few risky assumptions each time. Each test
you conduct will likely change your solution hypothesis. Stop testing when you believe the risks
are low enough that building a commercial grade product is a good bet.
§ In very early discovery, your riskiest assumptions may be that users truly have the
challenge you think they do. An interview and observation plan could be the best first
MVP Test.
§ During active discovery you’ll likely be using a combination of interviewing and
gathering feedback on prototypes that range from simple paper to higher fidelity
electronic prototypes.
§ Later, when you’re confident you know who users are and what their challenges are,
and they’ve seen and like prototypes you’ve shown them, then your next best MVP test
might be a working version of your product that Customer Development Partners can
put to use. From this you’ll learn if the decisions you’ve made about that product are
accurate, and whether users can really put the product into use.
You’ll find the ratio of time spent on validating the problem to time spent validating the solution
changes over time, too. This is a natural side effect of your biggest risks shifting from getting the
problem right to getting the solution right.

76 Respond with a Test

Paper Prototyping &
Lightweight User Testing
Use pencil, pens, card stock, scissors, and double-sided repositionable tape to build a user
interface prototype that users can operate just like they would the real software – with a little
help from someone playing the role of the computer.

Why?
Sketching user interface on paper, a whiteboard, or using a computer tool can leave you with
a user interface design that fools the designer. The design may look good, and users and
customers may say they like it, but when it’s built and someone sits down to use it they find it’s
missing critical elements or it’s confusing to use.
Creating something simple that can simulate use allows you to validate your UI ideas,
and iteratively fix and improve your UI design.
Asking users or customers to evaluate user interface that looks polished may lead them to
believe that many of the decisions have been well thought through. They’re often reluctant
to point out problems if they perceive them to be minor.
Presenting users with a UI design rich with colors, fonts, icons, and pictures focuses their
attention on these visual design elements and results in lots of critique on font and color
choices while the designer may be looking for feedback on the functionality and screen flow.
Create a prototype that focuses attention on the elements you wish to validate. If it’s not
time to validate visual design choices, keep the prototype rough enough that users focus

Cooking Up a Useful User on functionality and flow.

Interface Design
Start by choosing a task or set of tasks your user wishes to accomplish with your product.
Now, think of the last time you cooked from a recipe book. The recipe was nicely laid out with a list of
ingredients on the top, and some handy instructions below. If you cook like I do then you rifled through
your refrigerator and pantry to find all the ingredients and placed them on your kitchen counter. As you
proceeded through the instructions, you reached for various tools in our kitchen. You may have turned
on your oven because the recipe indicated a baking temperature. You may have found a measuring
cup, a mixing bowl, and spoon because the recipe told you to mix up 1 cup of flour and 1 cup of sugar.
The instructions may not always say explicitly what sort of tool you need, but it was easy to figure out.
Cooking up UI design works in a similar way.

1 Start with a narrative

Choose a task or set of tasks your user wishes to perform
using your product to reach a goal.
Write a narrative: some written description of the things
the user does to reach their goal. Writing a narrative, user
scenario, use case, or simple story in prose that imagines
at a high level what your user would do in your UI is your
first act of user interface design.

2 Identify UI ingredients
and tools
Step through your narrative sentence by sentence. Where the narrative calls for
the user to view something on the screen, note down on paper or a post-it the
information your UI will need to have.
For example a narrative containing the text: John sees a list of the most recent
CDs would, after a little thought, result in me writing down: list of CDs then in
bullets under that: CD title, cover photo, artist, release date, and price – because
those would be the things John might expect to see in an on-line music store,
right?
A next sentence might read: John clicks 'add to my shopping cart.' I add to my
list of tools: add to shopping cart button because John will need that button.

3 Draw, cut out, and organize

ingredients and tools on paper
Now that you’ve got all your ingredients identified, step through each one, draw it on card
stock, cut it out, and organize it with the others on another piece of card stock that will be
your screen.
Use repositionable double-stick tape so you can easily change your lay out and later, when it
comes time to simulate use, bring it to life.
Use this simple approach to cook up user interface design and you’ll always end up with a
user interface that at least supports the narrative you imagined. If you stick to the recipe,
you’ll find your UI won’t be cluttered by all those unnecessary bits of flashy stuff people throw
in without considering exactly who needs them and when. The result is simple, useful, user
interface that’s ready for lightweight usability testing.

©©2014,
2013, Comakers LLC, www.comakewith.us
Jeff Patton • www.jpattonassociates.com
Validating your user interface
with lightweight user testing
Use a user interface prototype made of paper, or built electronically, that allows your users
to simulate using the product to complete tasks and reach their goal.
Ask users to perform tasks then observe them as they do without instructing them. Record
problems you observe your users encountering. After the test change your prototype to fix
problems and then repeat testing with a different user to see if the problem is repaired.

Why?
As user interface designers, we often know too much about a UI design to be objective.
It’s difficult to predict how users will interpret information and controls on software user
interface, and how they’ll act on it to reach their goals. Observing as someone attempts
to use your product helps quickly identify issues with your design that stop users from easily
learning it, and effectively using it.

Planning a lightweight user test

1. Identify the user tasks you wish to focus on
What would you like to learn about your product’s design? Choose the user goals and tasks they’ll likely
perform to reach them.
2. Create your prototype to support those tasks
Prepare your prototype with these tasks in mind. Since it’s a prototype, you likely won’t have created the
whole product. Just make sure the stuff the user is likely to need is ready.
Fabricate good data. Showing silly or unlikely data in a prototype can be really distracting for a user.
Creating data that looks correct will result in them quickly engaging with the prototype.
3. Identify your test team
To test, you’ll need participants to act as:
• facilitator: to lead the test
• computer: to operate the paper prototype as if it were real working software
• observers: to sit quietly, pay close attention, and record notes as subjects use the prototype.

4. Find appropriate test subjects

In early stages of design your prototype will be rough. Find equally rough test subjects quickly. Grab a co-
worker or friend.
In later stages after the UI has had some validation and is more mature, find test subjects that more closely
match your target users.

Conducting a simple user test

1. Welcome your user
Thank them for coming and remind him or her that: "It’s the prototype that’s being tested, not
you." Users often feel embarrassed when they can’t figure out the software, even at early stages.

2. Set the stage

Verbally place the user in some context where they’d need to use the software. Supply them
with a specific task to perform, and any other context they’ll need to succeed.
“You’re in a music store and you don’t have much time. You’re looking for a used copy of AC/
DC’s Back in Black CD. You see an information Kiosk just as you walk in that looks like this.”
3. Begin the test
Ask your user to think out loud, to explain what they see and what they intend to do as they use
the software.
4. Keep information flowing
If you’re the facilitator help keep information flowing by asking questions like: “Tell me about the
information you see on this screen” or “before you click that button, can you tell me what you
expect to happen?”

5. Course correct if necessary

If your test subject gets hopelessly stuck, or wanders way out of bounds, it’s OK to course correct.
Organize
observations & fix
Let the user know that the UI has some problems we’ll need to take care of and we’ll skip past
this particularly rough part. Move the prototype to jump a bit past where your user is stuck, give
them a bit of context, and ask them to continue from there.

6. Conclude the test and invite questions

Once the user has accomplished their goal you can congratulate them and let them know the
test part is over. Ask the observers if they have any questions at this time. Ask the participant if
they have any. It’s a good time to do a bit of an interview with the participant to get their
your prototype
evaluation of the UI.
1. Discuss and organize your observations
7. Thank your user
2. Make changes to address problems
If your user came from outside your organization, it’s common to give a gift of thanks like a gift
certificate for a favorite online bookstore. 3. Test again with a new user
17. Use a Lean Canvas to Distill Hypotheses and
Identify Your Next Test
Jeff Gothelf’s Lean Canvas
Jeff Gothelf’s Lean Canvas
combines the essentials of the
Opportunity Canvas with the
structure to help you clearly
articulate your hypothesis and
find your next best test.
This canvas codifies the process
Jeff Gothelf and Josh Seiden first
introduced in Lean UX. Use this
process to help your team frame
your work as a business problem
to solve (rather than a solution to
implement) and then dissect that
business problem into its core
assumptions. Then weave those assumptions into hypotheses. Finally, design experiments to test
your riskiest hypotheses.
Download it at: : www.jeffgothelf.com/blog/leanuxcanvas
Like all canvases, there’s a suggested order to working through it. But, you should feel free to fill
it out in any order that makes sense, or change it to suit your needs.

1. Business Problem 6. Hypotheses

What business have you identified that needs Combine the assumptions from 2, 3, 4 & 5
help? into the following template hypothesis
statement:
2. Business Outcomes “We believe that [business outcome] will be
(Changes in customer behavior) achieved if [user] attains [benefit] with
What changes in customer behavior will [feature].”
indicate you have solved a real problem in a
Each hypothesis should focus on one feature.
way that adds value to your customers?

3. Users & Customers 7. What’s the most important thing

What types of users and customers should we need to learn first?
you focus on first? For each hypothesis, identify the riskiest
assumption. This is the assumption that will
4. User Benefits cause the entire idea to fail if it’s wrong.
What are the goals your users are trying to
achieve? What is motivating them to seek out 8. What’s the least amount of work
your solution? (e.g., do better at my job OR we need to do to learn the next
get a promotion) most important thing?
Brainstorm the types of experiments you can
5. Solution ideas
run to learn whether your riskiest assumption
List product, feature, or enhancement ideas
is true or false.
that help your target audience achieve the
benefits they’re seeking.

Respond with a Test 79

 18. Interview and Test to Gain Empathy and Insight
Use customer and user interviews to build empathy with customers
and users, to test assumptions about your users and your solutions,
and to identify key insights that’ll help you build a better solution
Use customer and user interviews to understand your users’
joys and rewards that motivate them, and the pains and
frustrations that hold them back. Your goal is to look for
insights that lead you to new problems you could solve, or
new ways you could delight potential customers.

It’s a conversation, not an

interrogation
Your interview should feel like chatting with a friend.
The best interview questions don’t actually sound like questions. Rather, they’re requests for
your interviewee to tell you about the last time they did something, or a time when it went well,
or went poorly.

Plan your interview

To plan your interview, start with a list of what you want to learn:
§ What do you believe is true that you’d like to validate?
§ What questions would you like answered?
§ What do you need to learn more about to better understand the people that might use
your product?
Given what you need to learn, what stories or experiences can you ask your interviewees? It’s
through listening to these stories that you’ll really get the answers to your questions.

Directly asking your users what you want to know often

results in a leading question.
Asking directly for the information you want often results in a leading question that doesn’t really
get you the information you want. For example, if you believe it’s challenging for people to use
your current product, and you want to know why, you may be tempted to ask:
“What makes our current product challenging to use?”
While that seems sensible, your interviewee will do their best to oblige and work hard to think of
challenging things. But, in fact they may not believe it’s all that challenging. And, the parts that
really are challenging they may have come to accept as necessary complexity.
Better questions might be:
“Tell me about the last time you used our product.”
“Tell me about a time the product really helped you.”
“Tell me about when the product really got in the way.”
The recent, best, and worst stories are easier to recall for your interviewee. And, out of them
you’ll learn what really happened and not just what was challenging, but why.

Plan for a 2-part interview

In an iterative, Lean Startup influenced process we leverage prior experience, insight, and
assumptions to arrive at our solution hypothesis. In interactions with our customers we interview

80 Respond with a Test

and observe to validate customer and user hypotheses, and then elicit feedback on our solution
ideas to validate solution hypotheses.
Confirmation bias is unavoidable. But knowing that helps you deliberately acknowledge it in your
testing strategy.

Be deliberate about trying to disprove your

assumptions.
What questions could you ask to prove your solution won’t work, or to prove users don’t have
the challenges you think they do?

Create prototypes or examples

Design a prototype or example you could get feedback on that would initially help you validate
your value proposition. Focus on the key areas that will help your users imagine the value they’ll
get.
Hint: It won't be a log in screen.
Prototype your solution: Construct a simple paper prototype, or use a simple prototyping tool to
create a prototype.
Proto.io: Use Proto.io for simple, fast tap-able iOS and Android prototypes
inVision: Use inVision to create simple clickable web and mobile apps:
http://www.invisionapp.com/
Describe your solution: Create a simple storyboard or design comic that helps you more tangibly
describe your solution. Or, create a landing page or promotional material that pitches your
solution. These will help you test the value proposition.
Instapage: Use Instapage to design a simple, measurable landing page:
http://www.instapage.com/

Plan to ask for data you can use more objectively:

§ On a scale of 1-10, how likely are you to try this product?
§ Prepare a list of 20 or so good and bad adjectives. Ask your customer to choose 3 that
describe their impressions of the solution.
§ Can we take your name and email address to contact you when our beta program
begins?
§ Can we take your credit card information to sign you up now?

Build your plan collaboratively

My favorite approach to planning interviews is to pair with someone else and together work
through these 2 things:
§ What do I want to learn?
§ What questions or other approaches do I have for learning these things?
Put ideas in 2 columns. Prioritize what you want to learn. Consider multiple approaches to
learning in the interview including:
§ Asking for stories: recents, bests, & worsts
§ Asking them to show you in their current solution
§ Asking them to show you examples of their output

Respond with a Test 81

 During interviews
Record the facts and details.
Record emotions using your users’ own words. These quotes are referred to as verbatims.
Interview in pairs when possible, one to lead discussion, the other to take notes. Trade roles
during the interview.

Tips for better interviews:

o Use open-ended questions to o Ask for an example: “Give me an o Watch and listen for emotion –
steer. example of a time that this that’s a signal that there’s
o Use closed questions to confirm, happened…” potential value to find.
or to change the course of the o Look for a chance to observe: o When they ask for a feature, ask
interview. “Can you show me how you do them the magic question –
o Ask for stories: “Tell me a story that?” “what would you do if you had
about the last time you…” o Ask for highs and lows: “Tell me that?”
about your worst experience…” o Take notes on paper – especially
“Tell be about your best verbatim quotes.
experience…”

Interview and test face-to-face

Early in discovery the fastest way to build empathy and test your ideas is using face-to-face
interviews. You can use traditional recruiting approaches to find people to interview. Or, if you’re
building a consumer product, go to where you’re likely to find consumers with the right interests,
and “intercept” them.

82 Respond with a Test

Photos courtesy of Kodak

Even remote interviews can feel “face-to-face” when you use cameras and screen sharing tools.

Photos courtesy of Carmax

This team interviews a customer hundreds of miles away, but uses a screen sharing tool to
observe how their user works today, and to have them use and give feedback on a prototype for
the solution they’re working on.

Respond with a Test 83

Simple interview and solution feedback flow
Introduce yourself & Hi, I’m …….. and these are my partners ……, and …….
your team We’re doing some research on [the general topic of the interview] to help us
create a product that’ll help people [do something better].
Introduce your
product We’re really grateful that you agreed to talk to us today. What we learn from you
will really help us create a better product.
Ask questions to Build rapport first by asking for simple examples or stories
understand how Lean in when they speak
your users think and
Make eye contact – don’t focus on your notes, and never record on a computer if
do things today you’re the interviewer
Parrot to build trust, paraphrase to confirm understanding
Don’t be afraid of the “awkward silence.” Be quiet, and the person you’re
speaking with will fill in the space with their thoughts
Be alert for goals, pains, and unmet needs you didn’t anticipate!

Bridge from learning “Thanks, learning about your experience has been really helpful.”
to testing “We’ve been working on some ideas that address some of the problems you’ve
described. We’d like to get your feedback on some of those ideas…”

Test your solution Help your user imagine themselves in front of the product: “Imagine you’re
putting together a shopping list so you can pick up groceries on your way home
from work…”
For early conceptual testing: tell your product or feature’s story from a user’s
perspective. Make the person you’re talking to the main character in the story.
For later usability testing: after placing your user in front of the product, and
giving them a goal, ask them to try using the product to reach their goal.
Get excited to hear things you didn’t want to hear! These are the insights that
lead to you finding and solving the real problem.

Wrap up “Thank you! This has been really helpful for us!”
Invite observers to ask any clarifying questions. If your partners have been
patiently listening and taking notes, they may have questions to ask.
Ask about staying in touch: “As we go back through our notes, we often find we
have other questions. Would you mind if we got back in touch with you later with
those?”
Give the user a small gift: an Amazon, Starbucks, or Visa gift card works great.
Ask for a referral: “Do you know anyone else that you think would be a good
candidate for us to speak to?”

84 Respond with a Test

Investigation Process
planning, carrying out, and making use of user research
Directly observing and interviewing is the best way to learn about

2
Interview
potential users of your product.
Pay attention to what they do say, and what they don't say.

Find the discomfort

You’re looking for situations where your users have begun to tolerate the pain
you perceive. If you solve these problems, you’ve got a chance of changing Prepare for each interview
their lives Have a notebook ready – ideally the one you’ve been using for all your interviews
Where are the workarounds? Cheat sheets, slips of paper, reminders, pages from Keep your interview focus close by and visible for reference during the interview
training manuals,
Record the name of your interview subject, the date, the time, and any other
Find the clever invention, or workaround interesting details about the location
This is your best clue about where your product opportunity might be.
Being there is the best way to identify it.
Go to where the action is
A good cop or reporter will always go to the scene of the crime. You should, too.

1
Interview people “in-context” – that is the place where they’d normally engage in

Plan
the activity. For someone working in an office, talk to them at their desk where they
normally work. For a consumer making a car-buying decision, hop in the car and visit
the dealership together.
This is a key characteristic of a research approach called Contextual Inquiry
Agree on your focus Be an apprentice
It’s essential to have a focus for your interviews in
Sit with someone as they engage in an activity. Act as though you were an
order to produce coherent findings
apprentice.
▪ What activities do you want to understand?
Carry out an apprenticeship interview in the context where your interviewee does her
▪ What aspects in particular do you need to learn about? work. Work with the same software, handle the same forms, listen in on the same
▪ What information do you need specifically to clarify a phone calls.
question you have or to support your design efforts? While watching someone work, pay close attention to what they do without
This focus should be something you can share with the mentioning it. Experts often do many of there actions automatically, without
interviewee - “We are interested in learning [________]” conscious attention. Be on the lookout for difficulties the person you're interviewing
Write out your focus for reference during the interview has learned to live with.
Pay close attention to
experts. Watch what
Go low-tech they do while you listen
He's acting as an to what they say
Keep a notebook for taking notes.
apprentice being shown
Notebooks never run out of power.
how the work is done
Record audio if you like, but ask permission.
However, it’s unlikely you’ll ever have time
to listen to it later. What to record
Use computers with caution. Even if you type fast, Your hand should hurt at the end of the interview
interacting with the computer prevents you from interacting from the amount you have written. You should be writing
with the participant. It’s impersonal and makes participants constantly. Try to stay factual - the time for interpretation is in the analysis phase after
more aware that what they say is being recorded. the interview is done (think: would I feel happy showing these notes to the
tip: try using a
interviewee?).
single notebook
Plan to Interview with a partner with non-
removable
Use your interview subjects words
One person can focus on the conversation while the other pages for the Write down quotes. You can pull data from the quotes, you can’t pull quotes from the
focuses on recording notes. One partner often has his
length of a data. Information, especially emotion, is best conveyed in your users’ own words
“eyes free” to observe – paying attention to body
research don’t write: he was frustrated
language and specific actions interviewees take while the
other focuses on good notes. project do write: he said “I wasted my entire day trying to get this done!”
It takes a while to get a good working rhythm with an

3
interview partner. For instance if you’re both writing the

Synthesize
same notes, then neither of you are paying close attention
to your subject. You also end up with lots of duplicate
notes to reconcile.
Trade-off responsibilities. Switch between holding the
conversation and taking notes. If one partner is struggling to
maintain the conversation, it’s time for the other to jump in.
Immediately review and clean
up your notes
Don’t wait until you’ve run all of your interviews - the process of writing up allows you
to find out what you still need to know. Also, much of the information from the
He's focused on interview will be in your head. Sharing it with others forces you to make it concrete.
listening and
recording Share notes with your team
It’s important to have shared understanding of the visit, and for that to happen
She's deeply quickly. Re-playing the visit cements it in the mind. Each individual will have observed
engaged in different aspects of the same interaction. Sometimes it’s possible to quickly seek
conversation clarification from participants.
Take a photocopy of every team member’s written notes, and file them away. Team
members should have been writing the entire time they were out on the visit. User
Collect evidence quotes, sequence of events, issues observed, etc.
Ask your interviewee if they can show examples of forms, paperwork, or
other information they refer to in conversation. Discuss with your team:
If they discuss a website or software application, pull it up on the screen. ▪ Patterns of behavior

A picture's worth a thousand words ▪ Use of tools

▪ Breakdowns in flow
Draw a sketch or plan of the environment if you are at the interviewee’s
location. Note the location of items/areas that the interviewee refers to in ▪ Disruptions from tools or process
your conversation. ▪ Workarounds
Ask if you can take a photo. Invite them to pose proudly with an item ▪ Do tools get in the way or disappear into background?
you're discussing. ▪ What support artifacts exist?
▪ How is the job learned?
© 2014, Jeff Patton • www.jpattonassociates.com
 Investigation Skills
asking good questions ● observing useful details ● sniffing out opportunities
Conversation,
It took me
ask good questions

literally all day to get this

flight booked!
not Interrogation Every time I got started looking up flights,
I’d get interrupted. Then when I came
A good interview is a conversation – like talking with a friend. So,
back, the website lost all the routes when you came back the website
A bad interview feels more like an interrogation. In addition to being I’d been looking at! made you start your search over? That
very unpleasant for the interviewee or interviewer, it’s not likely to must have been frustrating.
result in interesting or insightful information

Hmm... she’s been

Paraphrase
talking a while, but I’m not When you want to move on, Oh my
getting much detail I’ll ask an open sum up what you’ve heard yes! It really drove
ended question to dive deeper. using your own words. This lets me nuts!
interviewees know that you’ve
That sounds understood them or gives them
really interesting. a chance to correct you.
Can you give me some more details
about the last time you did that?
Watch your altitude Get the info you want
Conversations about experience can be (without leading)
Steer your conversation at a high-level, almost in the clouds, which
Tour: “What does a typical day look like?”
You have specific information to find in a short amount won’t get you enough useful information.
of time. Steer the conversation with the questions you Story: “Tell me about a time when that happened.”
Some conversations can get lost in the
ask. It’s OK to change topics and move on when you Example: “Can you give me an example of...?”
weeds churning up too much detail on
have the information you need. You’ll maximize the
information you get, and help the interview feel like a one area, and failing to get the full story. Exceptions: “Has it [not done what you expected] before?”
real conversation, not an interrogation. Keep track of where you are in your user’s What else: “Is that the only thing that stops you from…”
journey. Pull the conversation up a bit to Expectations: “Was that what you expected?”
Steer with move things along. Dive deeper to collect
open-ended questions important details.
Generalizing: “Does this [problem] happen often?”
Focus: “What does [term] mean here?” / “What would you
“How does that go?” Pull up to move the conversation forward:
call [item]?”
“Can you talk about the last time you….” “So, how did you move forward from
Understanding: “I am hearing you say…”
there?”
Confirm, redirect, or stop conversation with Summary: “So the way that [x] works is confusing, but the idea
Dive to get more detail:
is a good one.”
closed questions “That sounds complicated, can you tell
me more about that?”
“Exactly how long did that take?”
“What was the next step you took?”
Build Empathy
Why focus on empathy?
If you’re new to interviewing, it’s easy
to fall into a trap of just writing down Think of the empathy map below to
what people do and general facts help you pay attention to and ask
about that activity. But, finding key questions about what people think,
insights comes from building empathy. see, say, do, feel, and hear.

Avoid questions that

avoid objectionable questions

Think back to the

last time you booked travel
arrangements... can you tell me
Objection! result in bad information how it went?

It’s not a court of law, but it’s close.

In a court of law, certain lines of questions
just aren’t allowed. We want real information
from our witnesses, not words we put into
In a court of law, the apposing attorney will their mouths, or their guesses, or conjectures.
watch you like a hawk, and shout “objection!” Bad information is misleading and won’t help
Well.. it was
last month when I
if you engage in an improper line of a jury make good decisions. booked my trip to
questioning. This won’t happen in real life. But, Cancun....
if it helps you ask better questions pretend that It won’t help you as a designer make good
it will. decisions either.

Avoid interview objections: Recall a specific event

A witness on the stand is generally asked to discuss a
Leading the witness specific event that they were present for. That’s why
Don’t ask questions that suggest the answer to the they’re a witness. Ask the people you’re interviewing
question. to think back to a specific time they engaged in an
Don’t ask: “Don’t you feel the software you’re using activity and describe that.
today is too slow?” Calling for speculation Don’t ask: “How do you usually purchase an plane
Hmm… the interviewee may not have considered Don’t ask interviewees to guess what happened ticket?”
it slow until you suggested it was. when they weren’t around or how others felt. Do ask: “Think back to the last time you bought a
Do ask: “How do you feel about the speed of the Don’t ask: “When the network is down, how do plane ticket. Can you tell me when that was?” “Start
software you’re using today?” your employees feel?” from the beginning and tell me what you did.”
Prejudicial or inflammatory question Do ask: “Think back to the time when the network
was slow. What kinds of comments did you hear Hearsay
A particularly nasty form of leading is to ask in a
way that makes it embarrassing or confrontational people making?” If you ask your interviewee to repeat information they
for the subject to give their opinion. Calling for conclusion heard from someone who heard it from someone
Don’t ask: ”Do you feel the large amount of time Don’t ask your interviewee to draw conclusions else, you’re not likely to get correct information.
you spend reviewing search results is wasteful?” when they don’t have the knowledge or Don’t ask: “What did your customer service person say
Hmm… if your subject says “no,” is it because experience they’d need. that the angry customer said to them?”
they’re wasteful? Interviewee thinks to self: “This Don’t ask: “Do you think the amount of people on Hmm… you should probably go ask the customer
guy thinks I’m wasteful! “ the network is what makes it so slow?” service person yourself.
Do ask: “Think back to the last time you reviewed Unless you’re talking to the guy responsible for the Do ask: “Are there customer service call logs or email
search results. How do you feel about the time you network administration, the answer to this may not messages we can review to better understand how
spent? Too much?, too little?, or about right?” be very useful. customers might feel?”
 12#Tips#for#Early#Customer#
Development#Interviews##
Revision(3(Published(by(Giff(Constable(on(December(6,(2012(
http://giffconstable.com/2012/12/126tips6for6early6customer6development6interviews6revision63/((
(

1.#One#person#at#a#time# You(might,(however,(run(an(experiment(where(you(
test(the(market,(test(pricing,(and(do(try(to(close(a(
Focus(groups(are(a(groupBthink,(distractionBfilled( sale.(That(is(great,(but(keep(this(part(of(the(
mess.(Avoid(them(and(only(talk(to(one(person(at(a( conversation(separate.(As(with(product(feedback,(
time.(If(desired,(you(can(bring(someone(with(you(to( keep(this(out(of(the(behavior/mindset(portion(of(
take(notes(—(some(UX(designers(like(this(approach.( the(discussion.(
Personally,(I(tend(to(do(oneBonBone(interviews(
because(I(think(people(loosen(up(and(thus(open(up(
a(bit(more,(but(it(can(be(nice(to(have(a(noteBtaker,( 5.#Disarm#“politeness”#training#
which(allows(you(to(focus(entirely(on(the( People(are(trained(not(to(call(your(baby(ugly.(You(
conversation(and(body(language.( need(to(make(them(feel(safe(to(do(this.(Ask(them(
upBfront(to(be(brutally(honest,(and(that(this(is(the(
2.#Know#your#goals#and#questions# very(best(way(they(can(help(you.(If(they(seem(
confused,(explain(that(the(worst(thing(that(could(
ahead#of#time# happen(is(to(build(something(people(didn’t(care(
Have(your(assumptions(and(thus(learning(goals( about.(
prioritized(ahead(of(time.(Decide(who(you(want(to(
talk(to((age,(gender,(location,(profession/industry,( 6.#Ask#open#ended#questions#
affluence,(etc),(and(target(interviewees(accordingly.( Do(not(ask(too(many(yes/no(questions.(For(
Prep(your(basic(flow(and(list(of(questions.(You( example,(minimize(such(questions(as(“do(you(like(
might(veer(off(the(plan(to(follow(your(nose,(which( Groupon?”(Instead(ask(“what(kinds(of(deals(do(you(
is(great,(but(go(in(prepared.( look(for,(if(any?”(“What(motivates(you(to(hunt(for(
deals?”(“How(do(you(discover(deals?”(“Do(you(get(
3.#Separate#behavior#and# frustrated(with(the(deal(sites(out(there?”(

feedback#in#discussion# Sometimes(it(is(hard(not(to(ask(a(yes/no(question,(
Decide(up(front(if(your(focus(is(going(to(be(on( but(always(follow(up(with(an(openBended(question(
learning(a(user’s(behavior(and(mindset,(and/or( like(“why?”(or(“tell(me(more(about(that(
getting(direct(feedback(or(usability(insights(on(a( experience.”(
product(or(mockup.(Do(not(mix(the(two(in(the(
discussion(flow(or(things(will(get(distorted.( 7.#Focus#on#actual#behavior,#not#
Put(“behavior(and(mindset”(first(in(your(discussion( speculative#or#abstract#feelings#
flow.(During(this(part,(don’t(let(the(interviewee(go( To(emphasize(#3:(people(are(not(very(good(at(
too(deep(in(terms(of(suggesting(features,(but(keep( predicting(their(actions,(knowing(what(they(want,(
them(focused(on(if(they(have(a(problem,(how(they( or(knowing(their(true(goals.(Your(job(is(not(to(ask(
think(about(the(problem(space,(and(if(and(how(they( the(person(for(the(solution.(It(is(*your*(job(to(figure(
have(tried(to(solve(it(in(past.( out(the(best(solution,(and(then(validate(that(your(
If(you(want(to(get(feedback(on(a(product,(whether( solution(is(actually(right.(
on(paper(or(digital,(do(this(after(digging(into( People(*love*(to(talk(about(features(and(solutions.(
behavior(and(mindset.( When(you(are(in(learning(mode,(don’t(let(that(
dominate(the(conversation.((Try(to(keep(things(
4.#Get#psyched#to#hear#things#you# factual.(Get(them(to(tell(you(stories(about(how(they(
previously(experienced(a(problem,(if(they(tried(to(
don’t#want#to#hear# solve(it((or(why(not),(and(what(happened.((Get(
If(you(don’t(do(this,(you(might(find(yourself(selling( them(to(tell(you(stories(about(using(other(products(
or(convincing,(or(even(hearing(what(you(want(to( that(are(in(the(same(domain(space.(You(do(want(to(
hear.(This(is(called(“confirmation(bias”(and(we(are( dive(into(their(emotions,(but(you(can(trust(a(
all(very(susceptible(to(it.((Your(initial(goal(should(be(
learning.(
discussion(of(historical(emotions(much(more(than( interesting(results(through(this.(In(the(first,(they(
one(speculating(“what(ifs”.( correct(you(because(you’ve(misinterpreted(what(
they(said.(In(the(second,(by(hearing(their(own(
Some(people(like(to(ask(the(question,(“if(you(could(
thoughts,(they’ll(actually(realize(that(their(true(
wave(a(magic(wand(and(make(this(product(do(
opinion(is(slightly(different,(and(they(will(give(you(a(
whatever(you(want,(what(would(it(
second,(more(sophisticated(answer.(
do.”((Occasionally(interesting(things(can(come(from(
this,(but(I(would(advise(that(you(take(the(answers( Another(approach(is(to(purposefully(misrepresent(
with(a(grain(of(salt.( what(they(just(said(when(you(parrot(it(back,(and(
then(see(if(they(correct(you.(But(use(this(technique(
8.#Listen,#don’t#talk# sparingly,(if(at(all.(
Try(to(shut(up(as(much(as(possible.(Try(to(keep(
your(questions(short(and(unbiased((i.e.(don’t( 11.#Ask#for#introductions#
embed(the(answer(you(want(to(hear(into(the( At(the(end(of(every(interview,(see(if(you(can(get(
question).( leads(to(another(1(to(3(people(to(talk(to.(
Don’t(rush(to(fill(the(“space”(when(the(customer( If(it(is(not(obvious(to(everyone(by(now,(let(me(just(
pauses,(because(they(might(be(thinking(or(have( be(clear(that(you(want(to(avoid(doing(these(
more(to(say.( interviews(with(friends(and(family.(There(are(lots(
of(creative(ways(to(recruit(interviewees((the(tactics(
Make(sure(you(are(learning,(not(selling!((at(least(
vary(depending(on(who(you(need(to(get(to),(but(
not(until(that(part(of(the(conversation,(if(relevant)(
getting(referrals(will(make(the(process(a(lot(easier.(

9.#Follow#your#nose#and#drill# 12.#Write#up#your#notes#as#quickly#
down# as#possible#
Anytime(something(tweaks(your(antenna,(drill(
The(details(behind(a(conversation(fade(fast,(so(if(
down(with(follow(up(questions.(Don’t(be(afraid(to(
you(haven’t(recorded(the(session,(write(up(your(
ask(for(clarifications(and(the(“why”(behind(the(
notes(and(color(commentary(as(soon(as(you(can.(I(
“what”.(You(can(even(try(drilling(into(multiple(
brainBdump(into(a(shared(Google(Doc(so(the(rest(of(
layers(of(“why”((see(“Five(Whys”),(as(long(as(the(
the(team(can(see(it.((Note:(I(typically(have(not(
interviewee(doesn’t(start(getting(annoyed.(
recorded(sessions(for(fear(of(making(interviewees(
more(selfBconscious(or(careful,(but(other(
10.#Parrot#back#or#misrepresent# entrepreneurs(have(said(to(me(that,(while(it(takes(
some(rapportBbuilding(at(the(start,(pretty(soon(
to#confirm# people(forget(about(a(recorder.)(
For(important(topics,(try(repeating(back(what(the(
person(said.(You(can(occasionally(get(one(of(two(

#
Afterwards:#Look#for#patterns#and#apply#judgment#
Customer(development(interviews(will(not(give(you(statistically(significant(data,(but(they(will(give(you(insights(
based(on(patterns.(They(can(be(very(tricky(to(interpret,(because(what(people(say(is(not(always(what(they(do.(
You(need(to(use(your(judgement(to(read(between(the(lines,(to(read(body(language,(to(try(to(understand(context(
and(agendas,(and(to(filter(out(biases(based(on(the(types(of(people(in(your(pool(of(interviewees.(But(it(is(exactly(
the(ability(to(use(human(judgement(based(on(human(connections(that(make(interviews(so(much(more(useful(
than(surveys.(
Ultimately,(you(are(better(off(moving(fast(and(
making(decisions(from(credible(patterns(than(
dithering(about(in(analysis(paralysis.(
(
19. Keep Learning from Each Test Visible
Learn simple practices that help build shared understanding about
what you learned from testing
You’ve conducted your test. Now, it’s time to pull together what you’ve learned, rethink your
assumptions about your customers, and users, and reconsider or redesign your solution.

1. After the interview, make sense of what you’ve learned

Dump and Sort what you’ve learned
After each interview or round of interviews, your team will need to build shared understanding of
what they heard and saw, and what it means to your product. This simple dump-and-sort process
is a good place to start.

Think-write-say-place
Make sure you externalize your observations and ideas. Write it before or as you say it. Avoid
“think-say” or just “say” without thinking.
Think about these things:
§ Observations – they said this, they do this, they use this…
§ Inferences – I think this means…. I think they feel….
§ Ideas: a good solution would be – I think they need this – They said they want this
§ Insights – dependencies, correlations, surprising information, counter-intuitive
observations
Comb through your notes, and write a sticky note for everything that seems important to you.
Say what you’ve learned out loud as you place them on a wall or on a tabletop. Tell stories, and
give more context as you place them.

Cluster and distill

As you and your team members begin to place your stickies, you’ll see common themes emerge.
Cluster them. For each cluster write a distilling statement: a statement that you could read in
place of all the other notes. This statement usually synthesizes the ideas in the cluster of notes.

Respond with a Test 89

 Create an empathy map to organize what you’ve learned
An empathy map is a simple way to organize what you’ve learned from a user’s perspective. Start
with a simple model like the one in the figures below. Think about and add in sticky notes saying
what potential users are:
§ Thinking & feeling about their worries or aspirations?
§ Hearing while using our product, from their friends or boss?
§ Seeing while using our product in their environment?
§ Saying & doing while using our product in public or in private?
§ Experiencing as a pain point or fear when using our product?
§ Experiencing as a positive or gain when using our product?

Look for key insights that’ll help you identify a better solution

Insight: provocative statements about human behavior

expressed as universal truths
-- definition via John Kolka author of Well-Designed: How to Use Empathy to Create
Products People Love

2. Distill what you’ve learned across tests to find changes to

make to your hypothesis
Summarize results in using a Delta-Next 2x2 matrix
Think about what you knew and believed before the
interview and test:

Δ- What did you believe that you no longer believe?

Δ+ What did you learn that you didn’t know before?
? What questions do you now have that you should
take up in your next customer test?
What solution ideas do you have that you’d like to
explore in your next customer test?

90 Respond with a Test

3. Rethink your assumptions
Your personas and journey maps contain your starting assumptions about your users and the
way they reach their goals today. Look back at them now. I promise you that there’s information
in them that you’ll want to change.

Your starting assumptions about users and the way

they work never survive your first test
Adjust your personas and journey map. Or, throw them away if they’re irrelevant. Keeping bad
information displayed will only slow you down.
Look back at your opportunity canvas and adjust your initial assumptions. Expect the problems
you’re solving and your target customers and users to change at least a little. Other things will
change along with them.

4. Refocus
Look back at your hypothesis statement. Is it still correct? It’s likely it could use some refinement
if this is your first iteration.

5. Rethink your solution

How much does what you learned change your solution? You may need to make just a few
changes and refinements. Or, you may want to go back and run a Design Studio session to sketch
a new batch of ideas to work with.
Sketch new ideas, describe your new solution, then design your next prototype or example to
test.

That’s a whole validated learning cycle

Congratulations! You’ve just completed a cycle.
As you continue to iterate, your prototypes will progress
from testing for value to testing for usability, too. As you
become certain you’re on the right track, you should
consider building prototypes to test for feasibility. After
a few iterations, you’ll need to scale up your prototypes
to using code and live data.
When you’re pretty confident you’ve got a winner, build
a backlog and begin building a production ready
solution.

Kill your hypotheses?

If too many assumptions are invalid, you may find you need to choose a completely different
solution, a different customer, or a different problem to solve. That’s a pivot.

Respond with a Test 91

 20. Release to Learn Before You Release to Earn
Understand how you might plan delivery as a series of releases
targeted at getting value from learning, and from the benefits you’ll
see from adoption and use.

Early tests aren’t software at all

If you believe you know what you should build it’s time to look hard at the assumptions you’re
making about your users and the outcomes you expect to observe after shipping your solution.
How risky are those assumptions? If you’re wrong will it make you wish you wouldn’t have built
software at all?
We won’t discuss MVP Testing strategies in this workshop, but remember:

Early MVP Tests aren’t about building software.

The best MVP tests may be one or all of practices like user interviews, prototypes at various
fidelity levels, and other clever approaches that may or may not involve software.

Last-best tests are software we build to learn

Sometimes the only way to be confident your solution is fit for your customers is to see them
using it. But, we don’t want to ship less-than-viable solutions to all our customers and cross our
fingers. We’ll use a small closed group of Customer Development Partners that fit an “early
adopter” profile. These customers will do more than try out our product. They’ll put it to use and
give us feedback. We’ll use that feedback to “iterate until awesome.” Then we’ll ship it to our
whole customer base.

Choose customer development partners that match an

early adopter profile.
Cultivate a pool of customer development partners. Good partners are customers that fit an early
adopter profile. They’ll be willing to use a less than perfect product and to give you frequent
feedback.

Find minimum and viable by shipping less than viable

It may seem counter intuitive to release something that you know isn’t ideal to some of your
most valuable customers, but it’s one of the fastest ways to learn what really is minimum and
viable.

92 Respond with a Test

 MVP?
*"Artwork"and"concept"described"by"Henrik"Kniberg somewhere
around here

Eric from Liquidnet describes his strategy for finding minimum and viable.

When shipping a release to customer development

partners, target outcomes are focused on learning and
not adoption or growth

Respond with a Test 93

 Respond at Scale
21. Create a Development Strategy to Minimize
Development Risks
Understand iterative and incremental development and how to
organize work to maximize learning and reduce risk
Once you’ve decided what should go in a product release, it’s time to break that down into
smaller parts that can be delivered iteratively and incrementally. Use development strategies that
mitigate risk and help you learn faster.

Use an iterative and incremental development approach

Incremental-only thinking builds software the way a bricklayer builds a wall:

Incrementing calls for a fully

A more iterative allows you to
formed idea.
move from vague idea to
And, doing it on time requires realization making course
dead accurate estimation. corrections as you go.

1 2 3 4 5 1 2 3 4 5

Iterative and incremental thinking builds enough of the whole to see the big picture then
incrementally adds more, while iteratively improving as you learn.

Create a development strategy that maximizes learning

Given confidence that you’ve got a viable release, you’ll need to break work down into smaller
stories that drive development while maximizing learning and minimizing risk.

Build your product up in layers, like a painter, to maximize learning and minimize risk.

94 Respond at Scale
22. Plan and Workshop Stories Ahead of
Development (AKA backlog refinement)
Understand how to use deep-dive story discussions to understand
and come to agreement on precisely what we’ll build

Product team planning

Ahead of every sprint, your product team will need to meet frequently to get ready. I’d
recommend placing at least a weekly meeting on your calendars. Product teams that sit close
together usually don’t need to schedule a meeting, they can just talk together throughout the day
as needed.
Use product team meetings to:
§ Review the progress of the release so far
§ Discuss and add new stories you’ve discovered that should go into the current release,
or be tossed back into the opportunity backlog
§ Select stories for the next 1-3 sprints
§ Identify all the work that needs to be done to get those stories really ready

Product team task board

Keep the stories you’re working on visible in a product team task board. Identify and post the
tasks you’ll need to complete to get those stories ready.

opportunities
&
backlog backlog
items to do doing done items

opportunity

backlog split & refined

item to get backlog
ready items

discovery
team tasks

A product team task board often combines the stories we’re getting ready and the stories we’re
doing discovery work for.

Workshop in small balanced groups

3-5 people is a good-sized group for workshopping stories. It’s difficult for more than that to
work together productively. If more people are interested in participating, schedule time later to
review and get feedback on the results, and make adjustments.
Include:
§ Someone who understands the software from a user’s perspective: Often it’s
someone from the PO team such as a UX designer, business analyst, or the product owner.
§ Someone who understands the code: Usually a developer on the team who has
knowledge of the code and how to implement the feature you’re discussing.

Respond at Scale 95
 § Someone who can test the product: Ideally a tester on the team that can ask tougher
questions, help identify acceptance criteria, and get enough information to help them
think about a good test plan.
In the Scrum community, this group of people is sometimes referred to as “the three amigos.”
Notice this group of three isn’t like the core product ownership team. During story workshops,
QA plays a critical role.

Testers play a critical role in refining stories before

every sprint
It’s OK if the whole team doesn’t participate so long as those that weren’t there can learn from
those that were later during the sprint.

9 Rules of thumb to improve your backlog

refinement workshops:
1. Do it more often – try twice a week
Plan to workshop stories or do backlog refinement multiple times a week. It’ll make the sessions
quicker. And, if questions come up that the group can’t answer, you can do some research and
bring the story back later in the week.

2. Make attendance non-mandatory

When people are forced to attend a workshop they’re often unengaged. If they’re not engaged,
you won’t have a good discussion, and leave with the shared understanding you need.

Ironically, including everyone with the hope that they all

leave with shared understanding can result in no one
leaving with shared understanding.
As long as you have a small balanced group that includes someone who understands the
functionality, someone who can build it, and someone who can test it, you’ll have a good
discussion. Let groups know ahead of time what you’ll be talking about, and allow them to opt in,
or leave if they’re not interested or engaged. If someone who wasn’t there needs details later,
they need only talk with a team member who was there.

3. Keep the working group small

Groups of 2-5 can have an effective conversation. If you more want to participate, try a fish-bowl
facilitation approach.

Fish Bowl Collaboration Pattern

Use this approach to have productive, unstructured conversations when a large group wants to
participate.

96 Respond at Scale
§ 3-5 work together in front of
whiteboard or flipchart paper –
they’re the fish in the bowl.
§ Others may observe, but not
speak. They’re outside the bowl.
§ If someone from outside the bowl
wants to participate, they can
“jump in.” But, when one jumps
in, another must jump out.
This way the conversation stays small
and productive and others stay
informed and involved. It's also a great
way for learners to get up to speed
without slowing down work.

4. Don’t project your backlog tool on the wall – use the

whiteboard
Everyone can engage sketch their ideas on the whiteboard. Everyone can add their own sticky
notes with ideas. Use tools that allow everyone to discuss, visualize ideas, and engage. Even when
working remotely, try to use tools, like google docs, that allow participants on all sides to make
changes to a virtual document.

Talk & Doc

Don’t let your words vaporize, especially during a story workshop. Use whiteboards, flipchart
paper, index cards, sticky notes, napkins, or whatever you can get your hands on to visualize your
thinking.

Draw pictures that describe the user experience you’re talking about.
Record story tests on flipchart paper or whiteboard where everyone can see them.

Speak in examples
Remember if you’re keeping outcomes in mind, you’ll need to talk about who does what in your
software.
Don’t just describe what the software does; give specific examples of users and what they’d do in
your product.
Talk about:
• Obvious examples
• Typical examples
• Complicated examples
• Terrible, awful, no good, very bad day examples
• Terrific, ideal, happy day examples

Respond at Scale 97
 5. Don’t start with acceptance criteria, take time to discuss and
visualize how the functionality might look and work first
It’s just hard to arrive at good acceptance criteria if everyone doesn’t have the same
understanding of how the software should work. Take time to make sure you’re in agreement
about how it works first.

6. Use acceptance criteria to confirm you have shared

understanding
After you’re reasonably confident the team has the same idea in mind about what they’re
building, discuss how you’ll confirm you’ve built the right thing. It’s OK if this discussion results in
a bit of back-tracking. That’s why you’re having it.

Acceptance Criteria
Acceptance criteria, or the “confirmation” part of the story, is our agreement on what it means to
be done with the story. I like using these questions to drive out acceptance criteria:

1. What will we check to confirm this story is done?

2. How will we demonstrate this story at sprint review?
For extra credit ask:

3. How will we measure success when this feature or

capability is released?
Answer these questions as a team with simple bullet points.
You may go deeper with acceptance criteria by using approaches like Behavior Driven
Development. Acceptance criteria formatted as BDD looks like this:

Given [some preconditions]

When [a user does these steps]
Then [we’ll observe these specific results in the
product]
A best book for learning to work together to create great acceptance criteria is Adzic’s
Specification by Example.

7. Do talk about technical details

It’s OK for developers to discuss how they’d implement it and consider options. Because, if it’s
expensive to build, we may want to consider alternative designs. Or, not build it at all.

8. Do estimate
Discussing how complex it would be to build will help confirm you have shared understanding
about how it works. It might force discussions of technical trade-offs. And it may change what
you choose to build.

98 Respond at Scale
9. Do split stories into the smallest testable parts possible
Don’t expect stories to come into the workshop “right-sized” for development. This is what the
workshop is for. Use the deeper understanding you’ve built during the workshop to break the
story down into the smallest buildable and testable parts you can.

Remember, the value from each of these small stories

likely doesn’t come from users putting them to use until
many of them are built and released. But, as a team,
you can learn from everything you build. So, make them
small!
Split and thin stories during the workshop
As you discuss what the software could do,
write those things down on sticky notes,
one thing per sticky note. You might find
that they become acceptance criteria, or
smaller stories you could split out and build
independently.

Play good-better-best
Describe a “barely-sufficient” version of the
functionality, then ask what would make it
better? And then, what would make it
fabulous.

Meszaros’ simple splitting heuristic

Gerard Meszaros describes for simple buckets that almost every story can be broken up into.

Bare Necessity Capability & Flexibility

For the feature to be minimally demonstrable What would add the ability to perform the
– but not releasable, what is the minimal user task in different ways? Adding in sub
functionality? tasks that are optionally performed?
Example: A form with only necessary fields Example: a form with optional fields, date
and no validation lookup tools, input translation on dates

Safety Usability, Performance, Sex Appeal

What would make this feature safer to use? What would make this feature easier to use?
For both the user, and for the business paying More desirable to use? Faster to use?
for the software?
Example: auto-completion, sexy visual
Example: input validation, enforcement of
design, speed keys
business rules such as credit card validation

Respond at Scale 99
 23. Support the Team Through the Sprint
Use different techniques for keeping your progress visible

Work with the team every day

Product owners and product team members need to check in with the team every day or things
can get off track quickly.
During the sprint your day-to-day activities include:
§ Listen in on standups
§ Check in with individual developers on ongoing stories to give feedback and guidance
§ Review finished stories

Keep development progress visible

Burn charts can be used at both the sprint level, and whole release level.

Burn Down Chart Burn Up Chart

25

20
Stories added
20

15
Stories added

15
Stories removed
10

10

5
5

Stories removed
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10

Burndown chart Burnup chart

A burndown chart shows work remaining, but A burn up chart separates the work
is sometimes difficult to visualize new work completed from the total work to complete.
added. It’s easy to see when we’ve added or
removed work.

Cumulative flow diagram

A cumulative flow diagram shows the specific state of all the work and makes it a bit easier to see
bottlenecks.

Source: http://www.agilesherpa.org/agile_coach/metrics/cumulative_flow/

100 Respond at Scale

Development task board
A team-level development task board makes it easy to see specifically what’s in progress and
how close to “done” it is.

done
backlog backlog
items to do doing done items

delivery
team tasks

Tagged Story Map

A tagged story map allows us to see how much is done in a whole release and how much is left to
go.

Respond at Scale 101

 24. Evaluate Your Product’s Release Readiness
Learn about the activities you’ll need to engage in to prepare the
product for release

Enough
Don’t release when all the scope you’ve defined is completed, release when you have enough.

Enough is a subjective evaluation the product owner

will need to make with the help of the product team,
and potentially the whole team.
For stakeholders: Enough software may be the addition of a feature critical or capability that
improves the business in an observable way. For commercial products, enough may be the
addition of new capabilities or features that can help acquire new customers.
For customers: Enough software may be the addition of a feature that will represent real value
for them when they or their organization begin to use the new software.
For users: Enough software may be the addition of software that allows them to reach one of
their goals using your product.

Evaluate release readiness

Evaluate the working product with Users and Customers

While you may have validated portions of your product using prototypes in discovery, it’s critical
to re-validate working software with users and customers before you ship, especially where value
and usability are critical.

102 Respond at Scale

Balance Continuous Discovery
and Development
25. Continuous Discovery and Delivery in Parallel
Tracks
Learn how to balance continuous discovery and delivery in an Agile &
Lean environment
There are [at least] two kinds of work in software development, and there’s no way around it.

Development work
If you’ve worked in Agile development before, you know teams will talk a lot about velocity. But
the velocity they’re talking about is development velocity. Teams hand-wring about their
predictability. At the beginning of a sprint, they’ll estimate velocity, and at the end they’ll
measure it. Ideally their prediction was accurate.

When you’re delivering production quality stuff, quality is super important. If we’re putting
software into production, quality, scalability, performance, localization, and lots of other
concerns are important. So, finished development work should be built, tested, and reviewed by
others to look after all these concerns. Agile teams will talk a lot about “potentially shippable
software” which really means that they may not have built enough of it to ship yet, but once they
do, the quality is high enough that they could ship it confidently.

Development work focuses on predictability and quality

Discovery work
One of the tragedies in software development, and all product development for that matter, is
that much of what we build doesn’t succeed. It doesn't deliver the benefit we’d hoped. So, that’s
a problem. But, even before that, it takes a bit of time to learn enough about the problems we're
solving to make good decisions about what we should build. We use discovery work to do all that.
To answer questions, to test ideas, and to avoid – as much as possible – wasting time over-
investing in quality stuff we shouldn’t have built in the first place.
We want to learn as quickly, cheaply, and safely as we can. So velocity is important during
discovery too – but this is learning velocity.

Discovery work focuses on fast learning and validation

Because the goal is learning, not working software, a discovery learning loop looks a bit like this:

Balance Continuous Discovery & Development 103

 It starts by describing what we believe is the problem we’re solving and for who, the solution It
starts by describing:
o What we believe is the problem we’re solving and for whom
o The solution we’d build to solve it
o How we’d measure success
That’s our bet, our best guess, our belief, our hypothesis. All of those are uncomfortable words
for people who believe they’re building the right thing. But, the truth is, we’re always making a
bet that we’ll get value. Embedded in that bet are lots of assumptions, risks, and maybe some
questions. To focus our learning, we’ll choose the assumption, risk, or question that scares us the
most and identify an experiment or method to learn. Then do it. Then use what we’ve learned to
change all those going-in beliefs about problems and solutions.
Sadly, one of the most time consuming expensive ways to learn is to build potentially shippable
software. So we don’t – unless we really can’t come up with any other way to learn, or we’re
really confident our bet is good. Remember, we’re not betting we can build it on time. We’re
betting that people have the problem we’re solving and will happily try, use, and adopt our
solution.

The most expensive way to test your idea is to build

production quality software
That’s how a learning loop works. And there’s a few things you should know about it.
We do all this as fast as we can. In hours when possible. Sometimes it may take days. But, we
hope it doesn’t take weeks. So, lots of discovery learning loops should fit in a typical 2-week
sprint.
Discovery work often results in killing ideas. At the end of every test you’ve got a decision to
make: build it, kill it, or keep learning. Yes, what I’m really saying here is discovery work can and
should result in killing ideas. Not everything goes forward. This can make some folks really
uncomfortable.
We time-box discovery cycles. To keep discovery costs from running away from us, we’ll timebox
a test or experiment from a few hours to a few days.
We can’t predict what we’ll need to learn next – not easily. When we learn something really
valuable, it tends to really change our going-in beliefs, and really change what our next biggest
assumption or question is. This can really suck.
Discovery loops chain together a little like this:

104 Balance Continuous Discovery & Development

By now it should be clear that both development and discovery work are critical. But the mindset
you approach the work with, and your process for doing it, are very different.

OK, it’s really 3 kinds of work…

To actually start building work software, you’ll need to make a lot of tactical design decisions.
These may not be the risky decisions that need validation, but they still need to be made. It’s
often designers that need to spend time ahead of development to refine and finish design work in
preparation for writing code.

If you’ve validated the product is worth building, you’ll

likely need to finish some detailed design work before
you write code
It’s happening all at once
It would be super-cool if we could all focus on discovery work, get it done, then move our focus
to tactical design and development. And that could work if all team members had the same skills.
But since some are good at writing code, some are good at user experience design, and others
are good at a variety of other things we’ve got an opportunity to be doing many kinds of work at
once. So we do.

Discovery work happens concurrently and continuously

with development work.
I draw the conjoined model a little like this these days.

Balance Continuous Discovery & Development 105

 Discovery work uses irregular cycle lengths. It’s “Lean” in that we’re trying to make the discovery
cycle as short as possible. Ideas in discovery mutate and very often get abandoned. The best
move forward into more deliberate development cycles. I’m not sure how to show all that stuff in
a single drawing. But, I’m trying to in the one above.

Discovery and development are shown in two tracks

because they’re two kinds of work, and two kinds of
thinking
Two tracks, not two teams
But, you shouldn't think of it as two processes – just two parts of one process. And, I think you’re
doing developers and others on the team a disservice not to involve them in discovery work.
There’s usually more than enough discovery work to do and lots of ways to involve the whole
team in doing it. If you feel pressure to shorten discovery work to “feed the beast,” it usually
means you’re making decisions to build software before learning enough to be confident that you
should. In the best case the outcomes are uncertain and usually the outcomes are just bad.

The whole team is responsible for product outcomes, not

just on-time delivery
Dual-Trak Myths
Let me hit the biggest misconceptions people have with the model again.
Myth: Discovery is a process that precedes agile development. It shouldn’t.

Discovery is a necessary part of product development.

Practice it with the same agile and lean principles in
mind.

106 Balance Continuous Discovery & Development

Myth: All work moves from discovery to development. It doesn’t.

If we’re doing discovery right, we substantially change

and kill lots of ideas.
Myth: The discovery team is different than the development team. It shouldn’t be.

While a product manager, designer, and senior engineer

may lead and orchestrate discovery, they must Involve
the whole team in discovery tasks wherever possible.
Keep discovery work and progress visible to the whole
team.
Myth: Once you move from discovery to development, discovery work done. It’s not.
This misconception is something that really bugs my friend Jeff Gothelf. He sees the production-
quality software we build as our last-best experiment.

Keep measuring and learning even after you ship.

From Jeff Gothelf’s perspective, it’s all discovery, and we learn from everything we make; be it a
paper prototype, or the next feature in your production software. I agree with him.

Involve the team in discovery work

I’ll come right out and say it: it’s foolish to leave developers, testers, and other team members
out of discovery work. While discovery work may not be their primary expertise, there’s a great
deal of discovery work they can do well. And, what’s more, involving them:
§ Adds diverse thinking and ideas you wouldn’t normally get
§ Helps build user empathy, alignment, and ownership to product outcomes in the team
§ Smooths and speeds up the transition of work from discovery to development
There are several ways you can include other team members in discovery. Here are a few:
§ Include developers and testers when sketching proto-personas or making journey
maps
§ Include a developer or tester in user interviews and prototype testing
§ Synthesize interview notes and other research data together
§ Use collaborative design sketching approaches like design studio or sketchboarding to
involve the whole team in ideation
§ Scale up the fidelity of prototypes to include working code to help get better data in
discovery
§ Include developers in discussions about measuring outcomes – they’ll bring ideas in
that help automate measuring

Balance Continuous Discovery & Development 107

 Visibility and the discovery track
Visibility and transparency are important characteristics of and Agile process. If it’s discovery and
design you’re responsible for, you’re not helping your team if you keep it hidden.

Keep discovery tasks visible in a discovery task board

Discovery task board at Carmax

Keep your current hypotheses, design, and test results visible in an evidence
board

“Work wall” from a product team at Carmax

Visualize Learning Velocity

Try approaches like the “Delta-Next” described earlier in this handout. Whatever you do distill
what you’ve learned and how it’s changed your hypothesis after every learning cycle.

Key learnings in a “Delta-Next” 2x2 at Carmax

108 Balance Continuous Discovery & Development

Rethinking Scrum Ceremonies
Sprint planning starts by talking about discovery work
Adjust your typical sprint planning meeting so that your first conversation is about the discovery
work you’re planning on. Remember that discovery work can’t be planned like in detail like
development work can. Hopefully you can complete a cycle of discovery in a few hours to a few
days. And, what you learn from that discovery cycle will help you decide what you'd like to learn
on the next cycle and exactly how you might go about it. But you won’t be able to predict what
you’ll do in the next cycle until after you’ve learned.

If you can plan two weeks of discovery work in detail,

you’re probably doing it wrong.
Since you can’t plan the details of discovery, instead:
§ Discuss the opportunities you’re working on
§ Discuss the risks, assumptions and questions you’re likely to tackle in that
opportunity
§ Discuss the types of work that the team could likely help with
§ Agree on a time-box to budget team time for discovery work
Once you’ve agreed on a time-box to allocate for discovery, the team will better be able to
predict how much development they can tackle.

In daily standups review delivery then discovery

Usually more team members are engaged in development work, talk about that work first.
Then, switch to talking about discovery work. It’s OK for team members that don’t have any
discovery work responsibility this sprint to leave if they want.

Try not to mix discovery and delivery conversations.

They’re different kinds of work and it tends to confuse
people.
Start sprint reviews by talking about discovery
In a sprint review or sprint demo it’s time to show what we’ve done and assess the quality.
Normally you might start by showing what was built. But, from now on, start by discussing
discovery.

Discuss what you’ve learned and not just what you did
You may have worked hard building lots of prototypes or interviewing lots of users. But, it’s not
time to impress people with your hard work. Focus discussion on what you’ve learned.
§ What assumptions did you validate or invalidate?
§ What important questions did you get answered?
§ What are the next important things to learn?
§ Will items in discovery move forward to delivery? Continue in discovery? Or, have we
learned they’re bad ideas and we can kill them?
If you include business stakeholders in your reviews I’ve learned that they really love hearing this
stuff. They usually really care about product outcomes and the work you’re doing to validate that
you’ll get them is important. I’ve also learned that the last time I want critical stakeholder
feedback is after we’ve spent lots of time and money building production quality software.

Balance Continuous Discovery & Development 109

 Ebb & flow
In most organizations all focus and almost all the pressure is on building more stuff faster. When
your organization begins to give discovery and delivery equal visibility, you’ll find the organization
will begin to value it more. When that organization sees discovery as equally valuable, people
worry less when development velocity dips so more of the team can focus on learning velocity.

110 Balance Continuous Discovery & Development

26. Plan Discovery AND Delivery
Use a sprint planning meeting to review the work you’d like to
accomplish in the sprint, and create the plan to accomplish it.
Agile processes like Extreme Programming and Scrum use time-boxed development where each
development cycle starts with a planning session, and ends with review. In many companies,
they’re some of the most loathed of meetings. They can be long and painful, and by the time
team members leave the meeting, they’re often ready to agree to anything just to get out of the
room. It doesn’t take a rocket scientist to guess that the quality of the plans they make aren’t so
good.
But, it doesn’t need to be that way.
Here’s a simple recipe that should help you avoid the worst problems.

Development cycle planning recipe

Purpose: use a team planning session to set goals and plan work together as a team. The team
owns its plan. It isn’t given to them.

Prepare
Who: the core product team including the product owner/product manager and the few people
the lead discovery and development for your team’s product.
How long: this is a continuous activity. You may spend a little bit of time every day or every
couple days. Just be ready for the team planning meeting or it makes it challenging for everyone.

1. Choose delivery stories a cycle or two ahead

If you’re a product owner, meet routinely with your core product team to discuss the
progress of the solutions underway. Choose the stories that you'd like to take on next to
move those solutions closer to release.

2. Workshop stories ahead of time

For those on the product team, make time to work together with team members ahead of
the planning session. Dig into details, split larger stories, and consider multiple options. In my
book User Story Mapping, look back to Mat Cropper’s story in Chapter 7. When I spoke with
Mat, one of the things he most looked forward to was the series of short, half-hour ad-hoc
story workshops he had us developers and testers get ready for planning.

3. Review discovery opportunities a day or so before planning

Since you learn something after every cycle of discovery validation, it’s hard to choose these
too far ahead of time. It may be as simple as carrying forward the opportunities you’re
working on the in the current development cycle.
Be ready to talk about the opportunities you’ll be exploring over the next sprint. Be ready to
talk about your learning goals. And, be ready to discuss the amount of whole-team
participation you’ll need. You’ll need to give the team an idea of how much help you’ll need
for them in the coming cycle.

4. Invite the whole team

And any others whose help you might need during the upcoming development cycle.
Hopefully your planning session is already on the calendar. It should be a routine workshop
that follows the cycle-end review.

Balance Continuous Discovery & Development 111

 Plan
Who: the whole product team responsible for doing the work. Optionally anyone else that may
work with the product team during the next cycle.
How long: plan for 1-3 hours. It depends on the size of your team and the length of the time-box
you’re planning for.

1. Start by discussing the big goals

You’ve chosen some opportunities to move forward with discovery work and some stories to
work on delivering. How do these opportunities and delivery stories help advance your
product?

2. Review the discovery opportunities you’ll be engaged in and agree on the

amount of team time needed
Review each opportunity – there should only be one or two. What are they? What’s the
benefit for building them? What are the risks or assumptions you’ll be working to test? How
might the team help in this effort. Agree on a time-box for team involvement. You’ll need to
know how much team time you’ll be using for discovery to figure out how much
development work you’ll be able to take on.

3. Review the stories you’ll be turning into deliverable software

Don't go into extreme detail here – just enough to give everyone the big picture. Use lots of
pictures. Bring in decisions that smaller groups made in story workshops.

4. Set a time-box for the delivery team to plan on their own

Remember, crowds don’t collaborate. And the people building and testing this software
need to do some real thinking to create their recipes for building these stories. Give the team
an hour or so to break into small groups and work together on the stories. If you’re a product
owner, UI designer, or business analyst, stay close by. Observe if you like. But be ready to
answer questions that’ll help them move fast.

5. In small groups, create a plan for each story

Work in small groups that include developers, testers, and anyone else that has work to do
to turn the story into working software.
• Discuss your approach to building each bit of software. Write out development tasks
that describe your plan. But remember that you likely can’t anticipate everything. Be
open to identifying new tasks as the development cycle progresses.
• Discuss how long each bit of software is likely to take.
• As a development team, decide how many of these stories can be successfully
completed in the delivery cycle. Don’t forget to consider holidays and days off.

6. Together, agree on the plan

At the end of the time-box, and after the team does their plan for each story, they’ll need to
come back and share their plan. Not every detail, because that would be super-boring, even
to them. But, what’s important is for the team to be clear about what they believe they can
get done in the cycle. They should take this plan and their agreement seriously, especially if
they want others to consider them reliable and predictable.
Agreeing may take a little time, especially if all the work that needs to be done won’t fit in
the development time-box. It’s lucky you know some tricks for slicing stories down thinner.
Try dialing back a story from better to just good enough. That should make it fit.

112 Balance Continuous Discovery & Development

7. Celebrate
You’re done. In the past, we liked planning in the afternoon. We tried to finish a bit before
quitting time. Then we’d celebrate by taking the rest of the day off. We showed up the next
day refreshed and ready to start working on the plan we created together.

Balance Continuous Discovery & Development 113

 27. Standup to review and plan every day
Use a daily standup meeting or team huddle to review your progress
on the previous day and plan your work today.
If you’re already practicing an agile process, you’re probably familiar with a daily standup
meeting. And, it’s been my experience that for some teams this can be one of the most annoying
parts of the day. If it is, this may be a hint you should change the way you’re doing things.

Remember: This isn’t a status meeting.

This is the team’s time to figure out how they can work
together to make as much progress as possible today.
Who: the whole product team
How long: Keep these meetings 15 minutes or less. If a problem takes more than a minute to
discuss or solve, use this meeting to plan a time to discuss it afterward.

1. Discuss any team news or general announcements everyone needs to know

The standup meeting may be the one time in the day that the whole team is together.

2. Discuss development work

Review each story in progress. Hopefully there are only 2 or 3. If you have more stories in
progress, it may be a symptom of not working together, or “swarming” to get stories completed
faster.
For each story in progress discuss:
• What progress was made the previous work day
• What challenges might be slowing things down or blocking progress
• What can do together today to move things forward
While discussing development work it’s helpful to look at simple visualizations:
• A task board showing the work to do, in progress and done
• Mock ups or visualizations of the software you’re building – this makes it easy to
explain exactly what you’re working on
Notice we’re discussing our progress story-by-story and not person-by-person. Remember it’s not
about who’s most busy. We’re all busy. It’s about the progress we’re making on the software we
agreed to build. Keep the focus there.

This team at Atlassian holds their standup in front of a flow for the feature they’re working on.

114 Balance Continuous Discovery & Development

3. Discuss work to prepare for next cycle
Part of the team’s work is refining development stories for the next cycle. If there are stories that
need refinement workshops today, let people know during the standup so that can attend if they
want.

4. Discuss discovery work

We’ve saved discovery discussion for last. It’s OK for team members who aren’t involved in
discovery work to leave and get to work on development work.
Review each opportunity in progress:
• What are next tests, customer interviews, or work you’ll be doing to refine and advance
your hypotheses.
• How can other team members participate?

A discovery task board at Carmax

As with discussing development work, it’s useful to have visualizations to support the discussion:
• Use a discovery task board that shows your current hypotheses, next most important
question, and discovery tasks
• Keep an evidence board that shows personas, journey and story maps, user experience
sketches, and any other information that supports your current hypothesis

An evidence board at Carmax

More reading: Jason Yip, currently a coach at Spotify, has a useful paper describe lots patterns
and approaches to standup meetings. While he doesn’t explicitly discuss discovery work, you’re
sure to find some useful advice in it:
It’s Not Just Standing Up: https://martinfowler.com/articles/itsNotJustStandingUp.html

Balance Continuous Discovery & Development 115

 28. Review Sprints with the product team
Understand how to evaluate your work, your plan, and your process
strategies together as a team
If you’re using Scrum, this is a Sprint Review and Retrospective. If you’re using XP terminology,
this is an Iteration Review. If you’re like some teems I’ve worked with you might do this Friday
afternoon before everyone leaves, or Monday morning before you plan the next weeks’ worth of
work.
One of the core characteristics of an effective process is stopping and reflecting on the work
you’ve done, and using what you’ve learned to make changes to how you’ll work going forward.
Yes, it’s an Agile tenet. But, it’s just a characteristic of any effective way of working.

Team Product Review and Reflection Recipe

Purpose: The team that worked together to understand their product development—and who
made a short-term plan for doing discovery and development work—must stop and reflect on the
quality of their work. Use a short workshop to accomplish this.
Who: the whole product team
Constrain this workshop to include only the people who worked together to understand
and plan the work. Include the product owner and any others on the product team, as
well as developers, QA, and anyone whom did active delivery work. Yes, I’m saying that
it’s okay to exclude business stakeholders. We’ll share with them soon enough. But right
now we need a safe place to talk.
How long: plan for 1-3 hours. It depends on the size of your team and the length of the time-box
you’re reviewing.
Bring food. Years ago, in my team, this workshop simply couldn’t start if we didn’t have bagels.

1. Evaluate your current product’s health

If your team is responsible for an existing product or product area, you’ll need to review how
that product is doing. If you don’t currently have something in production that users are
using, skip this part. Hopefully you’ll get something shipped soon.
Discuss your product’s Key Metrics, or KPIs:
§ What 2-4 metrics are you currently paying attention to about your product or product
area?
§ What are their current values?
§ How do they compare to what you expected? To the last cycle? To last month? To last
year?
Discuss any subjective data on your product:
§ Quotes from customers that came from discovery work, customer surveys, or
customer support

2. Evaluate discovery work

Reviewing discovery is critical. Show what you’ve learned from your customers and users.
o Discuss each opportunity you’ve taken up briefly: whom it’s for, why we’re building it,
and the outcomes you expect if it’s successful.
o Discuss how your hypotheses changed during this cycle:
o What parts of your hypotheses were wrong?
o What new facts did you learn that changed your hypotheses?

116 Balance Continuous Discovery & Development

 o What parts of your hypotheses were strengthened as a result of your discovery
work?
o Discuss and show the work you’ve done to understand the problem and the solution.
This may include things like proto-personas, story maps, or UI design.
o Discuss and show prototypes and experiments you’ve run. Discuss what your customers
and users are saying about your solution. If you have experiments that you deployed to
a limited set of users, discuss any data you were able to get from measuring their use.
o Discuss your learning velocity: the amount you’ve learned relative to the amount of
effort you put into discovery.

3. Evaluate development work

Start by discussing and showing the software built as a result of the stories. Make sure you
bring it up on a screen, and get a chance to try it out. All of it. In big teams, it may be the only
chance everyone has to see one another’s work.
Grade your quality subjectively as a team. Grading will drive out lots of good discussion.
o Discuss the quality of user experience. Not just how the UI looks, but how it feels to
use. Is it as good as you expected? Grade yourselves on a scale of 1-5, with 5 being best.
o Discuss the functional quality. Did testing go smoothly, or were there lots of bugs? Do
testers expect to find more bugs as more software is added, or as they get more time to
test? Grade yourselves on a scale of 1-5, with 5 being best.
o Discuss the code quality. Did you just write code that will be easy to maintain and
grow? Or, did you add to the technical debt you’ll need to clean up later? Grade
yourselves on a scale of 1-5, with 5 being best.
Write stories to correct quality issues you see in the product.

4. Evaluate your original plan

If you were working in a time-boxed iteration or a sprint, you started by making a plan and a
prediction for how much you could get done, both discovery and development. Was your
plan a good one?
o Decide which stories are and aren’t done. This may be harder than you think. Having
this discussion helps your team build a common definition of what they consider to be
done. Does “done” mean there are automated tests? Does it mean that all manual
testing is done? Does it mean that product owners or UI designers have reviewed it?
o Total the number of stories you agree are done. You can total the stories, or the original
estimates of your stories. This is your development velocity.
o Total the stories started and not completed. If it’s a lot, it’ll signal you need to work on
your planning. I call this amount the overhang. Someone I used to work with called it
hangover, because it makes your head ache.
o Discuss the amount of time budgeted on discovery work. Since discovery work was
time-boxed, you need only evaluate whether you used the time you planned. Ask
yourselves if you used more time than you budgeted? Using too little will hurt you later
when you don’t have things ready to build that you feel confident in. Using too much
may hurt your chances for delivering what you’ve committed on time.

5. Review and improve your process

o Discuss the way you worked over the last development cycle. Could you make changes
to the way you work to:
• Improve the quality of what you learn doing discovery?
• Improve the whole-team participation in discovery?

Balance Continuous Discovery & Development 117

 • Improve development quality?
• Improve your ability to predictably plan?
• To make it more fun to be at work every day? Because if you’re having fun, I
promise you’ll be able to go faster.

§ Review any changes you made last development cycle. For each change should
you:
• Keep the change in place?
• Take the change out?
• Adjust it and try it again?
o Together agree on the specific changes you’d like to make during the next cycle. It’s
best to make just a few changes. One to three is good.
This process improvement discussion is commonly called a retrospective, and there are lots
of great approaches to performing one.
If you’d like to look at some more comprehensive recipes for retrospectives, try the book:
Agile Retrospectives by Esther Derby and Diana Larsen.

118 Balance Continuous Discovery & Development

29. Review product team progress with the
organization and stakeholders
In Scrum, sometimes this is called a Sprint Demo. Some teams call this meeting a Showcase. You
might know this as the thing your team needs to do every few weeks to keep your work visible to
the whole organization.

Stakeholder Product Review Recipe

Purpose: Keep your product’s health, your discovery work, and your development work visible to
the whole organization.
There are lots of others in the organization who are likely interested in what you’re working on,
and what you’ve accomplished. You’ll need to make this work visible to them. Unlike your team,
these others probably don’t know the details of what you chose to build, nor where they fit into
the big picture. So, you’ll need to plan on connecting what you accomplished and learned back to
the product. This is also an excellent opportunity to learn from them, and to get their support.
Do use this review to show the outcome of your efforts. Stakeholders should care about
that.
Don’t use this meeting as a place for stakeholders to criticize your team’s planning or
the way your team works. That’s your team’s responsibility to manage.
Who: Invite everyone who’s interested.
This is a big public review. Anyone interested is welcome. Make sure your whole team is there.
Seeing others’ reactions to what they’ve done, either positive or negative, helps remind them
that what they’re doing matters.
Some organizations combine multiple product teams’ reviews into one larger stakeholder review.
This cuts down on the number of meetings stakeholders need to attend routinely.
How long: plan for 30-90 minutes. This review should be faster, and at a higher level than your
teams’ product reviews.
Bring food. I promise everyone will like what you have to say when they’re loaded up with
carbohydrates. Even bad news goes down easier with sweets.

1. Review your current product’s health

If your team is responsible for an existing product or product area, you’ll need to review how
that product is doing. If you don’t currently have something in production that users are
using, skip this part. Hopefully you’ll get something shipped soon.
When reviewing your product or product area’s health, make sure you connect what your
focusing on to the metrics that matter for the organization.
Discuss your product’s Key Metrics, or KPIs:
§ What 2-4 metrics are you currently paying attention to about your product or
product area and what are their values?
§ How do those metrics connect to those that impact the business such as revenue,
cost savings, or retention?
§ How do they compare to what you expected? To the last cycle? To last month? To
last year?
§ What should you celebrate? What should you be watching out for?
Discuss any subjective data on your product:
§ Quotes from customers about your current product that came from discovery work,
customer surveys, or customer support

Balance Continuous Discovery & Development 119

 2. Review discovery work
Reviewing discovery is critical. The best time to get feedback from stakeholders is before
you’ve invested lots of time building something. If you’re showing real lessons learned from
putting software in front of customers and users, they’ll value learning what their customers
actually think. Often, the only thing that trumps an executive opinion is a cold, hard fact.
o Discuss each opportunity you’ve taken up briefly: whom it’s for, why we’re building it,
and the outcomes you expect if it’s successful. Make sure you tie that opportunity back
to the value proposition for your organization.
o Discuss your hypothesis at the beginning of the cycle and how it changed during the
cycle:
o What were you wrong about? And, what tests lead you to believe you were?
o What were surprising new facts that changed your hypotheses?
o What parts of your hypotheses were strengthened?
o Discuss and show the work you’ve done to understand the problem and the solution.
This may include things like proto-personas, story maps, or UI design.
o Discuss and show prototypes and experiments you’ve run. Discuss what your customers
and users are saying about your solution. If you have experiments that you deployed to
a limited set of users, discuss any data you were able to get from measuring their use.
Notice that you’re not explicitly discussing the time budgeted for discovery or reflecting on
your learning velocity. Your team owns the quality of its planning and its work. You’ll
certainly answer questions and share how you did thing when asked. But, their no need to
open yourselves up to micromanagement.

3. Review delivery work

It’s been my experience that stakeholders are focused on what and when you’ll release to
customers and users. They should be because it’s not until after you release a viable solution
that you’ll be able to observe real outcomes and get real value. They’ll be interested in
progress made toward that goal.
Review the delivery work you’ve completed at a solution-by-solution level. Think of the
solution as the big rock that’s more relevant to stakeholders. The feature or capability that
you’ll release. Some using story jargon may think of this as an epic.
For each solution:
o Review the solution’s target customers, users, and outcomes. It’s good to remember
why we’re building this and what success means.
o Discuss and show the results of stories built for each solution. Stakeholders will offer
feedback. Hopefully if they had a chance to give feedback when you were doing
discovery work, the feedback at this point will be “Yup, that still looks good.”
o Discuss the stories holistically. If you’re using a development strategy like the Mona Lisa
strategy explained in User Story Mapping Chapter 4, you’ll need to explain to them why
the software looks incomplete at this point. Remember that they may want to see a
square inch of a complete portrait, and not the software equivalent of a sketch of the
whole canvas.
o Share with them your progress toward getting this solution releasable. How much work
is left? What have you learned while building the solution that will affect its successful
delivery?
Be prepared to write stories for new opportunities, or for changes you’ll need to make.

120 Balance Continuous Discovery & Development

 It’s possible that others in the room unfamiliar with what you’re building and why, will
suggest things that aren’t a good idea. Respectfully and gently remind them of the target
audience and outcome for the solution, and why what they’re suggesting might be a great
idea, but doesn’t support the outcome you’re currently focused on.
Notice that you didn’t discuss your team’s development velocity and how that relates to what
you’d planned on. Keeping your commitments is your team’s responsibility. Use your team’s
review and planning meetings to discuss how you’ll meet those commitments.
Keep your work visible to everyone in your company. Help them be excited about what you’re
doing and learning.

Balance Continuous Discovery & Development 121

 Agile, Scrum, and What You
Really Need to Know About
Process
Effective Process Uses Simple Values & Principles
Understand that effective process is based on simple values and
principles that make it less like an assembly line and more like a team
sport

Process
What do you think of when I say the word “process”?
Take a minute and write down the first word that comes to mind. Then keep going and write a
few more.

The Waterfall was never intended to be best practice

In his 1970s paper Winston Royce is credited with
drawing the model we commonly think of as the
“waterfall model.” But he drew the diagram in a
progression on his way to more sophisticated models. He
pointed out that you’d need feedback loops between
every phase, and feedback all the way from test back to
requirements. Royce was trying to describe an iterative
development cycle, NOT a sequential process.
“I believe in this concept, but the implementation
described above is risky and invites failure.” --Royce

Effective product design is more like a team sport

In the 1986 Harvard Business Review (HBR) paper “The
New New Product Development Game,” Takeuchi and
Nonaka studied a variety of product design teams and
found that the most successful had derived a process that
looked chaotic on the outside, but was ultimately faster
and more effective at creating great products. They
compared these teams’ work-practice to the sport of
Rugby.

122 Agile, Scrum, & What You Need to Know About Process
“Under the rugby approach, the product development process emerges from the constant
interaction of a hand-picked, multidisciplinary team whose members work together from start to
finish.” – Takeuchi & Nonaka

Game
What do you think of when I say the word “game”? Take a minute and write down the first few
words that come to mind.

Agile Development is a style of process

The term “agile” was coined in 2001 to name a style of process described in the Agile Manifesto
using simple values and principles. Specific processes such as Scrum, and Extreme Programming
are specific types of agile processes.

agile
Today’s common agile process is often
called Scrum, but uses a mashup of
practices borrowed from other processes:
for example, the common practice of user
stories comes from Extreme Programming. Agile is a style of process and an umbrella
term for lots of specific processes
Review the Agile Manifesto and 12
principles: DSDM Crystal
(Dynamic Systems Adaptive Software
Do you agree with the values in the Development Methodology)
Development
Agile Manifesto? Extreme
Scrum
Programming
Which of the 12 principles does Lean Software
FDD
Development
your company most need to focus (Feature Driven
Development)

on to succeed?

What values or principles do you think are missing from the manifesto?

Agile, Scrum, & What You Need to Know About Process 123
 Scrum’s Simple Agile Process Framework
The Plan-Do-Check-Act cycle is an old idea
W. Edwards Deming is usually credited for this simple Plan-Do-Check-Act
loop, although Deming credits Walter Shewhart with creating it. It’s a
simple recipe for a learning process that Deming described and promoted
in the 1950’s. You can tell by Deming’s haircut in the picture to the left that
he’s been talking about this and lots of other new management principles
since the 50’s. After the Japanese enjoyed early success with his ideas in
their automotive industry, westerners started to take notice.
Plan: create a short-term plan focusing on an
important goal.
Do: execute your simple plan.
Check: inspect the work you’ve done, and the
effectiveness of your plan. Take note of what
you’ve learned.
Act: Use what you’ve learned to adjust your
goals and your way of working,

Repeat this cycle perpetually as you move towards your goal, and through a series of goals.
Adjust your cycle length to match the rate you’d like to learn. The shorter your cycle length, the
faster you learn.

Use a PDCA loop to learn quickly and adapt goals,

plans, and work practice
Scrum is a simple process framework based on a learning loop
The Scrum Process Framework is a simple application of a Deming-style PDCA loop to the building
of software. And while Scrum’s creators may have initially envisioned its use for software, they
and lots of others, have found it’s simple enough to adapt to lots of other activities.

Because Scrum focuses on improving the process based

on what we learn each cycle, its creators call it an
empirical process
And, so do I.
You can describe the Scrum framework concisely using:
§ A set of simple values and principles that guide process adaptation and day-to-day
practice
§ 3 simple roles
§ 3 routine collaboration points
§ 3 types of artifacts teams create
§ A simple structure that binds roles, collaboration points, and artifacts together
Scrum is intended to be a process framework. What that really means is that it’s not completely
defined. In fact you’ll need to adapt Scrum to your organization and work to apply it.

Scrum is intentionally incomplete. Adapt Scrum to fit

your organization and goals.
124 Agile, Scrum, & What You Need to Know About Process
Scrum values and principles guide our thinking
Just like Agile values and principles give guidance that helps make specific process choices, Scrum
values and principles do the same thing.

Scrum Values:
Focus, Courage, Openness, Commitment, and Respect
Scrum values are things all team members should aspire to. Reminding ourselves of these core
values helps us make tactical, in-the-moment decisions when things get tough.

Inspect and Adapt

We create the opportunity to improve by stopping frequently, and looking closely at what we’ve
created and how we worked together to create it. That’s the inspection part.
We act on what we’ve learned and make changes to our product, our plans, and the way we
work. That’s the adaptation part.

Visibility and Transparency

We’re striving to work together as a team. If we were on a sports team, we could keep our eye on
the ball. But, when we’re engaged in knowledge work, and work in different locations we’ll need
to find other ways of making our work visible.

If we don’t have visibility, we can’t work together as a

team.
If we’re transparent about our specific plans and our progress, it lets others relying on us keep an
eye on how we’re doing things. This makes them less nervous. And, although it might make you
nervous to expose your specific plans, your team members and others can’t help you improve if
they can’t see them.

Be transparent about the way you’re working.

Scrum roles focus on three critical concerns in product
development
Scrum only defines three roles. Of course you know three roles and their responsibilities isn’t
sufficient to describe the way you or your organization works. But that’s where the adaption
comes in.

Remember a role is a hat, not a head.

You’ll find that team members may put on different role hats in Scrum. And, you’ll find that
specific roles on teams may all take on the same Scrum role.

Agile, Scrum, & What You Need to Know About Process 125
 While each role has a name – you should think of these roles as three critical concerns in creating
software, or in creating anything for that matter.

Product Owner
The Product Owner focuses on making sure we’re building a product that’s valuable to its
customers, can be used by its users, and can be created economically.
All companies create products. What your product is may be clearly defined. Or, your company’s
products may feel a little fuzzier. They could be the services it provides to its customers or
content it publishes to them. You may be working on IT infrastructure that supports your
company’s work to build products or provide services. But, we think of all these things as
products. And, we tackle the creation of big products and service by breaking them down into
smaller products. For example:
§ If you work in a dot com that sells software on line, we might call the shopping cart a
“product” even though it’s only part of the bigger online product that allows people to
shop for and buy things online.
§ If you work for a bank or insurance company, we might call a critical backend system
that supports accounting a product. Even though we know it’s not visible to our
customers and that it’s just one necessary part of the overall service our company
provides to its customers.
A product, even part of a larger product, demands someone to understand its vision, create
strategy, and lead the continuous improvement of the product. That’s a product owner.

A product owner understands vision, creates strategy,

and leads continuous improvement of a product.
Delivery Team
The delivery team is the name we use to wrap up all roles, skills, and people it takes to actually
create the product.
We’ll consider everyone part of the delivery team when they actively engage in making things
that become part of the product we deliver. In software that includes developers, testers,
technical writers, UI designers, and any other roles you can think of that contribute to turning
product ideas into something you can deliver to your customer.

Delivery team members include all roles that contribute

to turning product ideas into deliverable products.
Scrum Master, or Coach
The Scrum Master is responsible for looking after the effectiveness of the whole team. They pay
attention to how well product ownership and delivery team members work together. They help

126 Agile, Scrum, & What You Need to Know About Process
the team be mindful of the way it’s working and help the team make good decisions on how to
improve.
A Scrum Master isn’t a manager. They don’t break down work and delegate it to others. They
aren’t accountable for making the right product choices or creating a high quality product. But
they are accountable for helping those that do those things understand their responsibility, and
how to continuously improve their skill and the way they work.
For all these reasons we think of a Scrum Master as a:
§ Coach § Mentor
§ Servant leader § Help when you need it
§ Facilitator § Someone to prompt you to
§ Cheerleader action when you’re not
§ Conscience § Someone to help you focus
§ Nag when you’re not

The Scrum Master is responsible for everyone working

together effectively and for helping everyone to improve
their skill.
These three Scrum roles form a whole product team.

Setting the whole product team to work

Agile, Scrum, & What You Need to Know About Process 127
 0. The Scrum Master helps set things in motion
Look to the Scrum Master to provide structure and guidance, especially initially. The Scrum
Master works with the team to make the decisions to schedule all the routine collaboration
points. He will need to help the team decide:
o The length of time for Sprints, Scrum’s development time-box
o The start and end days for a Sprint
o When Sprint Planning and Sprint Review meetings will be
o When Daily Standup meetings will be
o What tools the team will use to make progress visible
o What tools the team will use to collect all the information the team will create to
understand the product they’re building
The Scrum Master helps facilitate most meetings, and isn’t far away as the team works together
throughout the day.

Glube: The Scrum Master is the glue that holds things

together, and the lube that keeps things moving.
1. Product ownership creates a product backlog
The backlog holds all the ideas, features to build, or problems to solve for the product the team is
responsible for. Product backlog items don’t really need to be anything specific, although these
days people like using User Stories for backlog items. Stories came from the Agile process
Extreme Programming.
To create, organize, and prioritize the backlog so the most important things are considered first,
the product owner will need to work with others on their team, business stakeholders,
customers, and users. The product owner needs deep domain knowledge of the product they’re
building and the marketplace, or business context, the product is used in.

The product owner doesn’t create or evolve the backlog

alone. She works closely with others to leverage their
experience and expertise.
Later in this class we'll talk more about whom the product owner works with, and some specific
practices they use to:
§ Understand product strategy to prioritize backlog ideas
§ Validate backlog ideas are worth building
§ Refine and break down backlog items into smaller buildable pieces

2. Product ownership and delivery team members create a short-term sprint

plan
In a Sprint Planning Meeting the product owner and delivery team work together to:
Understand: First understand the items we could build during a next sprint. Take some time to
explain the goal of doing this work for the next sprint, and what backlog items the team will be
working on to reach that goal.
Plan: The team then gets to work identifying the specific things they’ll need to do to create
product backlog items they’ve just talked about. The list of development tasks that describe the
team’s short-term plan is called the Sprint Backlog. The team might break into small groups to
do this planning. It’s more efficient for them that way.
Agree: Finally the whole team meets to make a final agreement on exactly how much they intend
to accomplish. It’s only after doing a sufficient amount of detailed planning that the team can be
confident it can complete the work. The amount of work the team can complete may be less than

128 Agile, Scrum, & What You Need to Know About Process
everyone hoped, so the team and product owner need to work together on this agreement. But,
it’s important that the plan is realistic.

3. The time-boxed sprint starts

A Scrum Sprint can be one (1) to four (4) weeks, sometimes a calendar month. Two (2) weeks is
common. But remember, the shorter the sprint, the faster you can learn and adapt.

The sprint is a fixed time-box. If all the work doesn’t

get done inside the time-box, the sprint still ends.
4. Every day the team inspects and adapts in a daily standup
Every workday is a short plan-do-check-act loop. So every morning, ideally before the team gets
to work on anything else, they stop to very quickly:
o Review what was accomplished yesterday
o Discuss any problems or “blockers” keeping things from getting done. Ideally the
team can decide how to solve these problems on their own. But if the problems
come from outside the team, it’s usually the Scrum Master who takes on solving
the problem.
o Plan what we’ll do today to move closer towards our sprint goal. This is a good time
for the team to coordinate, to make plans to work together in specific things
throughout the day.

The daily standup is for review and planning. If work

needs to be done or problems need to be handled,
decide who should do the work, do it after the standup.
5. The team keeps progress visible using task boards and burndown charts
If this was a game of football, the team could keep their eye on the ball. But, if we’re building
software it’s hard to see everyone’s progress and see where we can pitch in and help.
A Burndown Chart helps the team visualize its progress through all the Sprint Backlog items.

Burn Up Chart
25
Burn Down Chart
20
Tasks added 20

Tasks added
15
15
Tasks removed

10
10

5
5

Tasks removed
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10

A burndown chart shows how much work is left A variation of the burndown, a burnup chart
shows how much has been done and uses a
separate top line to show how much was
planned to do.

A Task Board shows the specific Sprint Backlog Item Tasks currently in progress, and who’s
working on them. We can see what’s left to do, and how much is done.

Agile, Scrum, & What You Need to Know About Process 129
 done
backlog backlog
items to do doing done items

delivery
team tasks

6. At the end of the sprint time-box, the team stops to review their work and
adapt their product, plan, and process.
At the end of the sprint, the team stops, and takes a few hours to relax, review, and reflect. This
meeting is called a Sprint Review, and sometimes Sprint Review and Retrospective. It has three
parts:
o Product: review the going in sprint goals, and the parts of the product the team has worked
together to build. Review means we really pull it up on the screen and take a look at it
running. Then we talk openly and honestly about the quality of the product:
UX: from a user experience perspective, how would we rate the quality?
Functional: from a functional perspective does the software perform as you expected?
Are there bugs? Would you likely find more if you had more testing time?
Engineering: is the code well written? Is it easy to maintain? Is it supported by
automated tests? Or, will you have problems the next time you try to edit or improve
the code?
o Plan: How much did you get done? Really finished, tested, and reviewed? Sometimes people
don’t agree on this and it takes creating an agreement called the “definition of done” that
we use as a checklist for determining if something is really done. The amount you really got
done is what lots of people call your delivery velocity.
o Process: how effectively did you work together? Are there specific things you could change
to create a higher quality product more predictably? Are there things that you could change
that would make everyday work more fun? As a team, discuss challenges, and decide on one
or two things to try doing differently for the next sprint. Then next time, start your process
discussion by discussing how well those things worked. This part of the sprint review often
gets called the Sprint Retrospective.

7. Repeat
Take a break, collect your thoughts, and then get started with the next sprint with a sprint
planning session.
You’ve built a portion of a working product each sprint. If you’re working on a new product or
large new feature, it may take several sprints to create enough to be viable in your market. If
you’ve already shipped a product, strive to make changes small enough that you could improve it
continuously, releasing something every sprint.

That’s it.
That’s all there is to using the simple Scrum Framework. It’s this simple iterative learning process
that forms a foundation we can build lots of other practices around.

Common Scrum and Agile practice has a blind spot

If your biggest challenges are figuring out what to build, you’ll need to use Scrum differently.

130 Agile, Scrum, & What You Need to Know About Process
Scrum applied simplistically seems to focus the team on building software. Teams often pay close
attention to their delivery velocity. But, building the wrong software predictably and at a high
quality really isn’t helping anyone.
In the remainder of this class we’ll talk about the work product owners lead to learn faster about
what the right things are to build. I’ll call that learning velocity.

The official, but evolving One of the easiest to read quick

definition of Scrum can be references on Scrum is: Scrum: a
found in The Scrum Guide. You Breathtakingly Brief and Agile
can read it in several languages Introduction by Chris Sims and
at: Hillary Louise Johnson
http://www.scrumguides.org/

Agile, Scrum, & What You Need to Know About Process 131
 Reading List
Product Management, Discovery, and Design
o Inspired: How To Create Products Customers Love, Marty Cagan
o Sense and Respond: How Successful Organizations Listen to Customers and Create
New Products Continuously, Jeff Gothelf & Josh Seiden
o Escaping the Build Trap: How Effective Product Management Creates Real Value,
Melissa Perri
o The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to
Create Radically Successful Businesses, Eric Ries
o Running Lean: Iterate from Plan A to a Plan That Works, Ash Maurya
o The Startup Owner's Manual: The Step-By-Step Guide for Building a Great
Company, Steve Blank
o Lean UX: Applying Lean Principles to Improve User Experience, Jeff Gothelf
o Talking To Humans: Success Starts With Understanding Your Customers, Giff
Constable
o Testing with Humans: How to use experiments to drive faster, more informed
decision making, Giff Constable
o UX for Lean Startups: Faster, Smarter User Experience Research and Design, Laura
Klein
o Lean Analytics: Use Data to Build a Better Startup Faster, Alistair Croll
o Value Proposition Design: How to Create Products and Services Customers Want,
Osterwalder et al
o Change by Design: How Design Thinking Transforms Organizations and Inspires
Innovation, Tim Brown
o User Story Mapping: Discover the Whole Story, Build the Right Product, Jeff Patton
o Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers, Dave
Gray, Sunni Brown, James Macanufo
o Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, Jake
Knapp, John Zeratsky, & Braden Kowitz

Agile Development and Scrum

o Agile Software Development: The Cooperative Game, Alistair Cockburn
o The Art of Agile Development, James Shore and Shane Warden
o Essential Scrum, Ken Rubin
o Specification by Example, Gojko Adzic
o The Scrum Guide, Schwaber & Sutherland: http://www.scrumguides.org/
o Core Scrum, The Scrum Alliance: https://www.scrumalliance.org/why-
scrum/core-scrum-values-roles
o Version One’s Agile Checklist:
http://www.versionone.com/pdf/AgileCheckList.pdf

Websites and Newsletters

o Pivot Product Hits: https://pivotservices.curated.co/
o Marty Cagan’s Newsletter: http://svpg.com/
o Mind the Product: http://www.mindtheproduct.com/

132 Agile, Scrum, & What You Need to Know About Process
Agile Development & Scrum
Principles and process guide
Agile Development is nothing new
The origins of agile thinking are as old as software development. What we call
“Agile Development” today is a contemporary word applied to a process style
that’s been emerging since the 1970s.
agile
Agile is a style of process and an umbrella
term for lots of specific processes

Waterfall considered risky Crystal

In his 1970s paper Winston Royce is credited with drawing the
DSDM
model we commonly think of as the “waterfall model.” But he
(Dynamic Systems Adaptive Software
Development Methodology)
drew the diagram in a progression on his way to more Development
sophisticated models. He pointed out that you’ll need

Scrum Extreme
feedback loops between every phase, and feedback all the
way from test back to requirements. Royce was trying to
describe an iterative development cycle, NOT a sequential
process. Programming
Lean Software
“I believe in this concept, but the
Development
FDD
implementation described above is risky and (Feature Driven
Development)
invites failure.”
--Royce it’s
gets this
“Agile” identifies specific
um
More like a team sport, Scr
e fr
nam paper!
om values and principles
less like an assembly line
In 2001 17 software professionals gathered to discuss what they
had in common. They were concerned about the continued
In the 1986 Harvard Business Review paper “The New New growth of formalized waterfall style process. These professionals
Product Development Game,” Takeuchi and Nonaka studied disagreed on specific process, but agreed strongly on the
a variety of product design teams and found that the most values and principles that drive process creation.
successful had derived a process that looked chaotic on the
Scrum was one of those agile processes. Today Scrum has
outside, but was ultimately faster and more effective at
grown in popularity. While teams may identify their process as
creating great products. They compared these teams work-
“Scrum.” the way they work borrows practices from most other
practice to the sport Rugby.
agile processes.
“Under the rugby approach, the product
The agile manifesto describes the values and
development process emerges from the constant principles that guide process decisions.
interaction of a hand-picked, multidisciplinary
team whose members work together from start
to finish.” – Takeuchi & Nonaka
Values & Principles
Guide Process
The Agile Manifesto: The principles of Agile development Values & Principles
Values describe what s important to individuals,
and collectively to an organization.
We are uncovering better ways of The principles of Agile Software Development, written the same time as
developing software by doing it and the manifesto, give principles that help guide choices in how we choose Principles are the rules of thumb we create and
helping others do it. Through this work we to work. use to make day-to-day process decisions.
have come to value:
1. Our highest priority is to satisfy the 7. Working software is the primary
customer through early and measure of progress.
Individuals and interactions continuous delivery of valuable
software.
8. Agile processes promote Your Context
over processes and tools sustainable development. The The process you follow needs to
2. Welcome changing requirements, sponsors, developers, and users take into account your context.
Working software even late in development. Agile should be able to maintain a
processes harness change for the constant pace indefinitely. • Haw many people are involved?
over comprehensive • How risky is the project?
customer's competitive
documentation advantage.
9. Continuous attention to technical • How time-sensitive is delivery?
excellence and good design • How difficult is the problem you re
3. Deliver working software frequently, enhances agility.
Customer collaboration from a couple of weeks to a
solving?
10. Simplicity--the art of maximizing • What does quality mean in your
over contract negotiation couple of months, with a the amount of work not done--is context?
preference to the shorter essential.
Responding to change timescale.
over following a plan 4. Business people and developers
must work together daily
11. The best architectures,
requirements, and designs emerge New Knowledge
from self-organizing teams. We continue to discover new concepts
That is, while there is value in the items on throughout the project. and leverage them to create new and
12. At regular intervals, the team
the right (below in this case), we value the 5. Build projects around motivated better practice and tools. For example:
reflects on how to become more
items on the left more (bold and above in individuals. Give them the effective, then tunes and adjusts its • A system s throughput is only as fast
this case). environment and support they behavior accordingly. as its slowest step so we use Kanban
need, and trust them to get the job
style boards to visualize the flow of
You can find the manifesto & principles at: done.
work and find bottlenecks faster.
http://agilemanifesto.org/ 6. The most efficient and effective • Product ideas are hypothetical until
method of conveying information proven out after delivery so we use
to and within a development team MVP Tests to validate product ideas
n’t to
goal is is face-to-face conversation. before delivery.
e m b er, the process, but
Rem an agile r high-
follow istently delive our Process & Practices
ns y
to co lity software love.
qua users Practices like test-driven development support
ers and values like being able to respond quickly to
custom change, and principles like technical excellence.

Processes combine practices that support each

other and are used by different roles.

Processes help many people coordinate their

© 2014, Jeff Patton • www.jpattonassociates.com activities to accomplish a common goal.
Roles
Agile processes and Scrum use three super roles that
satisfy the concerns of building the right product, the
product right, and tuning the process so people can
Scrum Master or Coach
The scrum master focuses on
process success
The Scrum Master focuses on making sure
the process is working, that everyone
understands and fills their role, that
Product Ownership
Product owners focus on product
success
A single person may have the title “product
owner,” but the ideal product owners is a
great leader. Since a successful product
collaboration is effective, that visibility is kept must be valuable, usable, and feasible, a
perform at their best. Traditional software development
high, and that the team keeps focus on the product owner usually leads a small product
roles are often mapped to one or more of these super
goals of the current sprint or iteration and ownership team that includes the skills and
roles. product release. roles needed to be successful:
Remember these roles represent concerns we all Product • Product manager or business
representative
share and not individual people. In healthy agile Ownership • UX practitioner
teams people will change hats from one role to Build the right • Engineer, architect, & tester
another. product
Scrum Master
Help everyone keep the
process working

Process
effectively The Delivery Team
The team focuses on constructing
Team a high quality product
Build the
The team is composed of all the roles and
product right
skills necessary to build, test, and document
software of sufficient quality that it could be
This starting process builds from the essential Scrum Framework to add practices released. This includes:
that wrap the sprint for product discovery, getting to ready, and getting to • engineers
release. • architects
• testers
Remember that process isn’t skill. Success or failure is up to the • business analysts
whole team. The right process gives just enough structure for teams • UI designers
to effectively collaborate. • technical writers

Product Product
Opportunity Discovery Product
Backlog
Development
Backlog Using collaboration, design thinking, and
Deliverable pieces
The product delivery team strives for predictable, high
quality, delivery.
Ideas to explore, and validated learning answer the questions:
of a product or
problems to solve. 1. What problems are we solving and for experiment we’d Product Team Story Workshop
who? like the team to
View your 2. What will customers and users value? build Planning Product team members
meet with delivery team
organization’s 3. What can users use to reach their goals? The product team meets member regularly to work
roadmap not as 4. What’s feasible to build given the tools routinely to discuss through story details and
and time we have? release progress, select agree on acceptance
fixed items to stories for upcoming
deliver, but as ideas criteria
The speed of Build sprints, and plan the work
to explore and discovery is experiments needed to get stories
validate. measured by cycle ready for the delivery
time of learning. team.
Try to experiment
Learn Measure opportunities
and learn several if your solution
& observe &
times per week. is viable
backlog backlog
items to do doing done items

Artifacts
While discovering, use opportunity
backlog items for high-fidelity Sprint
prototypes or live-data The de
turn bac
prototypes that requires
wo
development time to create backlog split & refined
item to get backlog
ready items

Artifacts, or things we see and touch. They help make information,

discovery
ideas, and status visible to the whole team. Basic artifacts include team tasks
backlogs, burndown charts, and task boards.
Release Burndown Product Team Task Board
If no one uses the artifacts, remove them because they’re Makes release progress visible. How much is Use to routinely plan and re-plan
likely not working. left to build before we can release? discovery work and work to get
items ready to deliver.

Product Discovery Getting to Ready

Pull from a backlog of opportunities use discovery work to To help the team move quickly and predictable, your
identify the product you should build. product team lead by a product owner must better
understand and describe the details of what to build.
• Understand the business motivation for building the
product • The product team plans by identifying user stories 1-3
• Understand the customers and users that will use your iterations in advance. They identify the work they’ll need
product and the problems your product solves for them to do to design and describe the software to build and
• Ideate: consider multiple solutions to solve your makes the work visible in a task board.
customer’s problems
• Iteratively build and test prototypes with your customers • Collaborating with the team using a story workshop
and users approach to build shared understanding about what to
• Use backlog items to develop higher fidelity and live- build. Members of the product team and delivery team
data prototypes where you’ll need development work work together to answer these three questions: What
• Describe your validated solution using stories in a exactly will be build? How will we know when we’re
product backlog you can use to manage the delivery of done? How will we demonstrate this new software to
your software. others?

Work together to explore details and Work together to explore details and describe
describe the software you want to build in the software you want to build in the next
the next time-box. time-box.
 Dual-Track Development
Discovery work happens continuously alongside development work.!
t

ct Opportunities drive
Scrum discovery
Master ! Discovery Track
ct Discovery cycles vary in length. They
d start with ideas, and end with
learning. You may complete several
cycles of discovery in a single week.
Discovery creates
backlog items for
experiments or
Development Track software to deliver
When you use Scrum for
development, you’ll see the
predictable delivery of working
software every 1-4 weeks Delivery results in
working experiments
ng or deliverable
software

d
ent
be
Discovery Team
A product owner leads the discovery team
that includes individuals that have the
knowledge and skills to identify a valuable,
usable, and feasible product. Daily Scrum
Day
Reflect on what was done
Individuals like lead engineers may be the prior day
part of both discovery and delivery Plan what to do today
The smallest cycle of
Raise issues stopping
teams work – you can’t
progress
extend this one if you
don’t finish what you

t
planned

op Sprint Planning Sprint Sprint Review & Customer & Stakeholder

A fixed time-box for delivering
ers
am
The product owner shows
up “ready” with details for software usually 1-4 weeks Retrospective User Product Product Review
work high priority backlog Demonstrate and critique
the working Product Testing Keep progress visible to
stakeholders outside the
nd items. The team builds Routinely validate the team
e their plan and commits. done
Discuss the Progress
backlog backlog working software with
items to do doing done items relative to the plan genuine users and
Delivery Team Reflect on the way customers
Task Board you’ve been working
Use to routinely (your Process) and
plan and re-plan change it as necessary
delivery work

Sprint
Backlog delivery
The delivery tasks
that turn backlog
team tasks
Potentially Shippable Viable Product
items into working
software
Software Increment Release
It may take more software to be Built iteratively and incrementally
valuable to users, but it had better each sprint, this is the product that’ll
not require more testing and bug get you the outcomes you want from
fixing the users you’ve targeted.
d Sprint Burndown
n Makes progress visible during this sprint. Are
we making progress?

Sprint Getting to Learn after

Monitor
Released
(Iteration or Development Time-box)
Iterations (Sprints in Scrum) are short fixed time-boxes,
usually 1-4 weeks. At the end of each iteration
Release Release Software
Almost every day
demonstrate finished, tested, high quality software. The team may be confident in what they’ve After the release monitor metrics and take a look at
built, but we’ll need to validate it with scorecards, and observe people using your metrics , bug reports,
• The team plans the sprint by working through the details customers, users and stakeholders. product. Remember, your project may be and customer
of what they’ll need to build over, but the life of your product has just feedback for
• Keep visibility high during the iteration using a task wall • Take working software out to customers
begun. software you’ve
or burn chart and users to test it. Is it valuable? Is it
already released
• Keep collaboration high between the product team usable?
• Keep progress and user feedback visible to The most valuable improvements
and delivery team
• At the end of the iteration use a product review to stakeholders. to your product come from
evaluate the product and discuss the pace of delivery, observing people using it today.
or velocity Continue validating the software
• Use a heartbeat retrospective to adjust your process. you’ve built with customers,
users, and stakeholders to avoid
Use Sprints to build software, measure, and
surprises at release time.
learn. Use what you learn to improve your
product, and the way you work.
Product Backlogs Using User Stories
User stories describe pieces of software
to deliver in the language of someone
who will use the software. A short story Capabilities or Stories for upcoming Working tested
title is written on a card, sticky, or in a
list as a token for conversation. Stories Features iterations software
split into smaller stories and gain more • Name • Priority • Meets the team s definition
detail over time and through many • Target customer or user • UI Design of done
conversations with contributors in every • Value • Business rules
role. • Acceptance tests Minimal
At minimum a story needs: Releasable
• Concise title
• Description Software
• Acceptance criteria • Generates value
from its use
This popular template helps to think
through stories from a user and
benefits perspective:
as a [type of user]
I want to [perform some action]
so that I can [reach some goal]

Use this template as a

thinking tool, not a writing
format. Stories without
concise titles become hard to
organize, discuss, and
prioritize.

Think about who uses the

software, what they ll do, Release-sized stories Small iteration- Validated product
and why.
•
•
Target release
Relative size sized stories part
• UI Sketches • Detailed acceptance tests • Vetted with stakeholders,
• Rough acceptance tests • Small enough to complete customers, and users
in a single iterations • Evaluated for release readiness

Organize user stories

as a map

Visible Progress Organize large capabilities

roughly in the order users use
them. Decompose them top to
bottom. This makes the backlog
easy to understand and easy to

Burn
prioritize.
A burn chart makes progress over time visible. A burn down
chart shows work remaining, while a burn up chart shows
work complete. Watching the slope of the curve on the

Charts chart lets us detect early if we re on track to finish all the

scheduled work on time.

Iteration
Day
Story Points Story Points Story Points
In Scope Completed Remaining Burn Down Chart Burn Up Chart
1 21 1 20 25
20
2 21 3 18 Stories added
3 21 6 15
4 24 8 16 20
5 24 9 15 15
Stories added
6 24 11 13
7 19 11 8
15
8
A spreadsheet
18
houses
13 5
10 Stories removed
9 18 15 3
the 10
daily totals
18 17 1
10
5

Daily Daily, usually at the start of the day,

the team meets for a short planning
meeting. Keep the meeting less 1
Stories removed
2 3 4 5 6 7 8 9 10
5

Standup than 15 minutes. Focus the

discussion on what it will take to
meet iteration goals. 1 2 3 4 5 6 7 8 9 10

or Daily Each person think about:

1.What you worked on yesterday

Scrum 2.What you plan to work on today

3.What issues you have blocking
them from getting work done
Stories
Task Wall Stories
In Tasks In Tasks
Ready
For Stories
A task wall is used to Queue Story Tasks Progress Complete Review Done
visualize work in progress
during the development
cycle. Moving stickies
across the wall helps the
team coordinate, and
signal progress to each
other and people outside
the team.