By Pragmatic Marketing & Enthiosys
The Strategic Role of Product Management When Development Goes Agile
...the best job to date of describing the yin
and yang of APO (Agile Product Owner) and
APM (Agile Product Manager). Moreover, the
authors are experts in the field of software
product management so they speak with
knowledge and credibility from the PM role.
Dean Leffingwell / Scaling Software Agility
About the Companies
Enthiosys is a management
consulting and training
firm that brings business
agility to software
companies and firms embedding software into their
products. As the leading authority on agile product
management, they help companies plan, design, build
and manage their products throughout their lifecycle.
Enthiosys works collaboratively with clients to gain
crucial insights on customer needs, translate them
into superior products, and make other key changes
to their product management process. Their approach
ensures that your people, products and processes
generate sustainable results after they’re gone.
Clients range from Fortune 500 multinationals to
technology start-ups, including companies such
as SAP, Hewlett Packard, VeriSign, Yahoo!, Trend
Micro, Qualcomm, Emerson Electric and Wyse.
Pragmatic Marketing’s
training is based
on the fundamental
belief that a company’s products need to be grounded
in a strategy that is driven by the market. They
combine this core principle with a team of instructors
who have real-world experience leading high tech
product teams, to deliver training seminars that
are informative, entertaining, and impactful.
Pragmatic Marketing’s courses cover everything
technology companies need to be successfully
market-driven, from understanding market problems
and personas, to creating effective requirements
and go-to-market strategies. To find out how you or
your company can join the growing international
community of more than 75,000 product management
and marketing professionals trained by Pragmatic
Marketing, visit www.pragmaticmarketing.com.
Copyright © 2012 Pragmatic Marketing, Inc. All rights reserved.
Copyright holder is licensing this under the Creative Commons License. Attribution 3.0.http://creativecommons.org/licenses/by/3.0/
Other product and/or company names mentioned in this e-book may be trademarks or registered trademarks of their respective companies and are the sole property of their respective owners.
Please feel free to post this ebook on your blog or e-mail it to whomever you believe would benefit from reading it.
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 2
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
We are uncovering better ways of developing soft ware by doing it
and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
agilemanifesto.org
That is,
while there is value
in the items on the right,
we value the items
on the left more.
Manifesto for
Agile Software Development
While software development teams have been
moving toward agile methods for years, many
product managers are only now becoming
aware of it. An agile approach applies
collaborative and continuous improvement
concepts to software development. It
emphasizes close collaboration between
development teams and customers; frequent
delivery of deployable code (in sprints); face-
to-face communication with customers; tight,
self-organizing teams; managing backlogs of
user stories to reduce requirements churn;
and identification of self-improvement
opportunities.
There is no single, definitive “agile method.”
Agile teams tune practices and processes for
themselves to create a method that is unique
to their environment. Broadly, agile methods
function as both an organizational philosophy
and a set of development methodologies.
When you adopt agile development methods,
you encounter new concepts, new artifacts,
new planning methods, and new roles and
relationships. It seems that agile teams do
everything in a new way. And, as you attempt
to integrate agile into your existing systems,
you’ll also attempt to map these new concepts
to your old, familiar concepts. Requirements
are now stories; iterations are now sprints.
And a product manager is now called a
Product Owner… right?
Wrong!
Companies adopting agile methods know that
product teams need a voice representing the
customer. Developers need personas, market
problems, and most of all, a prioritized list of
requirements. Agile methods advocate a role
called product owner to support the product
team with customer and market information.
Since the closest equivalent to product owner
in most companies is the product manager, it
seems natural to equate the two.
But product owner and product manager
are not the same. In fact, a product owner’s
responsibilities are just a small subset of
product management.
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 4
Agile teams tune practices and
processes for themselves to
create a method that is unique
to their environment.
What is a product owner?
The product owner is a new role, created
and defined by the Scrum Alliance
(www.scrumalliance.org). Product owners live
full-time with development teams—elaborating
users’ stories, managing sprint-level backlogs,
expanding specifications, and interpreting
product vision.
Most product companies already have
staff members with similar skills, such as a
requirements analyst or business analyst
(titles and job descriptions have shifted
over time, but product companies
have always needed to provide
developers with detailed, feature-
level information and UI guidance;
someone with intimate customer
experience is always necessary to
build great software).
The product owner addresses the agile
development teams’ intense need for real-time
input on user stories, user experience/user
interface, and requirements.
In Scrum, a single person must have final authority
representing the customer’s interest in backlog
prioritization and requirements questions. This
person must be available to the team at any time,
but especially during the sprint planning meeting
and the sprint review meeting. Challenges of being
a product owner:
• Resisting the temptation to “manage” the team.
The team may not self-organize in the way you
would expect. This is especially challenging if
some team members request your intervention
with issues the team should sort out for itself.
• Resisting the temptation to add more important
work after a Sprint is already in progress.
• Being willing to make hard choices during the
sprint planning meeting.
• Balancing the interests of competing
stakeholders.
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 5
Product owners can close the gap between
a product manager’s inbound role (that is,
understanding the needs of the marketplace)
and the development team’s need for product
direction (that is, understanding the detail of
personas and their problems).
There are, however, a few fundamentally flawed
assumptions built into the product owner role
that experienced product managers immediately
spot. These flaws become abundantly clear
when the product owner role is aligned against
pre-existing functions (e.g., requirements analyst),
which we would not expect to drive strategy:
1. The top determinant of a product’s
revenue success is whether it meets real
customer needs
2. Product owners can’t rank backlog
based on ROI
3. Real revenue is driven by pricing
and packaging
4. Creating successful benefits and feature
descriptions that truly sell products,
requires a detailed understanding of the
technology and a detailed appreciation
of the customer’s problem
Spotting fundamental flaws
The top determinant of a product’s
revenue success is whether it meets
real customer needs. Regardless of
what the development team builds, a
product without interested customers
is a failure. It’s the agile product
manager’s primary job to meet existing
customers and potential prospects
face-to-face and deeply understand
what they want.
Throughout the development process,
the product manager represents
customers against short-term trade-
offs. If there is a product owner, he
or she needs to channel the product
manager throughout the day, avoiding
short-term thinking that can come
from living with Development every
day and answering only to the
technical team. Remember: You can’t
understand customers without getting
out of the office.
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 6
Product owners can’t rank backlog
based on ROI. In fact, this task is
impossible for anyone to do, since
real business metrics and financial
projections don’t exist at the feature/
backlog/item level. Researchers tell us
that the only way to assign revenue at
the feature level is to perform conjoint
analysis on every feature. Will any
company perform this type of research
for each product project? Probably not.
A broader and more rigorous backlog
ranking approach, “prioritizing for
profit,” considers market opportunity
and corporate strategic fit at the
product level. Most important to
this process is someone who can
prioritize the issues of all stakeholders,
considering the needs of buyer and
user personas, key new markets, and
issues of internal stakeholders in Sales,
Marketing, Support, Development,
and others.
Every release must have at least one
feature (story, improvement) requested
by each major stakeholder group.
Figuring out the features for a release
is an organizational challenge, not a
technical challenge. The market-driven
product manager should determine
what goes into the final product;
a product owner cannot.
Real revenue is driven by pricing
and packaging. Product managers
typically own pricing; product
owners rarely do. And unless you
have a seasoned product manager
driving software pricing and
packaging, you could be leaving
revenue on the table.
In cases where large projects (products) are divided into
multiple teams, it makes good sense to have a product owner (or
requirements analyst or business analyst) assigned to each team—
just as we would have a development manager and program
manager (scrum master) and QA manager assigned to each team.
The point of integration for these teams, though, is a single
product manager. When the executives demand “one throat
to choke,” it’s the product manager who is responsible for
overall success of the result.
Creating successful benefits and
feature descriptions that truly
sell products, requires a detailed
understanding of the technology
and a detailed appreciation of
the customers’ problem. This
takes lots of practice, hands-on
field experience, and a clear view
from both sides. In our experience,
internally promoted technical staff
members almost never get this
right. Marketing materials created
under this approach are often
feature-heavy, too technical, and fail
to motivate the exchange of money.
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 7
Failure modes
Over the short term, we can easily see product owners operating without close alignment with a product manager.
Over the course of a release—or a half-dozen sprints—we repeatedly see a few failure modes:
• Trading off company-wide strategic product fit in favor of product-level features. Good product managers look
across the product line for ways to make the overall collection more valuable. Hermetically-sealed product teams tend
toward local optimization: what’s best for my release plan—without regard to portfolio-level needs. Yet Sales and
Marketing are constantly trying to cross-sell existing products into the current customer base. Without some strategic
thinking sneaking into every sprint-level prioritization, the company loses many chances to make money through
product bundling, cross-selling, integrated features, and old-fashioned customer opportunities.
• Assuming a few showcase customers represent the broader market. Experienced product managers know
that one customer is not a market—unless you are a custom development shop or internal IT group. It’s easiest to
believe that three customers previewing your product represent the entire market. Product managers have had this
awareness beaten into their heads after thousands of similar customer meetings and presentations. First-time product
owners tend to be naïve (or hopeful) that the input they get is both true and universal.
• Adding new features without pricing them. Product owners worry about completing the sprint; product managers
worry about making money. Every new feature is an opportunity to re-bundle, re-price, or encourage customers to
upgrade in order to capture more revenue.
• Starving the product architecture in favor of customer-visible features. Product managers and product owners
alike often neglect the architectural element—forgetting to incorporate system improvements into the backlog. To
ensure that system internals, architecture, “technical debt,” and other technical issues are kept in the priority, we add
the architecture itself as a stakeholder. That is how you keep the architecture healthy—both now and four releases
from now.
• Wandering from the roadmap. Development teams (and their product owners) concentrate on the next release,
but often lose sight of the 12- to 18-month roadmap and goals that achieve business results.
Real revenue is
driven by pricing and
packaging. Product
managers typically own
pricing; product owners
rarely do.
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 8
Product management is outwardly focused
Developers and engineers tend to see product managers as internal technical
resources, to be used as much for project management as product management.
For some companies, agile development methods seem to have made the product
management role even more internally focused—with product managers getting
pulled into deeper tactical, technical activities.
But spending so much time with internal technical teams means less time spent
outside the company in the market. As Pragmatic Marketing-trained product
managers know, you don’t learn anything about the market while sitting
at your desk.
There’s more to product management than supporting Development. Product
managers also work with Sales, Marketing, Support, and other departments. Most of
all, astute product managers work closely with the company’s senior executives.
The activity spectrum of product management
The activities of product management span the range from strategic to tactical.
Some product management activities are focused on the business of the product,
while others are centered more on the technical aspects of the product. Applying
this concept to a grid looks like this:
BUSINESS
TECHNICAL
STRATEGIC TACTICAL
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 9
Competitive
Landscape
Product
Roadmap
Innovation Requirements
Sales
Process
Presentations
& Demos
Launch
Plan
Status
Dashboard
Sales
Tools
Event
Support
Lead
Generation
Referrals &
References
Channel
Training
Channel
Support
Business
Plan
Positioning
Marketing
Plan
Win/Loss
Analysis
Distribution
Strategy
Buy, Build
or Partner
Buyer
Personas
Customer
Retention
Distinctive
Competence
Product
Profitability
User
Personas
Program
Effectiveness
Product
Portfolio
Technology
Assessment
Use
Scenarios
“Special“
Calls
Thought
Leadership
Collateral
Market
Definition
Pricing
Buying
Process
Customer
Acquisition
Market
Problems
Tactical Strategic
Business
Technical
MARKET READINESS SUPPORT STRATEGY BUSINESS PLANNING PROGRAMS
• How Development sees product managers
Technical /Strategic
Developers and other technical colleagues tend to see product
managers (and therefore, the product owner role) as a strategic,
technical resource. A developer’s view of product management
might include market requirements, technology assessment,
definition of user personas, and other technical artifacts. In
many cases, the team realizes the product manager is a market
encyclopedia and so, product teams want a customer expert
to be available all day, every day.
• How Sales sees product managers
Technical /Tactical
Have you ever known a sales person who didn’t see everyone in
the company as an a resource for selling? Product managers are
the preferred source for great product demos—they can explain
the internals of existing features and they know the future plans for
the product. Who wouldn’t want to take them on a sales call? So
salespeople often rely heavily on product managers as a technical,
tactical resource.
• How Marketing sees product managers
Business/Tactical
In most vendor organizations, the Marketing department is staffed
with experts in promotion rather than experts in technology.
And this makes sense. But without some technical abilities, these
promotions experts can’t do a very good job of positioning and
messaging. And technical product managers and product owners
are usually terrible at it too. That’s why so many companies
recruit product managers (or product marketing managers) into
the marketing department. Marketing people rely on product
management for tactical, business-oriented information in support
of their promotional, go-to-market plans.
• How the executive team sees product managers
Business/Strategic
Executive management relies on product management as a strategic
resource—the source for strategy and business thinking at the
product level. The executive team wants to see business plans and
product roadmaps.
Rather than defining one role, product management actually spans
four disciplines.
The Pragmatic Marketing
Framework
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 10
With this grid
in mind, there
are four ways
people within
the organization
typically look at
product managers:
Mapping product management activities
Product management is often ill defined and poorly understood in
technology companies; yet the role can be one that propels the company to
the next level of performance. Rather than running the business like a hobby,
effective product managers focus on both the business and the technical
aspects of product management.
The Pragmatic Marketing Framework describes the activities, artifacts, and
practices for defining technology products and delivering them to market.
From market analysis to channel support, product management entails
activities ranging from strategic to tactical and from less technical to quite
technical. These activities align loosely with the expectations of the four
groups: Development, Sales, Marketing, and corporate executives.
The most common organizational format is for one product manager
to perform all of the activities of the entire framework. It’s a big job, but
a satisfying one. It is the president of the product (or perhaps a better
metaphor is the parent of the product). In any case, it’s also what the
“agilists” call a “single, wringable neck.” A single voice of priority.
With one product manager, everyone knows where to go for the definitive
answer. But… as your business grows larger, the demands on this single
person grow greater and greater, and soon exceed the number of hours
available in a day.
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 11
Competitive
Landscape
Product
Roadmap
Innovation Requirements
Sales
Process
Presentations
& Demos
Launch
Plan
Status
Dashboard
Sales
Tools
Event
Support
Lead
Generation
Referrals &
References
Channel
Training
Channel
Support
Business
Plan
Positioning
Marketing
Plan
Win/Loss
Analysis
Distribution
Strategy
Buy, Build
or Partner
Buyer
Personas
Customer
Retention
Distinctive
Competence
Product
Profitability
User
Personas
Program
Effectiveness
Product
Portfolio
Technology
Assessment
Use
Scenarios
“Special“
Calls
Thought
Leadership
Collateral
Market
Definition
Pricing
Buying
Process
Customer
Acquisition
Market
Problems
MARKET READINESS SUPPORT STRATEGY BUSINESS PLANNING PROGRAMS
Product
Marketing
Manager
Product
Strategist
Product
Owner
Sales
Engineer
The four roles of a product manager
There are four distinct roles played by the product manager, which
is a much larger function than that defined by a product owner.
The four most common titles are product strategist, product
marketing manager, product owner, and sales engineer. The
diagram below shows the four roles aligned with the Pragmatic
Marketing Framework.
Each organization adapts these titles and the associated
activities to the way it does business. If you’re new to this product
management framework, download the e-book The Strategic Role
of Product Management.
It is common for product owners to report to the development
organization, but product managers are increasingly reporting
into their own department—separate from Development and
from Marketing.
As you can see, the role of
product management includes
the responsibilities of product
owner— plus much more.
As you can see, the role of product management
includes the responsibilities of product
owner—plus much more. The practical product
manager serves as a hub of market and product
information, relies on business and technical
savvy, and works closely with Development,
Marketing, Sales, and other departments. Most
of all, a product manager is the executive team’s
eyes and ears at the product level, making
strategic decisions on the future of the product.
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 12
Do We Really Need a Product Owner?
Many agile development teams think they need a product owner for every project, but
product owners address only a small portion of the agile product management challenge. The
product owner role has been created by the agile development community to focus on the
hour-by-hour demands of an agile team—even though software product companies typically
have a product manager and other existing resources to meet those needs.
A product manager’s focus is creating products that are delivered to a market full of customers,
not one-time projects delivered to a single customer. And if we have agile product managers
assigned to the product, do we ever need a product owner?
A thoughtful answer needs context, and must be based on the structure and talents of the
team. Agile development is scaling beyond single co-located teams and now includes
revenue-driven product organizations. So let’s consider four situations:
1. Single, co-located agile team
2. Large, co-located projects with multiple development teams
3. Geographically distributed development teams
4. My product manager isn’t doing a good job
and doesn’t know agile development
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 13
D
o
I
R
e
a
l
l
y
N
e
e
d
a
P
r
o
d
u
c
t
O
w
n
e
r
?
Single, co-located agile team
One agile product manager can handle all of the
demands from a product team that sits together. In
fact, one agile product manager should be able to
manage two product teams in the same building—even
factoring in travel, customer visits, and demands from
Marketing/Sales. We routinely (and confidently) allocate
50% of an experienced agile product manager to each
development team. When everyone sits together, there’s
no need for a product owner (or requirements analyst
or business analyst) on the team to supplement the
agile product manager.
Large, co-located projects with
multiple development teams
As products and projects grow, Development has
to create additional agile teams. This approach is
sometimes called the “scrum of scrums” approach,
where one backlog is split among three or more groups,
each of which has a development manager, project
manager (scrum master), QA group, etc. The experience
level of the agile product manager matters here, as well
as scale, team cohesiveness, and whether the groups
have radically different technical challenges. It’s critically
important that one person (the agile product manager)
continues to be fully responsible for the resulting
product and its revenue success, but it may be time
to provide some help.
Most product companies already have a range of
resources and talents to apply, so they might have
a junior product manager needing hands-on agile
experience under the guidance of a seasoned agile
product manager; business analysts and requirements
analysts with intimate knowledge of the specific
customer requirements; sales engineers on loan for
individual product releases; or someone formally
designated as a product owner. In all cases, the
product manager is delegating specific authority and is
responsible for overall execution, coordination, priorities,
and customer satisfaction. The product owner (by
any name) is assigned to remove roadblocks, research
questions, elaborate, clarify, motivate, and assist—but
also to raise issues of substance with the agile product
manager. So, product owners are optional for complex,
co-located projects. Product managers need to ask for
help if they need it, and executives should provide it.
This situation is all about trust, skills,
team-building, and managers being
brave enough to say what they think.
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 14
Geographically distributed development teams
When Development is split across time zones and continents, one product
manager can’t possibly provide the face-to-face daily input and leadership that
agile development demands. Even if the sub-projects are part of one product’s
overall architecture—and one agile product manager’s overall vision—you
need leadership on the ground in each location to keep the work of agile
moving. This usually includes a development manager, a project manager
(scrum master), test/QA manager, and a product owner. Here, the company
should provide some formal agile training to resources such as business
analysts, since they’ll be without much in-person guidance from their agile
product manager.
Plane flights are too slow, phone calls too impersonal, and hour-by-hour task
assignment changes posted to the walls of the War Room too complicated to
manage at a distance. Having someone in each office responsible for keeping
the team clear on user stories/backlogs seems essential. As above, this quickly
spins out of control unless the product owner (or equivalent) is tightly aligned
with the remote agile product manager, and quickly escalates issues to that
person. So, a product owner seems necessary for each remotely located
development team.
D
o
I
R
e
a
l
l
y
N
e
e
d
a
P
r
o
d
u
c
t
O
w
n
e
r
?
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 15
My product manager
isn’t doing a good job
and doesn’t know
agile development
Ask most agile development managers
in private, and this is what they really
worry about. They are way ahead of
their (non-agile) product managers
and are used to slow, second-hand,
poor-quality customer input. Hiring
a product owner is one way of
protecting the team from bad product
management. The thinking goes, “We
still won’t have good market inputs
or true customer-driven backlogs, but
at least we’ll manage our sprints well,
and our developer-side collaboration
will deliver something usable.”
This situation is all about trust, skills,
team-building, and managers being
brave enough to say what they think. It
should not be about creating another
new title in order to cover for a failing
product manager.
Coming back to our core beliefs as
“agilists” (we value individuals and
interactions over processes and
tools; we value collaboration over
contract negotiation), the leaders
of Development and Product
Management need to step up with
honest discussions such as:
• “Our product managers don’t have
any agile training. Let’s get them all
to class this month so we can stop
complaining about it.”
• “We need more of a kick-start,
especially since project timelines are
at risk. Let’s bring in an outside agile
product manager for two or three
iterations who can show us how it’s
done while getting everything
back on track.”
• “We all know that product manager
X was barely competent doing
waterfall, and is hopeless under
agile. Let’s replace him instead of
spreading the load.”
• “Development doesn’t understand
why product managers can’t be
here at Headquarters every single
day. Let’s give the development
team a half-day tutorial on what
(else) product managers do, and
why sitting at their desks every
single day leads to inevitable
strategic failure.”
• “Iteration Planning is always on
Mondays and Retrospectives are
always on Fridays. Can the agile
product managers schedule more
of their customer travel and sales
briefings mid-week?”
• “Developers want to hear even
more of what customers really
say. If we promise not to say
anything, can we sit in on your
next few conference calls?”
Product management veterans
have seen similar reactions from
other functional groups faced with
weak product management teams.
Marketing suddenly creates product
marketing managers for select
products rather than identifying the
one product manager who’s unable
to get his or her features/benefits
straight. Finance invents a “pricing
czar” to fill in for product managers
who stumble through the pricing and
packaging process without leadership
or strategy. Developers freely
interpret vague requirements and
hope they build marketable software.
Said another way, product
management is a very tough job,
and we need to do it well. Creating
product owners to cover our personal
shortcomings or lack of agile training
is treating the wrong disease. Let’s
make sure we’re doing our best agile
product management instead of
meekly letting Development redefine
our responsibilities. If we’re short
of trained, capable agile product
managers, let’s get busy recruiting
and mentoring and training them
to fill the real need.
So, do we really need
a product owner?
Sometimes—in the right context and
with distributed development teams
that need real-time, local help. Never
staff up a revenue-driven product
without an agile product manager, but
don’t assume that every agile team
needs a product owner.
D
o
I
R
e
a
l
l
y
N
e
e
d
a
P
r
o
d
u
c
t
O
w
n
e
r
?
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 16
Attend a training course or we can come to you
Subscribe to The Pragmatic Marketer digital magazine
Download Strategic Role of Product Management e-book
Pragmatic Marketing’s blog
Luke Hohmann ’s Agile PM blog
Rich Mironov’s Product Bytes
We hope you enjoyed this e-book and it gives you some food for thought.
If you want to learn more, check out the following.
By Pragmatic Marketing
Howa market-driven focus
leads companies to build
products people want to buy
The Strategic Role of
PRODUCT MANAGEMENT
rev 4-6-12
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 17
doc_342779028.pdf
The Strategic Role of Product Management When Development Goes Agile
...the best job to date of describing the yin
and yang of APO (Agile Product Owner) and
APM (Agile Product Manager). Moreover, the
authors are experts in the field of software
product management so they speak with
knowledge and credibility from the PM role.
Dean Leffingwell / Scaling Software Agility
About the Companies
Enthiosys is a management
consulting and training
firm that brings business
agility to software
companies and firms embedding software into their
products. As the leading authority on agile product
management, they help companies plan, design, build
and manage their products throughout their lifecycle.
Enthiosys works collaboratively with clients to gain
crucial insights on customer needs, translate them
into superior products, and make other key changes
to their product management process. Their approach
ensures that your people, products and processes
generate sustainable results after they’re gone.
Clients range from Fortune 500 multinationals to
technology start-ups, including companies such
as SAP, Hewlett Packard, VeriSign, Yahoo!, Trend
Micro, Qualcomm, Emerson Electric and Wyse.
Pragmatic Marketing’s
training is based
on the fundamental
belief that a company’s products need to be grounded
in a strategy that is driven by the market. They
combine this core principle with a team of instructors
who have real-world experience leading high tech
product teams, to deliver training seminars that
are informative, entertaining, and impactful.
Pragmatic Marketing’s courses cover everything
technology companies need to be successfully
market-driven, from understanding market problems
and personas, to creating effective requirements
and go-to-market strategies. To find out how you or
your company can join the growing international
community of more than 75,000 product management
and marketing professionals trained by Pragmatic
Marketing, visit www.pragmaticmarketing.com.
Copyright © 2012 Pragmatic Marketing, Inc. All rights reserved.
Copyright holder is licensing this under the Creative Commons License. Attribution 3.0.http://creativecommons.org/licenses/by/3.0/
Other product and/or company names mentioned in this e-book may be trademarks or registered trademarks of their respective companies and are the sole property of their respective owners.
Please feel free to post this ebook on your blog or e-mail it to whomever you believe would benefit from reading it.
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 2
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
We are uncovering better ways of developing soft ware by doing it
and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
agilemanifesto.org
That is,
while there is value
in the items on the right,
we value the items
on the left more.
Manifesto for
Agile Software Development
While software development teams have been
moving toward agile methods for years, many
product managers are only now becoming
aware of it. An agile approach applies
collaborative and continuous improvement
concepts to software development. It
emphasizes close collaboration between
development teams and customers; frequent
delivery of deployable code (in sprints); face-
to-face communication with customers; tight,
self-organizing teams; managing backlogs of
user stories to reduce requirements churn;
and identification of self-improvement
opportunities.
There is no single, definitive “agile method.”
Agile teams tune practices and processes for
themselves to create a method that is unique
to their environment. Broadly, agile methods
function as both an organizational philosophy
and a set of development methodologies.
When you adopt agile development methods,
you encounter new concepts, new artifacts,
new planning methods, and new roles and
relationships. It seems that agile teams do
everything in a new way. And, as you attempt
to integrate agile into your existing systems,
you’ll also attempt to map these new concepts
to your old, familiar concepts. Requirements
are now stories; iterations are now sprints.
And a product manager is now called a
Product Owner… right?
Wrong!
Companies adopting agile methods know that
product teams need a voice representing the
customer. Developers need personas, market
problems, and most of all, a prioritized list of
requirements. Agile methods advocate a role
called product owner to support the product
team with customer and market information.
Since the closest equivalent to product owner
in most companies is the product manager, it
seems natural to equate the two.
But product owner and product manager
are not the same. In fact, a product owner’s
responsibilities are just a small subset of
product management.
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 4
Agile teams tune practices and
processes for themselves to
create a method that is unique
to their environment.
What is a product owner?
The product owner is a new role, created
and defined by the Scrum Alliance
(www.scrumalliance.org). Product owners live
full-time with development teams—elaborating
users’ stories, managing sprint-level backlogs,
expanding specifications, and interpreting
product vision.
Most product companies already have
staff members with similar skills, such as a
requirements analyst or business analyst
(titles and job descriptions have shifted
over time, but product companies
have always needed to provide
developers with detailed, feature-
level information and UI guidance;
someone with intimate customer
experience is always necessary to
build great software).
The product owner addresses the agile
development teams’ intense need for real-time
input on user stories, user experience/user
interface, and requirements.
In Scrum, a single person must have final authority
representing the customer’s interest in backlog
prioritization and requirements questions. This
person must be available to the team at any time,
but especially during the sprint planning meeting
and the sprint review meeting. Challenges of being
a product owner:
• Resisting the temptation to “manage” the team.
The team may not self-organize in the way you
would expect. This is especially challenging if
some team members request your intervention
with issues the team should sort out for itself.
• Resisting the temptation to add more important
work after a Sprint is already in progress.
• Being willing to make hard choices during the
sprint planning meeting.
• Balancing the interests of competing
stakeholders.
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 5
Product owners can close the gap between
a product manager’s inbound role (that is,
understanding the needs of the marketplace)
and the development team’s need for product
direction (that is, understanding the detail of
personas and their problems).
There are, however, a few fundamentally flawed
assumptions built into the product owner role
that experienced product managers immediately
spot. These flaws become abundantly clear
when the product owner role is aligned against
pre-existing functions (e.g., requirements analyst),
which we would not expect to drive strategy:
1. The top determinant of a product’s
revenue success is whether it meets real
customer needs
2. Product owners can’t rank backlog
based on ROI
3. Real revenue is driven by pricing
and packaging
4. Creating successful benefits and feature
descriptions that truly sell products,
requires a detailed understanding of the
technology and a detailed appreciation
of the customer’s problem
Spotting fundamental flaws
The top determinant of a product’s
revenue success is whether it meets
real customer needs. Regardless of
what the development team builds, a
product without interested customers
is a failure. It’s the agile product
manager’s primary job to meet existing
customers and potential prospects
face-to-face and deeply understand
what they want.
Throughout the development process,
the product manager represents
customers against short-term trade-
offs. If there is a product owner, he
or she needs to channel the product
manager throughout the day, avoiding
short-term thinking that can come
from living with Development every
day and answering only to the
technical team. Remember: You can’t
understand customers without getting
out of the office.
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 6
Product owners can’t rank backlog
based on ROI. In fact, this task is
impossible for anyone to do, since
real business metrics and financial
projections don’t exist at the feature/
backlog/item level. Researchers tell us
that the only way to assign revenue at
the feature level is to perform conjoint
analysis on every feature. Will any
company perform this type of research
for each product project? Probably not.
A broader and more rigorous backlog
ranking approach, “prioritizing for
profit,” considers market opportunity
and corporate strategic fit at the
product level. Most important to
this process is someone who can
prioritize the issues of all stakeholders,
considering the needs of buyer and
user personas, key new markets, and
issues of internal stakeholders in Sales,
Marketing, Support, Development,
and others.
Every release must have at least one
feature (story, improvement) requested
by each major stakeholder group.
Figuring out the features for a release
is an organizational challenge, not a
technical challenge. The market-driven
product manager should determine
what goes into the final product;
a product owner cannot.
Real revenue is driven by pricing
and packaging. Product managers
typically own pricing; product
owners rarely do. And unless you
have a seasoned product manager
driving software pricing and
packaging, you could be leaving
revenue on the table.
In cases where large projects (products) are divided into
multiple teams, it makes good sense to have a product owner (or
requirements analyst or business analyst) assigned to each team—
just as we would have a development manager and program
manager (scrum master) and QA manager assigned to each team.
The point of integration for these teams, though, is a single
product manager. When the executives demand “one throat
to choke,” it’s the product manager who is responsible for
overall success of the result.
Creating successful benefits and
feature descriptions that truly
sell products, requires a detailed
understanding of the technology
and a detailed appreciation of
the customers’ problem. This
takes lots of practice, hands-on
field experience, and a clear view
from both sides. In our experience,
internally promoted technical staff
members almost never get this
right. Marketing materials created
under this approach are often
feature-heavy, too technical, and fail
to motivate the exchange of money.
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 7
Failure modes
Over the short term, we can easily see product owners operating without close alignment with a product manager.
Over the course of a release—or a half-dozen sprints—we repeatedly see a few failure modes:
• Trading off company-wide strategic product fit in favor of product-level features. Good product managers look
across the product line for ways to make the overall collection more valuable. Hermetically-sealed product teams tend
toward local optimization: what’s best for my release plan—without regard to portfolio-level needs. Yet Sales and
Marketing are constantly trying to cross-sell existing products into the current customer base. Without some strategic
thinking sneaking into every sprint-level prioritization, the company loses many chances to make money through
product bundling, cross-selling, integrated features, and old-fashioned customer opportunities.
• Assuming a few showcase customers represent the broader market. Experienced product managers know
that one customer is not a market—unless you are a custom development shop or internal IT group. It’s easiest to
believe that three customers previewing your product represent the entire market. Product managers have had this
awareness beaten into their heads after thousands of similar customer meetings and presentations. First-time product
owners tend to be naïve (or hopeful) that the input they get is both true and universal.
• Adding new features without pricing them. Product owners worry about completing the sprint; product managers
worry about making money. Every new feature is an opportunity to re-bundle, re-price, or encourage customers to
upgrade in order to capture more revenue.
• Starving the product architecture in favor of customer-visible features. Product managers and product owners
alike often neglect the architectural element—forgetting to incorporate system improvements into the backlog. To
ensure that system internals, architecture, “technical debt,” and other technical issues are kept in the priority, we add
the architecture itself as a stakeholder. That is how you keep the architecture healthy—both now and four releases
from now.
• Wandering from the roadmap. Development teams (and their product owners) concentrate on the next release,
but often lose sight of the 12- to 18-month roadmap and goals that achieve business results.
Real revenue is
driven by pricing and
packaging. Product
managers typically own
pricing; product owners
rarely do.
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 8
Product management is outwardly focused
Developers and engineers tend to see product managers as internal technical
resources, to be used as much for project management as product management.
For some companies, agile development methods seem to have made the product
management role even more internally focused—with product managers getting
pulled into deeper tactical, technical activities.
But spending so much time with internal technical teams means less time spent
outside the company in the market. As Pragmatic Marketing-trained product
managers know, you don’t learn anything about the market while sitting
at your desk.
There’s more to product management than supporting Development. Product
managers also work with Sales, Marketing, Support, and other departments. Most of
all, astute product managers work closely with the company’s senior executives.
The activity spectrum of product management
The activities of product management span the range from strategic to tactical.
Some product management activities are focused on the business of the product,
while others are centered more on the technical aspects of the product. Applying
this concept to a grid looks like this:
BUSINESS
TECHNICAL
STRATEGIC TACTICAL
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 9
Competitive
Landscape
Product
Roadmap
Innovation Requirements
Sales
Process
Presentations
& Demos
Launch
Plan
Status
Dashboard
Sales
Tools
Event
Support
Lead
Generation
Referrals &
References
Channel
Training
Channel
Support
Business
Plan
Positioning
Marketing
Plan
Win/Loss
Analysis
Distribution
Strategy
Buy, Build
or Partner
Buyer
Personas
Customer
Retention
Distinctive
Competence
Product
Profitability
User
Personas
Program
Effectiveness
Product
Portfolio
Technology
Assessment
Use
Scenarios
“Special“
Calls
Thought
Leadership
Collateral
Market
Definition
Pricing
Buying
Process
Customer
Acquisition
Market
Problems
Tactical Strategic
Business
Technical
MARKET READINESS SUPPORT STRATEGY BUSINESS PLANNING PROGRAMS
• How Development sees product managers
Technical /Strategic
Developers and other technical colleagues tend to see product
managers (and therefore, the product owner role) as a strategic,
technical resource. A developer’s view of product management
might include market requirements, technology assessment,
definition of user personas, and other technical artifacts. In
many cases, the team realizes the product manager is a market
encyclopedia and so, product teams want a customer expert
to be available all day, every day.
• How Sales sees product managers
Technical /Tactical
Have you ever known a sales person who didn’t see everyone in
the company as an a resource for selling? Product managers are
the preferred source for great product demos—they can explain
the internals of existing features and they know the future plans for
the product. Who wouldn’t want to take them on a sales call? So
salespeople often rely heavily on product managers as a technical,
tactical resource.
• How Marketing sees product managers
Business/Tactical
In most vendor organizations, the Marketing department is staffed
with experts in promotion rather than experts in technology.
And this makes sense. But without some technical abilities, these
promotions experts can’t do a very good job of positioning and
messaging. And technical product managers and product owners
are usually terrible at it too. That’s why so many companies
recruit product managers (or product marketing managers) into
the marketing department. Marketing people rely on product
management for tactical, business-oriented information in support
of their promotional, go-to-market plans.
• How the executive team sees product managers
Business/Strategic
Executive management relies on product management as a strategic
resource—the source for strategy and business thinking at the
product level. The executive team wants to see business plans and
product roadmaps.
Rather than defining one role, product management actually spans
four disciplines.
The Pragmatic Marketing
Framework
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 10
With this grid
in mind, there
are four ways
people within
the organization
typically look at
product managers:
Mapping product management activities
Product management is often ill defined and poorly understood in
technology companies; yet the role can be one that propels the company to
the next level of performance. Rather than running the business like a hobby,
effective product managers focus on both the business and the technical
aspects of product management.
The Pragmatic Marketing Framework describes the activities, artifacts, and
practices for defining technology products and delivering them to market.
From market analysis to channel support, product management entails
activities ranging from strategic to tactical and from less technical to quite
technical. These activities align loosely with the expectations of the four
groups: Development, Sales, Marketing, and corporate executives.
The most common organizational format is for one product manager
to perform all of the activities of the entire framework. It’s a big job, but
a satisfying one. It is the president of the product (or perhaps a better
metaphor is the parent of the product). In any case, it’s also what the
“agilists” call a “single, wringable neck.” A single voice of priority.
With one product manager, everyone knows where to go for the definitive
answer. But… as your business grows larger, the demands on this single
person grow greater and greater, and soon exceed the number of hours
available in a day.
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 11
Competitive
Landscape
Product
Roadmap
Innovation Requirements
Sales
Process
Presentations
& Demos
Launch
Plan
Status
Dashboard
Sales
Tools
Event
Support
Lead
Generation
Referrals &
References
Channel
Training
Channel
Support
Business
Plan
Positioning
Marketing
Plan
Win/Loss
Analysis
Distribution
Strategy
Buy, Build
or Partner
Buyer
Personas
Customer
Retention
Distinctive
Competence
Product
Profitability
User
Personas
Program
Effectiveness
Product
Portfolio
Technology
Assessment
Use
Scenarios
“Special“
Calls
Thought
Leadership
Collateral
Market
Definition
Pricing
Buying
Process
Customer
Acquisition
Market
Problems
MARKET READINESS SUPPORT STRATEGY BUSINESS PLANNING PROGRAMS
Product
Marketing
Manager
Product
Strategist
Product
Owner
Sales
Engineer
The four roles of a product manager
There are four distinct roles played by the product manager, which
is a much larger function than that defined by a product owner.
The four most common titles are product strategist, product
marketing manager, product owner, and sales engineer. The
diagram below shows the four roles aligned with the Pragmatic
Marketing Framework.
Each organization adapts these titles and the associated
activities to the way it does business. If you’re new to this product
management framework, download the e-book The Strategic Role
of Product Management.
It is common for product owners to report to the development
organization, but product managers are increasingly reporting
into their own department—separate from Development and
from Marketing.
As you can see, the role of
product management includes
the responsibilities of product
owner— plus much more.
As you can see, the role of product management
includes the responsibilities of product
owner—plus much more. The practical product
manager serves as a hub of market and product
information, relies on business and technical
savvy, and works closely with Development,
Marketing, Sales, and other departments. Most
of all, a product manager is the executive team’s
eyes and ears at the product level, making
strategic decisions on the future of the product.
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 12
Do We Really Need a Product Owner?
Many agile development teams think they need a product owner for every project, but
product owners address only a small portion of the agile product management challenge. The
product owner role has been created by the agile development community to focus on the
hour-by-hour demands of an agile team—even though software product companies typically
have a product manager and other existing resources to meet those needs.
A product manager’s focus is creating products that are delivered to a market full of customers,
not one-time projects delivered to a single customer. And if we have agile product managers
assigned to the product, do we ever need a product owner?
A thoughtful answer needs context, and must be based on the structure and talents of the
team. Agile development is scaling beyond single co-located teams and now includes
revenue-driven product organizations. So let’s consider four situations:
1. Single, co-located agile team
2. Large, co-located projects with multiple development teams
3. Geographically distributed development teams
4. My product manager isn’t doing a good job
and doesn’t know agile development
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 13
D
o
I
R
e
a
l
l
y
N
e
e
d
a
P
r
o
d
u
c
t
O
w
n
e
r
?
Single, co-located agile team
One agile product manager can handle all of the
demands from a product team that sits together. In
fact, one agile product manager should be able to
manage two product teams in the same building—even
factoring in travel, customer visits, and demands from
Marketing/Sales. We routinely (and confidently) allocate
50% of an experienced agile product manager to each
development team. When everyone sits together, there’s
no need for a product owner (or requirements analyst
or business analyst) on the team to supplement the
agile product manager.
Large, co-located projects with
multiple development teams
As products and projects grow, Development has
to create additional agile teams. This approach is
sometimes called the “scrum of scrums” approach,
where one backlog is split among three or more groups,
each of which has a development manager, project
manager (scrum master), QA group, etc. The experience
level of the agile product manager matters here, as well
as scale, team cohesiveness, and whether the groups
have radically different technical challenges. It’s critically
important that one person (the agile product manager)
continues to be fully responsible for the resulting
product and its revenue success, but it may be time
to provide some help.
Most product companies already have a range of
resources and talents to apply, so they might have
a junior product manager needing hands-on agile
experience under the guidance of a seasoned agile
product manager; business analysts and requirements
analysts with intimate knowledge of the specific
customer requirements; sales engineers on loan for
individual product releases; or someone formally
designated as a product owner. In all cases, the
product manager is delegating specific authority and is
responsible for overall execution, coordination, priorities,
and customer satisfaction. The product owner (by
any name) is assigned to remove roadblocks, research
questions, elaborate, clarify, motivate, and assist—but
also to raise issues of substance with the agile product
manager. So, product owners are optional for complex,
co-located projects. Product managers need to ask for
help if they need it, and executives should provide it.
This situation is all about trust, skills,
team-building, and managers being
brave enough to say what they think.
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 14
Geographically distributed development teams
When Development is split across time zones and continents, one product
manager can’t possibly provide the face-to-face daily input and leadership that
agile development demands. Even if the sub-projects are part of one product’s
overall architecture—and one agile product manager’s overall vision—you
need leadership on the ground in each location to keep the work of agile
moving. This usually includes a development manager, a project manager
(scrum master), test/QA manager, and a product owner. Here, the company
should provide some formal agile training to resources such as business
analysts, since they’ll be without much in-person guidance from their agile
product manager.
Plane flights are too slow, phone calls too impersonal, and hour-by-hour task
assignment changes posted to the walls of the War Room too complicated to
manage at a distance. Having someone in each office responsible for keeping
the team clear on user stories/backlogs seems essential. As above, this quickly
spins out of control unless the product owner (or equivalent) is tightly aligned
with the remote agile product manager, and quickly escalates issues to that
person. So, a product owner seems necessary for each remotely located
development team.
D
o
I
R
e
a
l
l
y
N
e
e
d
a
P
r
o
d
u
c
t
O
w
n
e
r
?
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 15
My product manager
isn’t doing a good job
and doesn’t know
agile development
Ask most agile development managers
in private, and this is what they really
worry about. They are way ahead of
their (non-agile) product managers
and are used to slow, second-hand,
poor-quality customer input. Hiring
a product owner is one way of
protecting the team from bad product
management. The thinking goes, “We
still won’t have good market inputs
or true customer-driven backlogs, but
at least we’ll manage our sprints well,
and our developer-side collaboration
will deliver something usable.”
This situation is all about trust, skills,
team-building, and managers being
brave enough to say what they think. It
should not be about creating another
new title in order to cover for a failing
product manager.
Coming back to our core beliefs as
“agilists” (we value individuals and
interactions over processes and
tools; we value collaboration over
contract negotiation), the leaders
of Development and Product
Management need to step up with
honest discussions such as:
• “Our product managers don’t have
any agile training. Let’s get them all
to class this month so we can stop
complaining about it.”
• “We need more of a kick-start,
especially since project timelines are
at risk. Let’s bring in an outside agile
product manager for two or three
iterations who can show us how it’s
done while getting everything
back on track.”
• “We all know that product manager
X was barely competent doing
waterfall, and is hopeless under
agile. Let’s replace him instead of
spreading the load.”
• “Development doesn’t understand
why product managers can’t be
here at Headquarters every single
day. Let’s give the development
team a half-day tutorial on what
(else) product managers do, and
why sitting at their desks every
single day leads to inevitable
strategic failure.”
• “Iteration Planning is always on
Mondays and Retrospectives are
always on Fridays. Can the agile
product managers schedule more
of their customer travel and sales
briefings mid-week?”
• “Developers want to hear even
more of what customers really
say. If we promise not to say
anything, can we sit in on your
next few conference calls?”
Product management veterans
have seen similar reactions from
other functional groups faced with
weak product management teams.
Marketing suddenly creates product
marketing managers for select
products rather than identifying the
one product manager who’s unable
to get his or her features/benefits
straight. Finance invents a “pricing
czar” to fill in for product managers
who stumble through the pricing and
packaging process without leadership
or strategy. Developers freely
interpret vague requirements and
hope they build marketable software.
Said another way, product
management is a very tough job,
and we need to do it well. Creating
product owners to cover our personal
shortcomings or lack of agile training
is treating the wrong disease. Let’s
make sure we’re doing our best agile
product management instead of
meekly letting Development redefine
our responsibilities. If we’re short
of trained, capable agile product
managers, let’s get busy recruiting
and mentoring and training them
to fill the real need.
So, do we really need
a product owner?
Sometimes—in the right context and
with distributed development teams
that need real-time, local help. Never
staff up a revenue-driven product
without an agile product manager, but
don’t assume that every agile team
needs a product owner.
D
o
I
R
e
a
l
l
y
N
e
e
d
a
P
r
o
d
u
c
t
O
w
n
e
r
?
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 16
Attend a training course or we can come to you
Subscribe to The Pragmatic Marketer digital magazine
Download Strategic Role of Product Management e-book
Pragmatic Marketing’s blog
Luke Hohmann ’s Agile PM blog
Rich Mironov’s Product Bytes
We hope you enjoyed this e-book and it gives you some food for thought.
If you want to learn more, check out the following.
By Pragmatic Marketing
Howa market-driven focus
leads companies to build
products people want to buy
The Strategic Role of
PRODUCT MANAGEMENT
rev 4-6-12
Living in an Agile World: the Strategic Role of Product Management when Development goes Agile 17
doc_342779028.pdf