It is far too common for a newly appointed Product Owner to be left alone without any instructions or ideas of how to succeed than we care to imagine. The role of the Product Owner is different from traditional roles and in order to survive as a Product Owner new learning is necessary. In order to become a successful Product Owner you don’t only need a vision, you also need good tools, principles and practices.
In this session I will go through a number of principles, tools and practices that can help you to become more successful in your role regardless if you are new in the role or more experienced. After the session you will have a collection of principles, tools and practices to apply directly when returning home after the conference.
In this presentation you will learn:
Different ways of creating and communicating a product vision
Principles to follow in order to become a successful Product Owner
Tools and practices suitable for a Product Owner
7. Possible content
• A list of important stakeholders
• Product Vision
• Product Roadmap
- Release information
• Product Backlog
• Definition of Ready
• Definition of Done
11. Common Template
For (target customer)
Who (statement of the need or
opportunity)
The (product name) is a (product
category)
That (key benefit, compelling
reason to buy)
Unlike (primary competitive
alternative)
Our product (statement of primary
differentiation)
Source: Geoffrey Moore – ”Crossing the Chasm”
12. Example
For bikeriders who want to buy a custom bike the
YourBikey.com site is a marketplace that let
constructors provide custom bikes for sale Unlike
a traditional bike store where standard bikes are
sold, our solution support purchase of
individually and custom designed bikes.
Is this the way you would like it if you start as a new Product Owner?
In many cases this is exactly what happens. You are asked to become Product Owner, you accept and you are left without support.
In this session my aim is to give ideas on principles to follow and tools to use in order to become a succesful Product Owner.
My hope is to give some guidance through the Product Owner labyrinth.
So, let’s take a look at the empty desktop again.
What I believe would be greate to have on it is the following: A Product Owner Playbook
A Product Owner Playbook is
a collection of tools, templates, and training customized to your organization
a document that summarizes the most important aspects of the product and serves as a high-level overview of all things necessary to know for a Product Owner to be successful
a guide to be and continue to be a succesful Product Owner
A Product Owner Playbook is
to what sport teams uses to describe the different plays they want to do.
Possible content of a Product Owner Playbook is:
A list of important stakeholders
Product Vision
Product Roadmap
with Release information
Product Backlog
Definition of Ready
Definition of Done
The list can be made much longer. The things that you choose to put on your list should be relevant for your product, your company and your specific situation.
Product Vision gives us direction and focus
it should guide the team/s
it should he lp the team to focus
it should align stakeholders
A Product Vision should cover who, what and why
Having a Product Vision is proved valuable.
A good Product Vision is
Shared
Stable
Clear
Broad and engaging
Concise
Different ways of creating a Product Vision
Product Vision Box
Elevator Pitch
This example is from one of my Certified Scrum Product Owner classes
Discovery (How to understand the right product to build)
Product Discovery - Defines WHY something shoud be built, for WHOM and WHAT
Tips from Marty Cagan in his book Inspired:
Focus on Misery, not on Technology
Enlist your Developers Early
Use Prototypes over Product Requirement Documents
Lead by Objective, Not Instruction
Manage by Wandering Around
Build a Team With a Core of Passion, Integrity, Empathy
Succesful Product Owners are able to visualize things for themselves and others.
We want to visualize the things that are easily hidden if not fokused on.
Like values, strategic decisions, reasons why we prioritize in a certain order, understanding of customer segments, etc.
Good thinking tools that also can help us visualize our understanding are different types of canvases. I will talk more about Value Proposition Canvas, Business Model Canvas and Lean Canvas.
Other canvases that I know of are Product Scorecard and Product Vision Board. Both presented by Roman Pichler.
A Value Proposition Canvas is a tool to visualize two basic things:
A. The Customer Segment that you are focusing on creating value for
B. The Value Proposition that you believe will make your customers wanting to buy your product or use your service
You should aim to show the fit between what you offer and what customers want.
Customer segment profile. The term customer segment is used to describe who we aim to support and please. Customer to me is potential customer. It can of course be current customers as well.
Jobs - describe the important issues your customers are trying to solve (tasks, problems, needs)
(crucial, trivial)
Pains - cost, emotions, risks, frustrations currently experienced by your customers
Gains - outcomes, benefits, desire to have
The above is all about observing.
The left part of the canvas is about designing the product or service to be attraktive and valuable to the selected customer segment.
The Value Propostion Canvas fits well into the Business Model Canvas. Both invented by Alex Osterwalder and described in the books Business Model Generation and Value Proposition Design.
https://strategyzer.com/canvas
Business Model Canvas
Lean Canvas created by Ash Maurya.
http://practicetrumpstheory.com/why-lean-canvas/
Product Owners should be interested in getting early feedback on their products.
Lean Startup and MVP, Minimum Viable Product is an approach that fits well for many Product Owners.
Lean Startup by Eric Ries is the ultimate source. http://theleanstartup.com/
A Product Owner is responsible for maximizing return on investment for the product. By creating, rupdating and refining the Product Backlog the PO can take steps in the right direction.
In the context of the Product Backlog it is a benefit to define a Definition of Ready in order to be able to have the Product backlog in a Ready state in time for each Sprint planning.
Definition of Ready addresses what state the top items on the Product Backlog need to be in to make it possible for the development team to plan the Sprint and start implementation at once after Sprint Planning
In the similar way as the Definition of Ready we benefit from having a Definition of Done (DoD).
DoD tells us about the current capability of the development team. Ideally we want it to be possible to release the product increment directly after the Sprint. That is not always possible due to lack of capability of the development team. My favorite example is regression testing. It may not be possible to do regression test within a Sprint if we are using manual regression testing. Therefore the current DoD is without regression testing. Of course we need to do regression testing before we choose to release the product increment. And, the development team may be able to automats regression testing thus being able to expand thier capabilities and their DoD.
Some Product Owner choose to perform Release Planning.
One possible tool to support defining the scope for a release is Kano analysis to guide the Product Owner when deciding which features to include in the scope of the rerlase. Good advoce is to include not only must have features, but also some linear and some delighter functionality. Delighters are features customers and users didn’t even know they wanted before they saw them. Delighetrs tend to become must haves over time. E.g. color screen on a mobile phone.
The principles I’ve talked about are:
Product Discovery
Definition of Ready
Definition of Done
Getting Early Feedback (Inspect & Adapt)
The tools I’ve discussed are:
Product Owner Playbook
Product Vision and Product Vision Box
Value Proposition Canvas
Business Model Canvas
Lean Canvas
Lean Startup and MVP
Releas Planning and Kano analysis