Post on 21-Apr-2017
po:pmProduct Owner vs. Product Manager
One person or two?One role or two?
Sagi Smolarski - AgileSparks
I have a friend, Sarah, who, years ago,
learned to fly a hot air balloon
on her first solo flight, Sarah got hopelessly lost
?!?
...down below, she saw a
campfire and a man next to it, so she lowered
the balloon...
hey man! where am I?
when she was within ear’s reach, she shouted:
you are in a hot air balloon,
about 40 feet off the ground!
startled, the man answered...
Are you an engineer?
Surprised, my friend asked...
how did you know?
to which the man answered...
What you told me is 100% correct...
my friend replied...
... yet it doesn’t help me at all
my friend replied...
Are you a product
manager?
so the guy asked...
how the hell did you know?
and Sarah, which happens to be a product
manager at ACME.com answered...
You don’t know how you got here, you have no clue where you are, you
don’t know how you are going to proceed from here...
to which the man replied...
...and somehow you found a way to blame me !
to which the man replied...
what they didn’t know, is that they both work for ACME.com, a pillar of our country’s high
tech industry...
Meet ACME.com
Marketing
BusinessAnalysts?
icons by dapino http://www.iconarchive.com/show/people-icons-by-dapino.html
Project Management
Office
Product Management
R&D
QualityAssurance
They are running a tight ship, with
well defined groups, clear
responsibilities, really well
organized silos
All the silos are responsible together for delivering a product
Marketing
BusinessAnalysts?
icons by dapino http://www.iconarchive.com/show/people-icons-by-dapino.html
Project Management
Office
Product Management
R&D
QualityAssurance
“We” are responsible for delivering a valuable product
Feedback at the speed of the turtle
User
which makes for a pretty unhappy customer, who gets his requests late...
and often... wrong
The Bungay Friction ModelTo him, this picture is not a joke... it’s reality
Chaos Report 1994
31%
CriticalFailure
53%
16%
SuccessChallenged
Software Projects Success Rate
Planned Cost: $10M
$27MActual Cost:
Standish Group Chaos Report 1994
...and apparently he is not alone...
On average:
Looking at Successful Projects
However, some projects do succeed.
What are they doing which makes the
biggest difference?
16%
Success
His Direct Involvement Throughout The Project
User
Reason #1 For Project Success?
Direct, continuous user involvement
consistently rates as the #1 difference between projects
that succeed...and those that fail
Minimize the distance from user to maker
The Product Team
POUser
● Avoid miscommunications● Shorten the feedback loop● Seize opportunities● Collaboration instead of negotiation
So, when ACME.com tried to improve, they looked at agile & lean,
and unsurprisingly, those methods
promote proximity of the makers to the
users. There are clear benefits here...
PO Role Definition
❏ Deliver the right product❏ Articulates and champions the vision❏ Creates & prioritizes the product
backlog❏ Collaborates with the delivery team,
users and other stakeholders on translating the vision to work plans
❏ Manages expectations❏ Accepts work
Scrum, in particular, defines a new role which brings the product manager closer to the user, and to the team that
creates the software
Challenges with Single PO
➔ Capacity◆ Can you work with customers and be available
to the team all the time?◆ Can you focus on the tactical and still stay on
top of the strategic?➔ Skill set
◆ Can you have business expertise, marketing expertise, engineering expertise and domain expertise?
◆ Do people even want to do all the above?
... but Sarah soon found out that this role creates a new set of challenges, and the extra
closeness to the team is demanding
MarketingPricingMarket researchCompetitive analysisCustomer relations
Focus & Attention
Long TermStrategy
Short TermTactical
Product BacklogSprint & Release planningAcceptance Criteria
VisionProduct PositioningRoadmap
CustomerFocus
EngineeringFocus
PersonasUXUser stories
CustomerDevelopmentOutbound
EnvironmentsAssetsTechnologyCoding conventionsTesting strategy
ArchitectureTechnology stack
ProductDevelopment
Inbound
User feedbackDesign partnersFocus groups
...indeed, owning a product is a big job,
with many concerns...
Customer Support
MarketingPricingMarket researchCompetitive analysisCustomer relations
The Natural Solution?
Long TermStrategy
Short TermTactical
Product BacklogSprint & Release planningAcceptance Criteria
VisionProduct PositioningRoadmap
CustomerFocus
EngineeringFocus
PersonasUXUser stories
CustomerDevelopment
EnvironmentsAssetsTechnologyCoding conventionsTesting strategy
ProductDevelopment
ArchitectureTechnology stack
PO
PM
...so they decided to split the role into
two...
...they asked Ron, a Team Lead, to assume the role of PO, while Sarah took on
outbound & long term responsibilities...
H.L. Mencken
“for every complex problem, there is an answer that is clear, simple... and wrong”
PM & PO
The Product Team
POUser
The Product Team
POUser
PM
Separations hurt...
PM & PO
The Product Team
POUser
PM
She understands the customer well
PM & PO
The Product Team
POUser
PM
She understands the customer well
He doesn’t understands the
customer well➽
PM & PO
The Product Team
POUser
PM
They do their “agile” thing
PM & PO
The Product Team
POUser
PM
Who owns the product?
PM .. .. .. .. vs .. .. .. .. PO
The Product Team
PO
UserPM
Lean thinking and Agile principles are customer-focused for business success. They are not “development processes”
Agile
“the business” R&D
Making it Work
The Solo PO
<=>Less… is more
Smaller scope ➽ Smaller groups ➽ More manageable workload ➽ More focus Too often, scaling up
promotes inefficiency and mediocrity
Break your company into small start-ups
User Segments
Short TermTactical
Long TermStrategy
CustomerFocus
EngineeringFocus
PO
CustomerDevelopment
ProductDevelopment
Short TermTactical
Long TermStrategy
CustomerFocus
EngineeringFocus
POShort Term
TacticalLong Term
Strategy
CustomerFocus
EngineeringFocus
PO
Enterprise clients
Retail clients
B2B
This is one option
Product Areas / Services
Short TermTactical
Long TermStrategy
CustomerFocus
EngineeringFocus
PO
CustomerDevelopment
ProductDevelopment
Short TermTactical
Long TermStrategy
CustomerFocus
EngineeringFocus
POShort Term
TacticalLong Term
Strategy
CustomerFocus
EngineeringFocus
PO
Users Growth
Shopping Cart
Playlists
This is another option
The PO Team
Short TermTactical
Long TermStrategy
CustomerFocus
EngineeringFocus
CustomerDevelopment
ProductDevelopment
Short TermTactical
Long TermStrategy
CustomerFocus
EngineeringFocus
Short TermTactical
Long TermStrategy
CustomerFocus
EngineeringFocus
PO
PO
PO
CPOThe Chief Product Owner
You may need to have a Chief Product Owner, but
individual POs still fully own their area
Leverage Outside Expertise
Product Owner
MarketingSpecialist
But… I’m not a marketing
expert! But I am… and I will help you
market your product
“It take a village to raise a child”African proverb
Other Roles Are Fine… when they don’t come between the product and its users
Product Owner
ProductMarketing
User
Market
I am responsible for creating a great product
I am responsible for telling the
market about it & bringing in new
users
Marketing
Project Management
UX Expert
Team Lead /ScrumMaster
Product Owner
Domain expert
Tracking
Risk Management
ALM
Product Discovery
Team
Estimates Architect
Long-term product
architecture
Release Train
Product launch
Pricing
Telling the world about the
product
Positioning
Quality
xx-ilities
Interaction Design
Usability Testing
Visual Design
Long-term Velocity
Domain knowledge
Domain trends
Long TermStrategy
Short TermTactical
CustomerFocus
EngineeringFocus
Marketing
Project Management
UX Expert
Team Lead /ScrumMaster
Product Owner
Domain expert
Tracking
Risk Management
ALM
Product Discovery
Team
Estimates ArchitectLong-term
product architecture
Release Train
Product launch
Pricing
Telling the world about the
product
Positioning
Quality
xx-ilities
Interaction Design
Usability Testing
Visual Design
Long-term Velocity
Domain trendsDomain trends
Trade the dream of success... for the reality of feedback
The Big Picture is Smaller than You think
Success Success
what it really looks like
what people think it looks like
Don’t invest too much in long term planning
and analysis
Experiment
Use experiments & data to drive product direction
A significant portion of the
work should be experiments,
where we check assumptions
against reality
Not only For Startups
Build Measure
Learn
Insights
Product Data
How fast can you spin that wheel?
Build the Team’s Knowledge of Users
Spoon feeding teams with detailed user
stories is boring and inefficient
Develop the team’s capabilities to define
work itemsThe team should interact with the
user
Scaling Up
But... We Need More
SCALEe.g. we have a very large project, for a small # of large clients, so having many
POs working directly with them will impose extra burden on the client
Scaling Up
First rule of project
SCALING
Scaling Up
First rule of project
SCALING
DON’T
Large Projects ... Fail ... Almost Always
Standish Group Chaos Report 2013
A word of warning. Scaling up a project is
harmful
But if you must Scale there are recipes
Scaling Agile @ Spotify
Here are just some of the most popular
examples
Scaling Up Agile
All Agile Scaling Models are Wrong...
...but Some are Helpful
There’s no right answer, but some
interesting pointers
Scaling with SAFe
http://scaledagileframework.com/
Not my favourite solution, but
sometimes it may make sense
Scaling with SAFe
MarketingPricingMarket researchCompetitive analysisCustomer relations
The SAFE (?) Solution
Long TermStrategy
Short TermTactical
Product BacklogSprint & Release planningAcceptance Criteria
VisionProduct PositioningRoadmap
CustomerFocus
EngineeringFocus
PersonasUXUser stories
CustomerDevelopment
EnvironmentsAssetsTechnologyCoding conventionsTesting strategy
ProductDevelopment
ArchitectureTechnology stack
PO
PM
Scaling with Large Scale Scrum
Product Owner TeamOne Product Owner
Prioritizes all work
Product Area OwnersDefine work
Less separation, that’s better
Scaling with Large Scale Scrum
Scaling @ Spotify
Product Ower per SquadSometimes, a Chief Product Owner to help with synchronization
Sounds pretty good :)
Scaling @ Spotify
What do Agile Product Management Experts Say?
Marty Cagan is a Product Management expert.
He has managed product at ebay, Netscape HP and other
big name companies. He’s now part of the Silicon Valley
Product Group
He wrote the top selling (*) book on product management.
The book devotes a big section to the role of the Product
Manager
(*) Based on Amazon kindle sales position
What do Agile Product Management Experts Say?
“...for product software teams...the product manager is the product owner, and he represents the customer, He will need to be extremely involved with the product development team...”
hmmm….
What do Agile Product Management Experts Say?
“... some also like to have different people covering the product manager and the product owner role, but this is usually a symptom of a deeper problem ...nobody truly owns the product”
What do Agile Product Management Experts Say?
there’s more...
“... this model is based on a flawed view of software that holds that you can define high-level requirements independent of detailed requirements ”
What do Agile Product Management Experts Say?
flawed indeed...
“... in companies with this model, product managers become little more than spec-generation service. It is a frustrating job, tends to stifle innovation, and rarely produces successful products ”
What do Agile Product Management Experts Say?
can’t get much clearer...
Summary
❏ PO which fully owns the product ➽ Less barriers to being Lean & Agile... and successful
❏ Keep that model as long as you can❏ Scale horizontally❏ Less long-term planning, more experiments❏ Get the delivery team closer to the users❏ Other roles can help❏ Create a product discovery team
❏ When you have no choice, pick a scaling model which keeps the team as close to the user as possible
Summary
Sarah is now chief Product Owner at ACME.com
She got her hot air balloon pilot license.
Ron is a ScrumMaster on the same project.
Together, they delivered a kick-ass product.
They now get along fine.
SummaryEpilogue
po=pm
the end
Sagi Smolarskisagi@agilesparks.com