Passionate Product Ownership


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

Passionate Product Ownership

  1. 1. Passionate Product Ownershipworking together to create successful products Aaron Sanders Cofounder, Comakers LLC @_aaron_sanders
  2. 2. :: Get Started. Jump right in.
  3. 3. :: 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. :: We typically think about tasks
  5. 5. :: There’s a “natural size” for tasks * Cockburn’s Writing Effective Use Cases describes goal levels for use cases this way
  6. 6. :: 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. :: 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. :: We quickly built a two-dimensional map sub-tasks, alternative s, variations, and details An imperfect narrative flow
  9. 9. :: 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. :: We grouped tasks into activities
  11. 11. :: 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. :: 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. :: ★Practice shared understanding ★Collaborate effectively ★Build empathy with users ★Use Design Thinking continually ★Practice deliberate discovery The Big Goals:
  14. 14. :: Shared Understanding
  15. 15. :: 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. :: Often when we verbally discuss ideas, we may incorrectly believe we have the same understanding
  17. 17. :: Representing our ideas as models allows us to detect inconsistencies in our understanding
  18. 18. :: Through discussion and iterative model building we arrive at a stronger shared understanding
  19. 19. :: Using that common understanding we can work together to arrive at the same objectives
  20. 20. :: Shared understanding and alignment are the objectives of collaborative work
  21. 21. :: Use models to support collaboration  Affinity Diagrams  Chronological Models  Decompositions  Ad Hoc Charts
  22. 22. :: Blend model types and annotate models to accurately represent your ideas 22 mixing annotating
  23. 23. :: User Story Mapping
  24. 24. Via 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. :: user The original idea of a story was simple: use it to facilitate a conversation developer
  26. 26. :: 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. :: 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. :: 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. :: 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. :: Segment your users to help focus your product design and planning Look for differences that make a difference in product use
  31. 31. :: Sketch a pragmatic persona thinking about someone different from yourself (sort of)
  32. 32. :: Creating personas can be fast and collaborative
  33. 33. :: Empathy maps organize conversations about target users Do
  34. 34. :: 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. :: 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. :: The simple Scrum process framework
  38. 38. :: “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. :: “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 :: Work like an artist to envision and build the product holistically 40 “Art is never finished, only abandoned.” -Leonardo DaVinci
  41. 41. :: 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. :: 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. :: youshould@comakewith.us193 43 Many organizations consider revising the same functionality as failure. Iteration is not tolerated.
  44. 44. :: The Product Owner Role
  45. 45. :: A good product blends three important concerns and the skills to fill them Valuable Usable Feasible
  46. 46. :: 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. :: A cross functional product ownership team directs discovery Your discovery team should move forward to be your core product ownership team
  48. 48. :: 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. :: 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. :: Collaborative workshops involve stakeholders, users, and the delivery team
  51. 51. :: 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. :: Use pairing and small groups to speed up workshop collaboration
  53. 53. :: 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:
  54. 54. :: Brought to you by the letter “T” Breadth of skills Depth of expertiseFast Company, Strategy By Design
  55. 55. :: 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. :: Games have Positions not Roles Players on a sports team build deep specialization but maintain general skills to play many positions
  57. 57. :: 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. :: Discovery Balances Development
  59. 59. :: 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. :: Disscovery & Design Thinking
  61. 61. :: Product Opportunities & User Research
  62. 62. :: Winning the long game takes more than a single cycle
  63. 63. :: Maximize outcome and impact
  64. 64. :: Deciding relevant context is prioritization software product use (activities & tasks) users (goals) organization (goals) product context software solution customer (value proposition) 64
  65. 65. :: 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. ::
  67. 67. :: 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. :: 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:
  69. 69. :: 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. :: Plan by slicing the map into holistic valuable releases
  71. 71. :: Adding tape lines to the wall lets participants organize stories into layers
  72. 72. :: 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. :: 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. :: Segment your audience to reduce release size Photo courtesy of R1: Subset of the initial target market R2: What’s needed to expand to the original target
  75. 75. :: 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. :: Where are features in the map? Features are threaded through the user’s experience MVP 1 or more MMFs 76
  77. 77. :: 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. :: 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. :: Continuous discovery validates learning so that we can deliver the right outcomes
  81. 81. :: 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. :: 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. :: Research informally and in context
  84. 84. :: Go to where the product is used
  85. 85. :: Include the whole team in research
  86. 86. :: 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. :: Story maps morph with information * Narrative Journey Map courtesy Duncan Brown of the Caplin Group
  88. 88. :: 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. :: Solution Ideation & Description
  90. 90. :: 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. :: A design studio approach engages the whole team in sketching
  92. 92. :: Sketch independently
  93. 93. :: Everyone shares their results
  94. 94. :: Find the best ideas (not the best artist)
  95. 95. :: 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. :: Comic Booking sets a user scenario to pictures See for clipart and examples 97
  97. 97. :: UI Storyboard from Margarete Fuss, SAP AG
  98. 98. :: Example storyboard from Arie Stavchansky,
  99. 99. :: Single screen or concept ideation explores many variations of the same thing Ideation
  100. 100. :: Dive deep into a single screen or concept to explore complex design Deep dive sketch by Mike Rohde, CommLogix
  101. 101. :: Now it’s time for you to sketch
  102. 102. :: 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. :: Stand back and facilitate “Design by community is not design by committee.” -- Leisa ReicheltLeisa Reichelt Leah Buley “Design isn’t something that designers produce, design is a process that designers facilitate.” --Leah Buley You still own the outcome
  104. 104. :: Incremental releases allow us to get value from the market sooner Big Product Idea Incremental Release Strategy 1. 2. 3.
  105. 105. :: Value from building backlog items comes from learning Minimal Viable Release Product Backlog built from small stories
  106. 106. :: Test hypotheses with prototypes
  107. 107. :: Product Detail
  108. 108. :: Stories have a simple lifecycle ! ? Card Conversation ! Confirmation Consequences ! ?? ! Construction * Ron Jeffries coined the 3 C’s in Extreme Programming Installed
  109. 109. :: All things to all people user developer product manager tester PM BA UX Designer
  110. 110. :: user Stories need to support lots of conversations across lots of project roles developer product manager testerPM BA UX Designer
  111. 111. BA :: user testerPM UX Designer Stories need to support lots of conversations across lots of project roles developer product manager
  112. 112. :: user product manager The natural “unit of measure” for stories varies by conversation BA or UI Designer developer business leader
  113. 113. :: different people 2. need different details to support different people’s work 3. have a different
  114. 114. :: 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. :: 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