• Save
Passionate Product Ownership
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Passionate Product Ownership

  • 2,185 views
Uploaded 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......

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.

More in: Software
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,185
On Slideshare
1,777
From Embeds
408
Number of Embeds
8

Actions

Shares
Downloads
0
Comments
0
Likes
6

Embeds 408

http://www.scoop.it 334
https://twitter.com 26
http://www.1agile.com 19
http://better-built.ca 10
http://staging.1agile.com 9
http://sprmario.tumblr.com 7
http://1agile.com 2
http://iframe.ly 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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