Passionate Product
Ownershipworking together to create successful products
Aaron Sanders
Cofounder, Comakers LLC
aaron@san...
www.comakewith.us :: youshould@comakewith.us
Get Started.
Jump right in.
www.comakewith.us :: youshould@comakewith.us
Let’s start with mapping an experience
you likely remember doing today
Step 1...
www.comakewith.us :: youshould@comakewith.us
We typically think about tasks
www.comakewith.us :: youshould@comakewith.us
There’s a “natural size” for tasks
* Cockburn’s Writing Effective Use Cases
d...
www.comakewith.us :: youshould@comakewith.us 6
Step 2: Organize
 Pair up with someone
 Combine and layout tasks
left-to-...
www.comakewith.us :: youshould@comakewith.us 7
Step 2: Organize
 Find another pair and all four, do it
again
 Combine an...
www.comakewith.us :: youshould@comakewith.us
We quickly built a
two-dimensional map
sub-tasks,
alternative
s,
variations,
...
www.comakewith.us :: youshould@comakewith.us
Look together for groups of stickies that seem to go
together and create a hi...
www.comakewith.us :: youshould@comakewith.us
We grouped tasks into activities
www.comakewith.us :: youshould@comakewith.us
Look back across the model of the whole
experience.
 Think about other morni...
www.comakewith.us :: youshould@comakewith.us
Look back across the model of the whole
experience for bright spots and chall...
www.comakewith.us :: youshould@comakewith.us
★Practice shared
understanding
★Collaborate effectively
★Build empathy with u...
www.comakewith.us :: youshould@comakewith.us
Shared
Understanding
www.comakewith.us :: youshould@comakewith.us
Modeling workshops follow a simple
flow
Introduce the objective of the worksh...
www.comakewith.us :: youshould@comakewith.us
Often when we verbally discuss ideas, we may
incorrectly believe we have the ...
www.comakewith.us :: youshould@comakewith.us
Representing our ideas as models allows us
to detect inconsistencies in our
u...
www.comakewith.us :: youshould@comakewith.us
Through discussion and iterative model
building we arrive at a stronger share...
www.comakewith.us :: youshould@comakewith.us
Using that common understanding we can
work together to arrive at the same
ob...
www.comakewith.us :: youshould@comakewith.us
Shared understanding and alignment are
the objectives of collaborative work
www.comakewith.us :: youshould@comakewith.us
Use models to support collaboration
 Affinity Diagrams
 Chronological Model...
www.comakewith.us :: youshould@comakewith.us
Blend model types and annotate
models to accurately represent your
ideas
22
m...
www.comakewith.us :: youshould@comakewith.us
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 199...
www.comakewith.us :: youshould@comakewith.us
user
The original idea of a story was simple:
use it to facilitate a conversa...
www.comakewith.us :: youshould@comakewith.us
Stories are a deceptively simple idea
 Told from a user’s perspective of wha...
www.comakewith.us :: youshould@comakewith.us
Stories gain detail over time and from
conversation - don’t add all your deta...
www.comakewith.us :: youshould@comakewith.us
Tell stories, don’t just write stories
What I was thinking of was the way
use...
www.comakewith.us :: youshould@comakewith.us
User context builds through a simple
process
Identify Types of
Users
•Determi...
www.comakewith.us :: youshould@comakewith.us
Segment your users to help focus your
product design and planning
Look for di...
www.comakewith.us :: youshould@comakewith.us
Sketch a pragmatic persona thinking
about someone different from yourself
(so...
www.comakewith.us :: youshould@comakewith.us
Creating personas can be fast and
collaborative
www.comakewith.us :: youshould@comakewith.us
Empathy maps organize conversations
about target users
Do
www.comakewith.us :: youshould@comakewith.us
A Story Map helps facilitate discussion
about user’s experience with our
prod...
www.comakewith.us :: youshould@comakewith.us
Product
Ownership Team
Agile values & principles motivate
agile process
Individuals & Interactions Working
Software Customer
Collaboration Respon...
www.comakewith.us :: youshould@comakewith.us
The simple
Scrum
process
framework
www.comakewith.us :: youshould@comakewith.us
“incrementing” builds a bit at a time
1 2 3 4 5
Incrementing calls for a full...
www.comakewith.us :: youshould@comakewith.us
“iterating” and “incrementing” builds a rough
version, validates it, then slo...
time
www.comakewith.us :: youshould@comakewith.us
Work like an artist to envision and build
the product holistically
40
“A...
www.comakewith.us :: youshould@comakewith.us
End Game
Over time the value of
stories begin to diminish
signaling it’s time...
www.comakewith.us :: youshould@comakewith.us
Slice a first release into opening, mid,
and end-game stores
Expose your deli...
www.comakewith.us :: youshould@comakewith.us193 43
Many organizations consider revising the same
functionality as failure....
www.comakewith.us :: youshould@comakewith.us
The Product Owner
Role
www.comakewith.us :: youshould@comakewith.us
A good product blends three important
concerns and the skills to fill them
Va...
www.comakewith.us :: youshould@comakewith.us
Product ownership blends a diverse set of skills and
concerns – more than can...
www.comakewith.us :: youshould@comakewith.us
A cross functional product ownership
team directs discovery
Your discovery
te...
www.comakewith.us :: youshould@comakewith.us
At scale it takes teams of teams of
product owners
Product
ownership
team
Dis...
www.comakewith.us :: youshould@comakewith.us
Effective Collaboration Workshops
Take Preparation
Express shared understandi...
www.comakewith.us :: youshould@comakewith.us
Collaborative workshops involve
stakeholders, users, and the delivery
team
www.comakewith.us :: youshould@comakewith.us
Discovery workshop participants
Business stakeholders remind us of
business b...
www.comakewith.us :: youshould@comakewith.us
Use pairing and small groups to speed up
workshop collaboration
www.comakewith.us :: youshould@comakewith.us
Process ≠ skill
We tried
baseball
and it
didn’t
work
No one expects to be goo...
www.comakewith.us :: youshould@comakewith.us
Brought to you by the letter “T”
Breadth of skills
Depth of expertiseFast Com...
www.comakewith.us :: youshould@comakewith.us
Games have
Simple Rules
Almost anyone can learn to play
The sophistication co...
www.comakewith.us :: youshould@comakewith.us
Games have
Positions not Roles
Players on a sports team build deep
specializa...
www.comakewith.us :: youshould@comakewith.us
Games have
Clear Objectives
We know what winning the game means
Playing our p...
www.comakewith.us :: youshould@comakewith.us
Discovery Balances
Development
www.comakewith.us :: youshould@comakewith.us
Discovery balances development
Discovery Development
Learns:
•What will custo...
www.comakewith.us :: youshould@comakewith.us
Disscovery & Design Thinking
www.comakewith.us :: youshould@comakewith.us
Product
Opportunities &
User Research
www.comakewith.us :: youshould@comakewith.us
Winning the long game takes
more than a single cycle
www.comakewith.us :: youshould@comakewith.us
Maximize outcome and impact
www.comakewith.us :: youshould@comakewith.us
Deciding relevant context is
prioritization
software
product
use
(activities ...
www.comakewith.us :: youshould@comakewith.us
Spend a lot of time talking not about what to
build, but the solution context...
www.comakewith.us :: youshould@comakewith.us
www.comakewith.us :: youshould@comakewith.us
Create a simple product brief to build
common understanding and set goals
Wha...
www.comakewith.us :: youshould@comakewith.us
Cagan’s Opportunity Assessment
Exactly what problem will this solve? (value p...
www.comakewith.us :: youshould@comakewith.us
Product Scorecard
A collection of key performance indicators (outcome-centric...
www.comakewith.us :: youshould@comakewith.us
Plan by slicing the map into holistic
valuable releases
www.comakewith.us :: youshould@comakewith.us
Adding tape lines to the wall lets
participants organize stories into layers
www.comakewith.us :: youshould@comakewith.us
Slice the map into viable incremental
releases
Focus each release on target
u...
www.comakewith.us :: youshould@comakewith.us
Use target personas to drive release
strategy
Target a primary persona for a ...
www.comakewith.us :: youshould@comakewith.us
Segment your audience to reduce
release size
Photo courtesy of SnagAJob.com
R...
www.comakewith.us :: youshould@comakewith.us
Minimal Viable Releases target success
for a product with a specific target
a...
www.comakewith.us :: youshould@comakewith.us
Where are features in the map?
Features are threaded through the user’s
exper...
www.comakewith.us :: youshould@comakewith.us
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
www.comakewith.us :: youshould@comakewith.us
what:
who:
why:
what:
who:
why: Story Map Product
Use
R1
R2
R3
Opportunity
Ba...
www.comakewith.us :: youshould@comakewith.us
Continuous
discovery
validates learning
so that we can
deliver the right
outc...
www.comakewith.us :: youshould@comakewith.us
Summarize using photos or short
movies
57
You had to be there
 Models are mo...
www.comakewith.us :: youshould@comakewith.us
Create a research plan to fill in unknown
and uncertain context
Given assumpt...
www.comakewith.us :: youshould@comakewith.us
Research informally and in context
www.comakewith.us :: youshould@comakewith.us
Go to where the product is used
www.comakewith.us :: youshould@comakewith.us
Include the whole team in research
www.comakewith.us :: youshould@comakewith.us
Story maps can start with a description of
people’s experience today, before ...
www.comakewith.us :: youshould@comakewith.us
Story maps morph with information
* Narrative Journey Map
courtesy Duncan Bro...
www.comakewith.us :: youshould@comakewith.us
Segmenting using characteristics and
continuums
What I spend
is a concern
Don...
www.comakewith.us :: youshould@comakewith.us
Solution Ideation &
Description
www.comakewith.us :: youshould@comakewith.us
Discovery is a design thinking process
1. Understand the
problem
2. Identify
...
www.comakewith.us :: youshould@comakewith.us
A design studio approach engages the
whole team in sketching
www.comakewith.us :: youshould@comakewith.us
Sketch independently
www.comakewith.us :: youshould@comakewith.us
Everyone shares their results
www.comakewith.us :: youshould@comakewith.us
Find the best ideas (not the best artist)
www.comakewith.us :: youshould@comakewith.us
Practices to sketch experience
User scenarios
(which is actually just writing...
www.comakewith.us :: youshould@comakewith.us
Comic Booking sets a user scenario to
pictures
See www.designcomics.org for c...
www.comakewith.us :: youshould@comakewith.us
UI Storyboard from Margarete Fuss, SAP AG
www.comakewith.us :: youshould@comakewith.us
Example storyboard from Arie Stavchansky,
http://stavchansky.net
www.comakewith.us :: youshould@comakewith.us
Single screen or concept ideation
explores many variations of the same
thing
...
www.comakewith.us :: youshould@comakewith.us
Dive deep into a single screen or concept
to explore complex design
Deep dive...
www.comakewith.us :: youshould@comakewith.us
Now it’s time for you to sketch
www.comakewith.us :: youshould@comakewith.us
Critique the ideas relative to the design
target
<persona> would like this be...
www.comakewith.us :: youshould@comakewith.us
Stand back and facilitate
“Design by community is not
design by committee.”
-...
www.comakewith.us :: youshould@comakewith.us
Incremental releases allow us to get
value from the market sooner
Big Product...
www.comakewith.us :: youshould@comakewith.us
Value from building backlog items comes
from learning
Minimal Viable Release ...
www.comakewith.us :: youshould@comakewith.us
Test hypotheses with prototypes
www.comakewith.us :: youshould@comakewith.us
Product Detail
www.comakewith.us :: youshould@comakewith.us
Stories have a simple lifecycle
! ?
Card
Conversation
!
Confirmation
Conseque...
www.comakewith.us :: youshould@comakewith.us
All things to all people
user developer
product manager
tester
PM
BA
UX
Desig...
www.comakewith.us :: youshould@comakewith.us
user
Stories need to support lots of
conversations across lots of project rol...
BA
www.comakewith.us :: youshould@comakewith.us
user
testerPM
UX Designer
Stories need to support lots of
conversations ac...
www.comakewith.us :: youshould@comakewith.us
user
product
manager
The natural “unit of measure” for
stories varies by conv...
www.comakewith.us :: youshould@comakewith.us
different
people
2. need
different
details to
support
different
people’s work...
www.comakewith.us :: youshould@comakewith.us
User Stories are boundary objects
Here’s the fine print on boundary objects:
...
www.comakewith.us :: youshould@comakewith.us
1. Express stories
in a language
most people can
understand
2. Keep stories o...
release cycle
develo
pment
cycle
User Stories shrink in size and grow in
detail as they travel through a pipeline
Capabili...
release cycle
develo
pment
cycle
User Stories shrink in size and grow in
detail as they travel through a pipeline
release cycle
iterat
ion
User Stories shrink in size and grow in
detail as they travel through a pipeline
Just-in-time
ref...
Upcoming SlideShare
Loading in...5
×

Passionate Product Ownership

2,321

Published on

Passionate Product Ownership is an experience that will expose you to new ways of thinking and working.You’ll learn the details you need to fulfill or support the Scrum Product Owner role in this course. But, we believe that understanding the role and its requirements isn’t enough to be successful. So, in this course, you’ll engage in a process simulation that models a different way of working, a way that emphasizes working collaboratively as a balanced core team, and having a user-centric product design approach.

What’s taught in the Agile Passionate Product Ownership is based on the underlying philosophy that you should:

Judge the success of your process based on the satisfaction of your users and customers with your product.

Published in: Software
0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,321
On Slideshare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
0
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide

Passionate Product Ownership

  1. 1. Passionate Product Ownershipworking together to create successful products Aaron Sanders Cofounder, Comakers LLC aaron@sanders.name:: @_aaron_sanders
  2. 2. www.comakewith.us :: youshould@comakewith.us Get Started. Jump right in.
  3. 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. 4. www.comakewith.us :: youshould@comakewith.us We typically think about tasks
  5. 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. 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. 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. 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. 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. 10. www.comakewith.us :: youshould@comakewith.us We grouped tasks into activities
  11. 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. 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. 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. 14. www.comakewith.us :: youshould@comakewith.us Shared Understanding
  15. 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. 16. www.comakewith.us :: youshould@comakewith.us Often when we verbally discuss ideas, we may incorrectly believe we have the same understanding
  17. 17. www.comakewith.us :: youshould@comakewith.us Representing our ideas as models allows us to detect inconsistencies in our understanding
  18. 18. www.comakewith.us :: youshould@comakewith.us Through discussion and iterative model building we arrive at a stronger shared understanding
  19. 19. www.comakewith.us :: youshould@comakewith.us Using that common understanding we can work together to arrive at the same objectives
  20. 20. www.comakewith.us :: youshould@comakewith.us Shared understanding and alignment are the objectives of collaborative work
  21. 21. www.comakewith.us :: youshould@comakewith.us Use models to support collaboration  Affinity Diagrams  Chronological Models  Decompositions  Ad Hoc Charts
  22. 22. www.comakewith.us :: youshould@comakewith.us Blend model types and annotate models to accurately represent your ideas 22 mixing annotating
  23. 23. www.comakewith.us :: youshould@comakewith.us User Story Mapping
  24. 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. 25. www.comakewith.us :: youshould@comakewith.us user The original idea of a story was simple: use it to facilitate a conversation developer
  26. 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. 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. 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. 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. 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. 31. www.comakewith.us :: youshould@comakewith.us Sketch a pragmatic persona thinking about someone different from yourself (sort of)
  32. 32. www.comakewith.us :: youshould@comakewith.us Creating personas can be fast and collaborative
  33. 33. www.comakewith.us :: youshould@comakewith.us Empathy maps organize conversations about target users Do
  34. 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. 35. www.comakewith.us :: youshould@comakewith.us Product Ownership Team
  36. 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. 37. www.comakewith.us :: youshould@comakewith.us The simple Scrum process framework
  38. 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. 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. 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. 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. 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. 43. www.comakewith.us :: youshould@comakewith.us193 43 Many organizations consider revising the same functionality as failure. Iteration is not tolerated.
  44. 44. www.comakewith.us :: youshould@comakewith.us The Product Owner Role
  45. 45. www.comakewith.us :: youshould@comakewith.us A good product blends three important concerns and the skills to fill them Valuable Usable Feasible
  46. 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. 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. 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. 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. 50. www.comakewith.us :: youshould@comakewith.us Collaborative workshops involve stakeholders, users, and the delivery team
  51. 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. 52. www.comakewith.us :: youshould@comakewith.us Use pairing and small groups to speed up workshop collaboration
  53. 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. 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. 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. 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. 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. 58. www.comakewith.us :: youshould@comakewith.us Discovery Balances Development
  59. 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. 60. www.comakewith.us :: youshould@comakewith.us Disscovery & Design Thinking
  61. 61. www.comakewith.us :: youshould@comakewith.us Product Opportunities & User Research
  62. 62. www.comakewith.us :: youshould@comakewith.us Winning the long game takes more than a single cycle
  63. 63. www.comakewith.us :: youshould@comakewith.us Maximize outcome and impact
  64. 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. 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. 66. www.comakewith.us :: youshould@comakewith.us
  67. 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. 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. 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. 70. www.comakewith.us :: youshould@comakewith.us Plan by slicing the map into holistic valuable releases
  71. 71. www.comakewith.us :: youshould@comakewith.us Adding tape lines to the wall lets participants organize stories into layers
  72. 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. 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. 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. 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. 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. 77. www.comakewith.us :: youshould@comakewith.us Planning incremental releases can be a whole team event 77
  78. 78. release cycle develo pment cycle Defer letting stories get too small or detailed until delivery Discovery Delivery
  79. 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. 80. www.comakewith.us :: youshould@comakewith.us Continuous discovery validates learning so that we can deliver the right outcomes
  81. 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. 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. 83. www.comakewith.us :: youshould@comakewith.us Research informally and in context
  84. 84. www.comakewith.us :: youshould@comakewith.us Go to where the product is used
  85. 85. www.comakewith.us :: youshould@comakewith.us Include the whole team in research
  86. 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. 87. www.comakewith.us :: youshould@comakewith.us Story maps morph with information * Narrative Journey Map courtesy Duncan Brown of the Caplin Group
  88. 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. 89. www.comakewith.us :: youshould@comakewith.us Solution Ideation & Description
  90. 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. 91. www.comakewith.us :: youshould@comakewith.us A design studio approach engages the whole team in sketching
  92. 92. www.comakewith.us :: youshould@comakewith.us Sketch independently
  93. 93. www.comakewith.us :: youshould@comakewith.us Everyone shares their results
  94. 94. www.comakewith.us :: youshould@comakewith.us Find the best ideas (not the best artist)
  95. 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. 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. 97. www.comakewith.us :: youshould@comakewith.us UI Storyboard from Margarete Fuss, SAP AG
  98. 98. www.comakewith.us :: youshould@comakewith.us Example storyboard from Arie Stavchansky, http://stavchansky.net
  99. 99. www.comakewith.us :: youshould@comakewith.us Single screen or concept ideation explores many variations of the same thing Ideation
  100. 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. 101. www.comakewith.us :: youshould@comakewith.us Now it’s time for you to sketch
  102. 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. 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. 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. 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. 106. www.comakewith.us :: youshould@comakewith.us Test hypotheses with prototypes
  107. 107. www.comakewith.us :: youshould@comakewith.us Product Detail
  108. 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. 109. www.comakewith.us :: youshould@comakewith.us All things to all people user developer product manager tester PM BA UX Designer
  110. 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. 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. 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. 113. www.comakewith.us :: youshould@comakewith.us different people 2. need different details to support different people’s work 3. have a different
  114. 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. 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. 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. 117. release cycle develo pment cycle User Stories shrink in size and grow in detail as they travel through a pipeline
  118. 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

×