The document explores the distinction between product owners (PO) and product managers (PM), highlighting the challenges and benefits of each role in agile environments. It emphasizes the need for direct user involvement for project success and discusses strategies for effective role allocation, including splitting responsibilities between PO and PM. Ultimately, it advocates for maintaining strong user connections and encourages adopting lean and agile methodologies to foster product development success.

1. po:pm
Product Owner vs. Product Manager
One person or two?
One role or two?
Sagi Smolarski - AgileSparks

2. I have a friend,
Sarah, who,
years ago,
learned to fly a
hot air balloon

3. on her first solo
flight, Sarah got
hopelessly lost
?!?

4. ...down below,
she saw a
campfire and a
man next to it,
so she lowered
the balloon...

5. hey man! where
am I?
when she was
within ear’s
reach, she
shouted:

6. you are in a hot
air balloon,
about 40 feet off
the ground!
startled, the
man answered...

7. Are you an
engineer?
Surprised, my
friend asked...

8. how did you
know?
to which the
man answered...

9. What you told me is 100%
correct...
my friend
replied...

10. ... yet it doesn’t help me
at all
my friend
replied...

11. Are you a
product
manager?
so the guy
asked...

12. how the hell did you know?
and Sarah,
which happens
to be a product
manager at
ACME.com
answered...

13. 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...

14. ...and somehow you found a way to
blame me !
to which the
man replied...

15. what they didn’t know, is that
they both work for ACME.com,
a pillar of our country’s high
tech industry...

16. Meet ACME.com
Marketing
Business
Analysts?
icons by dapino http://www.iconarchive.com/show/people-icons-by-dapino.html
Project
Management
Office
Product
Management
R&D
Quality
Assurance
They are running
a tight ship, with
well defined
groups, clear
responsibilities,
really well
organized silos

17. All the silos are responsible
together for delivering a product
Marketing
Business
Analysts?
icons by dapino http://www.iconarchive.com/show/people-icons-by-dapino.html
Project
Management
Office
Product
Management
R&D
Quality
Assurance
“We” are responsible for delivering a valuable product

18. Feedback at the speed of the turtle
User
which makes for a pretty
unhappy customer, who
gets his requests late...
and often... wrong

19. The Bungay Friction Model
To him, this picture is not a joke... it’s reality

20. Chaos Report 1994
31%
Critical
Failure
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:

21. Looking at Successful Projects
However, some projects
do succeed.
What are they doing
which makes the
biggest difference?
16%
Success

22. 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

23. Minimize the distance from user to maker
The Product
Team
PO
User
● 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...

24. 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

25. 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

26. Marketing
Pricing
Market research
Competitive analysis
Customer relations
Focus & Attention
Long Term
Strategy
Short Term
Tactical
Product Backlog
Sprint & Release planning
Acceptance Criteria
Vision
Product Positioning
Roadmap
Customer
Focus
Engineering
Focus
Personas
UX
User stories
Customer
Development
Outbound
Environments
Assets
Technology
Coding conventions
Testing strategy
Architecture
Technology stack
Product
Development
Inbound
User feedback
Design partners
Focus groups
...indeed, owning a
product is a big job,
with many concerns...
Customer Support

27. Marketing
Pricing
Market research
Competitive analysis
Customer relations
The Natural Solution?
Long Term
Strategy
Short Term
Tactical
Product Backlog
Sprint & Release planning
Acceptance Criteria
Vision
Product Positioning
Roadmap
Customer
Focus
Engineering
Focus
Personas
UX
User stories
Customer
Development
Environments
Assets
Technology
Coding conventions
Testing strategy
Product
Development
Architecture
Technology 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...

28. H.L. Mencken
“for every complex problem, there is an
answer that is clear, simple... and wrong”

29. PM & PO
The Product
Team
PO
User
The Product
Team
PO
User
PM
Separations hurt...

30. PM & PO
The Product
Team
PO
User
PM
She understands the
customer well

31. PM & PO
The Product
Team
PO
User
PM
She understands the
customer well
He doesn’t
understands the
customer well
➽

32. PM & PO
The Product
Team
PO
User
PM
They do their “agile”
thing

33. PM & PO
The Product
Team
PO
User
PM
Who owns the
product?

34. PM .. .. .. .. vs .. .. .. .. PO
The Product
Team
PO
User
PM
Lean thinking and Agile principles are
customer-focused for business success.
They are not “development processes”
Agile
“the business” R&D

35. Making it Work
The Solo PO

36. <=>
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

37. User Segments
Short Term
Tactical
Long Term
Strategy
Customer
Focus
Engineering
Focus
PO
Customer
Development
Product
Development
Short Term
Tactical
Long Term
Strategy
Customer
Focus
Engineering
Focus
PO
Short Term
Tactical
Long Term
Strategy
Customer
Focus
Engineering
Focus
PO
Enterprise clients
Retail clients
B2B
This is one option

38. Product Areas / Services
Short Term
Tactical
Long Term
Strategy
Customer
Focus
Engineering
Focus
PO
Customer
Development
Product
Development
Short Term
Tactical
Long Term
Strategy
Customer
Focus
Engineering
Focus
PO
Short Term
Tactical
Long Term
Strategy
Customer
Focus
Engineering
Focus
PO
Users Growth
Shopping Cart
Playlists
This is another option

39. The PO Team
Short Term
Tactical
Long Term
Strategy
Customer
Focus
Engineering
Focus
Customer
Development
Product
Development
Short Term
Tactical
Long Term
Strategy
Customer
Focus
Engineering
Focus
Short Term
Tactical
Long Term
Strategy
Customer
Focus
Engineering
Focus
PO
PO
PO
CPO
The Chief Product Owner
You may need to have a
Chief Product Owner, but
individual POs still fully
own their area

40. Leverage Outside Expertise
Product
Owner
Marketing
Specialist
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

41. Other Roles Are Fine
… when they don’t come between the product and its users
Product
Owner
Product
Marketing
User
Market
I am responsible
for creating a
great product
I am responsible
for telling the
market about it
& bringing in new
users

42. 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

43. Long Term
Strategy
Short Term
Tactical
Customer
Focus
Engineering
Focus
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 trends
Domain trends

44. 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

45. Experiment
Use experiments & data to drive product
direction
A significant
portion of the
work should be
experiments,
where we check
assumptions
against reality

46. Not only For Startups
Build Measure
Learn
Insights
Product Data
How fast can you
spin that wheel?

47. 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 items
The team should
interact with the
user

48. Scaling Up
But... We Need More
SCALE
e.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

49. Scaling Up
First rule of project
SCALING

50. Scaling Up
First rule of project
SCALING
DON’T

51. Large Projects ... Fail ... Almost Always
Standish Group Chaos Report 2013
A word of warning.
Scaling up a project is
harmful

52. But if you must Scale there are
recipes
Scaling Agile @ Spotify
Here are just some of
the most popular
examples

53. Scaling Up Agile
All Agile Scaling
Models are Wrong...
...but Some are
Helpful
There’s no right
answer, but some
interesting pointers

54. Scaling with SAFe
http://scaledagileframework.com/

55. Not my favourite
solution, but
sometimes it may
make sense
Scaling with SAFe

56. Marketing
Pricing
Market research
Competitive analysis
Customer relations
The SAFE (?) Solution
Long Term
Strategy
Short Term
Tactical
Product Backlog
Sprint & Release planning
Acceptance Criteria
Vision
Product Positioning
Roadmap
Customer
Focus
Engineering
Focus
Personas
UX
User stories
Customer
Development
Environments
Assets
Technology
Coding conventions
Testing strategy
Product
Development
Architecture
Technology stack
PO
PM

57. Scaling with Large Scale Scrum

58. Product Owner Team
One Product Owner
Prioritizes all work
Product Area Owners
Define work
Less separation,
that’s better
Scaling with Large Scale Scrum

59. Scaling @ Spotify

60. Product Ower per Squad
Sometimes, a Chief Product Owner to help
with synchronization
Sounds pretty
good :)
Scaling @ Spotify

61. 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

62. 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?

63. “...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?

64. “... 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...

65. “... 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...

66. “... 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...

67. 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

68. ❏ When you have no choice, pick a scaling
model which keeps the team as close to
the user as possible
Summary

69. 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

70. po=pm
the end
Sagi Smolarski
sagi@agilesparks.com