1. Passionate Product
Ownershipworking together to create successful products
Aaron Sanders
Cofounder, Comakers LLC
aaron@sanders.name:: @_aaron_sanders

2. www.comakewith.us :: youshould@comakewith.us
Get Started.
Jump right in.

3. www.comakewith.us :: youshould@comakewith.us
Let’s start with mapping an experience
you likely remember doing today
Step 1 - Brainstorm: List all the things you did to
get ready to be here today
 Starting from the moment you woke up until you
arrived here
 Using sticky notes, write the things you did, one
thing per sticky note
3

4. www.comakewith.us :: youshould@comakewith.us
We typically think about tasks

5. www.comakewith.us :: youshould@comakewith.us
There’s a “natural size” for tasks
* Cockburn’s Writing Effective Use Cases
describes goal levels for use cases this way

6. www.comakewith.us :: youshould@comakewith.us 6
Step 2: Organize
 Pair up with someone
 Combine and layout tasks
left-to-right, from start-to-finish
 Group similar tasks in separate columns
 De-dupe by choosing a representative sticky
for all identical tasks and toss the duplicates away
 Place smaller tasks under larger ones
“lather” and “rinse” might go under “wash hair”

7. www.comakewith.us :: youshould@comakewith.us 7
Step 2: Organize
 Find another pair and all four, do it
again
 Combine and layout tasks
left-to-right, from start-to-finish
 Group similar tasks in separate columns
 De-dupe by choosing a representative sticky
for all identical tasks and toss the duplicates away
 Place smaller tasks under larger ones
“lather” and “rinse” might go under “wash hair”

8. www.comakewith.us :: youshould@comakewith.us
We quickly built a
two-dimensional map
sub-tasks,
alternative
s,
variations,
and details
An
imperfect
narrative
flow

9. www.comakewith.us :: youshould@comakewith.us
Look together for groups of stickies that seem to go
together and create a higher-level label for those
 All the stuff done in the bathroom could be called
“bathing” and all the stuff done in the kitchen might
be “getting breakfast.”
 You may need to invent some names - what would
you call those things you do to get out of the door?
Gathering laptop, papers, car keys...
9
Step 3: Find Patterns

10. www.comakewith.us :: youshould@comakewith.us
We grouped tasks into activities

11. www.comakewith.us :: youshould@comakewith.us
Look back across the model of the whole
experience.
 Think about other mornings, besides this one.
 What about when you miss an important part of
getting ready? What if school was cancelled
because of weather? What else? What happened
then?
 What about alternate scenarios?
11
Step 4: Consider the “whatabouts”

12. www.comakewith.us :: youshould@comakewith.us
Look back across the model of the whole
experience for bright spots and challenges
 Agree on and write down the reason for the
highest point. Put it in on the related task and
give it a smiley face.
 Write a note about the lowest point. Put it on
the related task, with a frowny face.
12
Step 5: Mark high points and pains

13. www.comakewith.us :: youshould@comakewith.us
★Practice shared
understanding
★Collaborate effectively
★Build empathy with users
★Use Design Thinking
continually
★Practice deliberate
discovery
The Big
Goals:

14. www.comakewith.us :: youshould@comakewith.us
Shared
Understanding

15. www.comakewith.us :: youshould@comakewith.us
Modeling workshops follow a simple
flow
Introduce the objective of the workshop
1. Get information out of minds and on to
walls
2. Organize the information into similar
groups
3. Distill the information and find patterns
4. Find focus to engage in the best work
Summarize and record what you’ve learned

16. www.comakewith.us :: youshould@comakewith.us
Often when we verbally discuss ideas, we may
incorrectly believe we have the same
understanding

17. www.comakewith.us :: youshould@comakewith.us
Representing our ideas as models allows us
to detect inconsistencies in our
understanding

18. www.comakewith.us :: youshould@comakewith.us
Through discussion and iterative model
building we arrive at a stronger shared
understanding

19. www.comakewith.us :: youshould@comakewith.us
Using that common understanding we can
work together to arrive at the same
objectives

20. www.comakewith.us :: youshould@comakewith.us
Shared understanding and alignment are
the objectives of collaborative work

21. www.comakewith.us :: youshould@comakewith.us
Use models to support collaboration
 Affinity Diagrams
 Chronological Models
 Decompositions
 Ad Hoc Charts

22. www.comakewith.us :: youshould@comakewith.us
Blend model types and annotate
models to accurately represent your
ideas
22
mixing
annotating

23. www.comakewith.us :: youshould@comakewith.us
User Story
Mapping

24. Via Dilbert.com: http://www.dilbert.com/strips/comic/2003-01-10/
Stories started with XP in the late 1990s
In the late 1990s Kent Beck coined the term
“Story.” In Extreme Programming Explained
stories describe an alternative to working with
traditional requirements

25. www.comakewith.us :: youshould@comakewith.us
user
The original idea of a story was simple:
use it to facilitate a conversation
developer

26. www.comakewith.us :: youshould@comakewith.us
Stories are a deceptively simple idea
 Told from a user’s perspective of what’s
needed
 Intentionally inviting conversation
 Revealing information and agreeing how to
proceed
That’s it.

27. www.comakewith.us :: youshould@comakewith.us
Stories gain detail over time and from
conversation - don’t add all your details at
once
Start with a short title
Add a concise description
Think about who, what, and why -
some use this useful template:
 As a [type of user]
 I want to [perform some task]
 so that I can [reach some goal]
Add other relevant notes,
specifications, or sketches
Before building software write
acceptance criteria (how would
we demo this?)
27

28. www.comakewith.us :: youshould@comakewith.us
Tell stories, don’t just write stories
What I was thinking of was the way
users sometimes tell stories about the
cool new things the software they use
does:
“I type in the zip code and
it automatically fills in the
city and state without me
having to touch a button!”
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?

29. www.comakewith.us :: youshould@comakewith.us
User context builds through a simple
process
Identify Types of
Users
•Determine the criteria that makes
each type distinct
•Identify high priority or “focal”
types
Profile User Types
•Identify information about users
relevant to product design
Personify User Types
•Leverage what you understand about
users to describe a realistic example
of your users
Identify Product Design Impact
•Name characteristics the software must have to be valuable to users as
design imperatives
•Name valuable product features ideas or opportunities

30. www.comakewith.us :: youshould@comakewith.us
Segment your users to help focus your
product design and planning
Look for differences that make a difference in product
use

31. www.comakewith.us :: youshould@comakewith.us
Sketch a pragmatic persona thinking
about someone different from yourself
(sort of)

32. www.comakewith.us :: youshould@comakewith.us
Creating personas can be fast and
collaborative

33. www.comakewith.us :: youshould@comakewith.us
Empathy maps organize conversations
about target users
Do

34. www.comakewith.us :: youshould@comakewith.us
A Story Map helps facilitate discussion
about user’s experience with our
product
Gary Levitt, owner & designer of Mad Mimi
34
product goals
(why build the
product)
users
(what are their goals)

35. www.comakewith.us :: youshould@comakewith.us
Product
Ownership Team

36. Agile values & principles motivate
agile process
Individuals & Interactions Working
Software Customer
Collaboration Responding to Change
Sustainable Development Technical
Excellence Simplicity Self-Organizing
Teams Reflection
Early and Continuous
Delivery
Welcoming Changing Requirements
Business People and Developers Work Together 14

37. www.comakewith.us :: youshould@comakewith.us
The simple
Scrum
process
framework

38. www.comakewith.us :: youshould@comakewith.us
“incrementing” builds a bit at a time
1 2 3 4 5
Incrementing calls for a fully
formed idea.
And, doing it on time requires
dead accurate estimation.
38

39. www.comakewith.us :: youshould@comakewith.us
“iterating” and “incrementing” builds a rough
version, validates it, then slowly builds up
quality
1 2 3
Iterating allows for movement
from vague idea to realization
with course corrections along
the way.
4 5
39

40. time
www.comakewith.us :: youshould@comakewith.us
Work like an artist to envision and build
the product holistically
40
“Art is never finished,
only abandoned.”
-Leonardo DaVinci

41. www.comakewith.us :: youshould@comakewith.us
End Game
Over time the value of
stories begin to diminish
signaling it’s time for
release
Mid Game
Once we’re confident
we have the “shape”
of the product right, we
begin to pile in value
Opening
Game
Early stories emphasize
iteration and learning.
We need to be sure
we’re building the right
product
Organize work to maximize learning
The inverse of
risk is
knowledge
Learning earlier
if we’re building
the right
product
mitigates risk
time
acquiredproductknowledge
41

42. www.comakewith.us :: youshould@comakewith.us
Slice a first release into opening, mid,
and end-game stores
Expose your delivery strategy within a release by slicing the
release into:
 opening game: stories that build up a walling skeleton and
reduce risk
 mid game: stories that build out features, and fatten up
features
 end game: stories that refine and tighten up the product for
release
opening-
game
stories
mid-game
stories
end-game
stories

43. www.comakewith.us :: youshould@comakewith.us193 43
Many organizations consider revising the same
functionality as failure. Iteration is not
tolerated.

44. www.comakewith.us :: youshould@comakewith.us
The Product Owner
Role

45. www.comakewith.us :: youshould@comakewith.us
A good product blends three important
concerns and the skills to fill them
Valuable
Usable
Feasible

46. www.comakewith.us :: youshould@comakewith.us
Product ownership blends a diverse set of skills and
concerns – more than can fit in one head
• Business Advocate
• Customer Advocate
• End User Advocate
• Subject Matter Expert
• Analyst
• Designer
• Visionary
• Communicator
• Decision Maker
26
Since it’s a rare individual that can effectively
wear all these hats, the Product Owner role is
generally filled by a person supported by a
collaborative team
46

47. www.comakewith.us :: youshould@comakewith.us
A cross functional product ownership
team directs discovery
Your discovery
team should
move forward to
be your core
product
ownership team

48. www.comakewith.us :: youshould@comakewith.us
At scale it takes teams of teams of
product owners
Product
ownership
team
Discovery team
Product
owner
Delivery
team
Chief product
owner
Strategic product ownership team
Senior
architect
Senior UX
practitioner

49. www.comakewith.us :: youshould@comakewith.us
Effective Collaboration Workshops
Take Preparation
Express shared understanding
Require everyone’s participation
Have an expert facilitator and coach
Keep the work highly visible

50. www.comakewith.us :: youshould@comakewith.us
Collaborative workshops involve
stakeholders, users, and the delivery
team

51. www.comakewith.us :: youshould@comakewith.us
Discovery workshop participants
Business stakeholders remind us of
business benefit and product
strategy
Product users, subject matter
experts, and user researchers give
user insights
Delivery team members break
down work, design solutions,
evaluate product feasibility, and plan
delivery

52. www.comakewith.us :: youshould@comakewith.us
Use pairing and small groups to speed up
workshop collaboration

53. www.comakewith.us :: youshould@comakewith.us
Process ≠ skill
We tried
baseball
and it
didn’t
work
No one expects to be good at a game without
practice
There’s no game-winning process
Jeffries, We tried baseball: http://xprogramming.com/articles/jatbaseball/

54. www.comakewith.us :: youshould@comakewith.us
Brought to you by the letter “T”
Breadth of skills
Depth of expertiseFast Company, Strategy By Design
http://www.fastcompany.com/magazine/95/design-strategy.html

55. www.comakewith.us :: youshould@comakewith.us
Games have
Simple Rules
Almost anyone can learn to play
The sophistication comes from strategies and
tactics used by skilled players and coaches

56. www.comakewith.us :: youshould@comakewith.us
Games have
Positions not Roles
Players on a sports team build deep
specialization
but maintain general skills to play many
positions

57. www.comakewith.us :: youshould@comakewith.us
Games have
Clear Objectives
We know what winning the game means
Playing our position well while our team loses
isn’t considered success

58. www.comakewith.us :: youshould@comakewith.us
Discovery Balances
Development

59. www.comakewith.us :: youshould@comakewith.us
Discovery balances development
Discovery Development
Learns:
•What will customers and
users value?
•Can they easily use the
solution to meet their
needs?
•Is it feasible to build with
the tools and time we’ve
budgeted?
Makes:
•Describe and plan
details
•Design, develop, and
test
•Measure
development speed &
evaluate progress
•Evaluate quality

60. www.comakewith.us :: youshould@comakewith.us
Disscovery & Design Thinking

61. www.comakewith.us :: youshould@comakewith.us
Product
Opportunities &
User Research

62. www.comakewith.us :: youshould@comakewith.us
Winning the long game takes
more than a single cycle

63. www.comakewith.us :: youshould@comakewith.us
Maximize outcome and impact

64. www.comakewith.us :: youshould@comakewith.us
Deciding relevant context is
prioritization
software
product
use
(activities & tasks)
users (goals)
organization
(goals)
product
context
software
solution
customer
(value proposition)
64

65. www.comakewith.us :: youshould@comakewith.us
Spend a lot of time talking not about what to
build, but the solution context
Business &
Product
Strategy
Customer
Segments
Users & user
goals
Product
usages
Regulatory
constraints
Legacy product and
architecture
?What else?
65

66. www.comakewith.us :: youshould@comakewith.us

67. www.comakewith.us :: youshould@comakewith.us
Create a simple product brief to build
common understanding and set goals
What
 What product are you working with?
 What specific capability of the product will you be focusing on?
Who
 What types of customers or organizations buy the product? What
benefit do they get?
 What types of people or roles use your product? How do they
benefit?
Why
 How will the business paying for the software to be built benefit?
 Metrics
 How will we measure success? What will we see change in the world after
the product ships?

68. www.comakewith.us :: youshould@comakewith.us
Cagan’s Opportunity Assessment
Exactly what problem will this solve? (value proposition)
For whom do we solve that problem? (target market)
How will we measure success? (business metrics)
How big is the opportunity? (market size)
What alternatives are out there? (competitive landscape)
Why are we best suited to pursue this? (our differentiator)
Why now? (market window)
How will we launch this product? (go to market strategy)
What factors are critical to success? (solution requirements/risks)
Given the above, what’s the recommendation? (go or no-go)
read more at: http://www.svpg.com/assessing-product-opportunities/

69. www.comakewith.us :: youshould@comakewith.us
Product Scorecard
A collection of key performance indicators (outcome-centric
metrics) that product managers, and the organization, use to
make product decisions:
Example Scorecard (via Marty Cagan):
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
Keep the list short: 4-6 internal
Prioritize KPIs to reflect product strategy

70. www.comakewith.us :: youshould@comakewith.us
Plan by slicing the map into holistic
valuable releases

71. www.comakewith.us :: youshould@comakewith.us
Adding tape lines to the wall lets
participants organize stories into layers

72. www.comakewith.us :: youshould@comakewith.us
Slice the map into viable incremental
releases
Focus each release on target
users and specific business-
level outcomes
named product
outcomes for each
release

73. www.comakewith.us :: youshould@comakewith.us
Use target personas to drive release
strategy
Target a primary persona for a first release
For a target persona, try a “good-better-best”
strategy
73

74. www.comakewith.us :: youshould@comakewith.us
Segment your audience to reduce
release size
Photo courtesy of SnagAJob.com
R1: Subset of the
initial target market
R2: What’s
needed to expand
to the original target

75. www.comakewith.us :: youshould@comakewith.us
Minimal Viable Releases target success
for a product with a specific target
audience
MVP: Minimal Viable Product
MMF: Minimal Marketable Feature
To thin a release, first reduce the size of your target
market
MVP
1 or more
MMFs
75

76. www.comakewith.us :: youshould@comakewith.us
Where are features in the map?
Features are threaded through the user’s
experience
MVP
1 or more
MMFs
76

77. www.comakewith.us :: youshould@comakewith.us
Planning incremental releases can be a
whole team event
77

78. release cycle
develo
pment
cycle
Defer letting stories get too small or
detailed until delivery
Discovery
Delivery

79. www.comakewith.us :: youshould@comakewith.us
what:
who:
why:
what:
who:
why: Story Map Product
Use
R1
R2
R3
Opportunity
Backlog
Contains valuable product and
feature ideas
Product Discovery
Research, explore, validate and
plan delivery of potential product
solutions
what:
who:
why:
R2what:
who:
why:
R3what:
who:
why:
Sketch, then
Prototype & Test
UI
Sketch &
Prototype
Technical Solutions
Target Product
Outcomes
Target Customers &
Users
Identify Viable
Product Releases &
Experiments
Product
Development
Technical prototyping and solution
development driven by discovery stocks
Product Discovery wraps Development
Product
Backlog

80. www.comakewith.us :: youshould@comakewith.us
Continuous
discovery
validates learning
so that we can
deliver the right
outcomes

81. www.comakewith.us :: youshould@comakewith.us
Summarize using photos or short
movies
57
You had to be there
 Models are most meaningful to those who participated
Photograph models as mementos
 A photo helps participants recall the discussion that occurred when they created of the
model
Record short movies
 A movie of 5 minutes or less, where a participant reviews the model, stands in for more
formal documentation

82. www.comakewith.us :: youshould@comakewith.us
Create a research plan to fill in unknown
and uncertain context
Given assumption based profiles, you can identify the areas where
your information is sparse or incomplete. You can use research to
backfill your profiles with facts in critical areas.
 Interviewing users from target user groups
 Observing users
 Questionnaires
 Existing published demographics
 Existing published research
 Customer service records
 and representatives
 Sales and marketing
 Usability testing
 Focus groups
facts

83. www.comakewith.us :: youshould@comakewith.us
Research informally and in context

84. www.comakewith.us :: youshould@comakewith.us
Go to where the product is used

85. www.comakewith.us :: youshould@comakewith.us
Include the whole team in research

86. www.comakewith.us :: youshould@comakewith.us
Story maps can start with a description of
people’s experience today, before there’s
even a product
* Narrative Journey Map
courtesy Duncan Brown of
the Caplin Group

87. www.comakewith.us :: youshould@comakewith.us
Story maps morph with information
* Narrative Journey Map
courtesy Duncan Brown of
the Caplin Group

88. www.comakewith.us :: youshould@comakewith.us
Segmenting using characteristics and
continuums
What I spend
is a concern
Don’t care what
I spend
I’ve got kids
and a family We’re all adults
here
I like organizing
a group of
friends
I just go with a
friend or people
close to me
I plan things in
advance
I do things at the
last moment

89. www.comakewith.us :: youshould@comakewith.us
Solution Ideation &
Description

90. www.comakewith.us :: youshould@comakewith.us
Discovery is a design thinking process
1. Understand the
problem
2. Identify
Solutions
(Ideate!)
3. Refine and
Validate
(Iterate!)
4. Create a plan

91. www.comakewith.us :: youshould@comakewith.us
A design studio approach engages the
whole team in sketching

92. www.comakewith.us :: youshould@comakewith.us
Sketch independently

93. www.comakewith.us :: youshould@comakewith.us
Everyone shares their results

94. www.comakewith.us :: youshould@comakewith.us
Find the best ideas (not the best artist)

95. www.comakewith.us :: youshould@comakewith.us
Practices to sketch experience
User scenarios
(which is actually just writing)
design comics
user interface story board
single screen ideation
single screen exploration

96. www.comakewith.us :: youshould@comakewith.us
Comic Booking sets a user scenario to
pictures
See www.designcomics.org for clipart and examples
97

97. www.comakewith.us :: youshould@comakewith.us
UI Storyboard from Margarete Fuss, SAP AG

98. www.comakewith.us :: youshould@comakewith.us
Example storyboard from Arie Stavchansky,
http://stavchansky.net

99. www.comakewith.us :: youshould@comakewith.us
Single screen or concept ideation
explores many variations of the same
thing
Ideation

100. www.comakewith.us :: youshould@comakewith.us
Dive deep into a single screen or concept
to explore complex design
Deep dive sketch by Mike Rohde,
CommLogix

101. www.comakewith.us :: youshould@comakewith.us
Now it’s time for you to sketch

102. www.comakewith.us :: youshould@comakewith.us
Critique the ideas relative to the design
target
<persona> would like this because....
How would <persona> use this to solve their
problems?
How would <persona> use this to get to
<outcome>, or help us reach our goal of
<benefit>?
only critique for magic is, “that sounds plausible!”,
if you can think of a way to make it real.

103. www.comakewith.us :: youshould@comakewith.us
Stand back and facilitate
“Design by community is not
design by committee.”
-- Leisa ReicheltLeisa Reichelt
www.disambiguity.com
Leah Buley
www.adaptivepath.com/aboutus/leah.php
“Design isn’t something that
designers produce, design is a
process that designers
facilitate.”
--Leah Buley
You still own
the outcome

104. www.comakewith.us :: youshould@comakewith.us
Incremental releases allow us to get
value from the market sooner
Big Product Idea Incremental Release
Strategy
1.
2.
3.

105. www.comakewith.us :: youshould@comakewith.us
Value from building backlog items comes
from learning
Minimal Viable Release Product Backlog built
from small stories

106. www.comakewith.us :: youshould@comakewith.us
Test hypotheses with prototypes

107. www.comakewith.us :: youshould@comakewith.us
Product Detail

108. www.comakewith.us :: youshould@comakewith.us
Stories have a simple lifecycle
! ?
Card
Conversation
!
Confirmation
Consequences
! ??
!
Construction
* Ron Jeffries coined the
3 C’s in Extreme
Programming Installed

109. www.comakewith.us :: youshould@comakewith.us
All things to all people
user developer
product manager
tester
PM
BA
UX
Designer

110. www.comakewith.us :: youshould@comakewith.us
user
Stories need to support lots of
conversations across lots of project roles
developer
product manager
testerPM
BA
UX Designer

111. BA
www.comakewith.us :: youshould@comakewith.us
user
testerPM
UX Designer
Stories need to support lots of
conversations across lots of project roles
developer
product manager

112. www.comakewith.us :: youshould@comakewith.us
user
product
manager
The natural “unit of measure” for
stories varies by conversation
BA or
UI Designer
developer
business
leader

113. www.comakewith.us :: youshould@comakewith.us
different
people
2. need
different
details to
support
different
people’s work
3. have a
different

114. www.comakewith.us :: youshould@comakewith.us
User Stories are boundary objects
Here’s the fine print on boundary objects:
“A boundary object is a concept in sociology to describe information
used in different ways by different communities. They are plastic,
interpreted differently across communities but with enough
immutable content to maintain integrity” --Wikipedia
“They are weakly structured in common use, and become
strongly structured in individual-site use. They may be abstract or
concrete. They have different meanings in different social worlds but
their structure is common enough to more than one world to make them
recognizable means of translation. The creation and management of
boundary objects is key in developing and maintaining coherence across
intersecting social worlds.”
-- Leigh & Griesemer

115. www.comakewith.us :: youshould@comakewith.us
1. Express stories
in a language
most people can
understand
2. Keep stories of
different sizes
in your backlog
to support
different
conversations
3. Save your

116. release cycle
develo
pment
cycle
User Stories shrink in size and grow in
detail as they travel through a pipeline
Capabilities
or features
•Name
•Target customer or
user
•Value
Release-
sized stories
•Target release
•Relative size
•UI sketches
•Rough acceptance
tests
Stories for
upcoming
iterations
•Priority
•UI design
•Business rules
•Acceptance tests
Iteration-
sized stories
•Detailed
acceptance tests
•Small enough to
complete in an
iteration
Working
tested
software
•Meets the team’s
definition of done
Validated
product parts
•Vetted with customers
and users
•Evaluated for release
readiness
Minimal
releasable
software
•Generates value
from its use

117. release cycle
develo
pment
cycle
User Stories shrink in size and grow in
detail as they travel through a pipeline

118. release cycle
iterat
ion
User Stories shrink in size and grow in
detail as they travel through a pipeline
Just-in-time
refinement
Automation &
continuous
delivery