Passionate Product Ownership

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

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

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

We typically think about tasks

There’s a “natural size” for tasks
* Cockburn’s Writing Effective Use Cases
describes goal levels for use cases this way

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”

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”

We quickly built a
two-dimensional map
sub-tasks,
alternative
s,
variations,
and details
An
imperfect
narrative
flow

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

We grouped tasks into activities

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”

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

★Practice shared
understanding
★Collaborate effectively
★Build empathy with users
★Use Design Thinking
continually
★Practice deliberate
discovery
The Big
Goals:

Shared
Understanding

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

Often when we verbally discuss ideas, we may
incorrectly believe we have the same
understanding

Representing our ideas as models allows us
to detect inconsistencies in our
understanding

Through discussion and iterative model
building we arrive at a stronger shared
understanding

Using that common understanding we can
work together to arrive at the same
objectives

Shared understanding and alignment are
the objectives of collaborative work

Use models to support collaboration
 Affinity Diagrams
 Chronological Models
 Decompositions
 Ad Hoc Charts

Blend model types and annotate
models to accurately represent your
ideas
22
mixing
annotating

User Story
Mapping

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

user
The original idea of a story was simple:
use it to facilitate a conversation
developer

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.

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

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?

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

Segment your users to help focus your
product design and planning
Look for differences that make a difference in product
use

Sketch a pragmatic persona thinking
about someone different from yourself
(sort of)

Creating personas can be fast and
collaborative

Empathy maps organize conversations
about target users
Do

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)

Product
Ownership Team

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

The simple
Scrum
process
framework

“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

“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

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

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

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

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

The Product Owner
Role

A good product blends three important
concerns and the skills to fill them
Valuable
Usable
Feasible

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

A cross functional product ownership
team directs discovery
Your discovery
team should
move forward to
be your core
product
ownership team

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

Effective Collaboration Workshops
Take Preparation
Express shared understanding
Require everyone’s participation
Have an expert facilitator and coach
Keep the work highly visible

Collaborative workshops involve
stakeholders, users, and the delivery
team

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

Use pairing and small groups to speed up
workshop collaboration

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/

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

Games have
Simple Rules
Almost anyone can learn to play
The sophistication comes from strategies and
tactics used by skilled players and coaches

Games have
Positions not Roles
Players on a sports team build deep
specialization
but maintain general skills to play many
positions

Games have
Clear Objectives
We know what winning the game means
Playing our position well while our team loses
isn’t considered success

Discovery Balances
Development

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

Disscovery & Design Thinking

Product
Opportunities &
User Research

Winning the long game takes
more than a single cycle

Maximize outcome and impact

Deciding relevant context is
prioritization
software
product
use
(activities & tasks)
users (goals)
organization
(goals)
product
context
software
solution
customer
(value proposition)
64

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

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?

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/

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

Plan by slicing the map into holistic
valuable releases

Adding tape lines to the wall lets
participants organize stories into layers

Slice the map into viable incremental
releases
Focus each release on target
users and specific business-
level outcomes
named product
outcomes for each
release

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

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

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

Where are features in the map?
Features are threaded through the user’s
experience
MVP
1 or more
MMFs
76

Planning incremental releases can be a
whole team event
77

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

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

Continuous
discovery
validates learning
so that we can
deliver the right
outcomes

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

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

Research informally and in context

Go to where the product is used

Include the whole team in research

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

Story maps morph with information
* Narrative Journey Map
courtesy Duncan Brown of
the Caplin Group

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

Solution Ideation &
Description

Discovery is a design thinking process
1. Understand the
problem
2. Identify
Solutions
(Ideate!)
3. Refine and
Validate
(Iterate!)
4. Create a plan

A design studio approach engages the
whole team in sketching

Sketch independently

Everyone shares their results

Find the best ideas (not the best artist)

Practices to sketch experience
User scenarios
(which is actually just writing)
design comics
user interface story board
single screen ideation
single screen exploration

Comic Booking sets a user scenario to
pictures
See www.designcomics.org for clipart and examples
97

UI Storyboard from Margarete Fuss, SAP AG

Example storyboard from Arie Stavchansky,
http://stavchansky.net

Single screen or concept ideation
explores many variations of the same
thing
Ideation

Dive deep into a single screen or concept
to explore complex design
Deep dive sketch by Mike Rohde,
CommLogix

Now it’s time for you to sketch

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.

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

Incremental releases allow us to get
value from the market sooner
Big Product Idea Incremental Release
Strategy
1.
2.
3.

Value from building backlog items comes
from learning
Minimal Viable Release Product Backlog built
from small stories

Test hypotheses with prototypes

Product Detail

Stories have a simple lifecycle
! ?
Card
Conversation
!
Confirmation
Consequences
! ??
!
Construction
* Ron Jeffries coined the
3 C’s in Extreme
Programming Installed

All things to all people
user developer
product manager
tester
PM
BA
UX
Designer

user
Stories need to support lots of
conversations across lots of project roles
developer
product manager
testerPM
BA
UX Designer

BA
user
testerPM
UX Designer
Stories need to support lots of
conversations across lots of project roles
developer
product manager

user
product
manager
The natural “unit of measure” for
stories varies by conversation
BA or
UI Designer
developer
business
leader

different
people
2. need
different
details to
support
different
people’s work
3. have a
different

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

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

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

release cycle
develo
pment
cycle

release cycle
iterat
ion
Just-in-time
refinement
Automation &
continuous
delivery

Passionate Product Ownership

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Passionate Product Ownership

Semelhante a Passionate Product Ownership (20)

Último

Último (20)

Passionate Product Ownership