Revenue Products need Product Managers, not Product Owners
Sunday, September 21, 2008 at 07:06PM {This has kicked off a lively discussion and two follow-on posts: So When Do I Need a Product Owner? and How Are We Defining Product Owners? Enjoy! - Rich Mironov}
Product Managers are responsible for the overall market success of their products, not just the delivery of software. In the Agile world, a new title is emerging - the Product Owner - which covers a small subset of the product management role and can lead to role confusion. Here, we'll explain why revenue-producing products need full-fledged Agile Product Managers.
Whenever we talk about roles and organization, setting context is critically important. Our focus here is on revenue-producing products and services: software that companies create to bring in money. (This is in strong contrast to internal IT projects.)
While software development teams have been moving toward Agile approaches for years, Product Managers are just now becoming aware of it. Agile 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; tight, self-organizing teams; managing backlogs of user stories to reduce requirements churn; and identification of self-improvement opportunities. Agile teams tune practices/processes for themselves, so there is no single definitive "Agile" method. Broadly, Agile functions both as an organizational philosophy and a set of development methodologies.
For Product Managers, Agile presents new opportunities and redefines many product management processes/ deliverables. Agile Product Managers interact with their development teams much more often, and more intensively, than under waterfall approaches. The traditional MRD (Market Requirements Document) is exploded into more (and more relevant) items including user stories, epics, prioritized backlogs, and release plans. Product Managers participate in sprint-level reviews, bring in customers earlier for product previews, and intensively rework the backlog to address changing market needs. Agile just demands more from Product Managers.
In general, Agilists don't understand product management, and Product Managers are new to Agile. So we need to recap roles and deliverables before we can clarify them. Let's start with Product Managers.
What Do Product Managers Do?
Product Managers bear primary responsibility for the success of their products (services). They drive vision, roadmaps, target segments, market success metrics and customer acceptance. When executives demand one neck to choke, a Product Manager steps forward.
Product managers serve three distinct constituencies: technical teams (who build products), marketing/sales teams (who deliver customers and revenue) and executives (who drive strategy and resources):
- Development teams need vision, requirements, priorities, personas, user stories, and market information from Product Managers. They collaborate on
release plans, roadmaps and architectures. In return, Development produces working software and finished products.
- Sales and marketing teams need customer-oriented materials, messages, pricing and strategy. They pass these through to customers. Customers are benefit-focused instead of feature-obsessed, demanding simple information and clear usage scenarios. Responses from customers are often unflinching critiques of the products we love.
- Executives manage the company's portfolio of products and people. They need roadmaps, revenue and resource forecasts by product, and competitive intelligence. In return, they give Product Managers permission to pursue selected markets.
Thus Product Managers bridge between developers, markets and executives. This requires skills as a simultaneous translator, reformulating information for each audience. Most importantly, the Product Manager represents the customers to each internal organization.
When we shift to an Agile context for revenue-producing software, Agile Product Managers have more (and different) deliverables for Development. MRDs are exploded into items that are smaller, more focused, and timed to match the development cycle: roadmaps for sprints and releases; constantly current backlogs that define priorities for upcoming sprints; target market positioning (or vision); user stories which define a single customer activity; epics that combine many user stories. These new artifacts contain the same essential ingredients as our old MRD but transformed for adaptability, clarity and alignment with Agile software teams. While Product Managers have often been at arms' length with their development teams, Agile brings them cheek-to-cheek.
What Is A Product Owner?
Product Owner is a new role, created and artificially defined by the Scrum Alliance. Product Owners sit with their development teams full-time, elaborating users stories, managing sprint-level backlogs, expanding specifications, and interpreting product vision. Most product companies already have staff with similar skills, such As 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). Product Owners are typically nominated from project management or technical analyst roles.
The Product Owner addresses Agile development teams' intense need for real-time input on user stories, user interface design, and requirements when Agile Product Managers are inevitably away from their desks. (See 1, 2, 3, 4.) And the company absolutely requires that Agile Product Managers go into the field to wrestle with real customers and prospects, instead of staying sheltered in the lab. Product Owners represent their Agile Product Managers during the half of each week when PMs are servicing executives, sales & marketing, customers and partners.
Pragmatic Marketing's Framework provides an ideal way to scope the two roles.
Product Managers are responsible for overall success of their products. This ranges from market strategy to technical tactics to outbound product messaging. For smaller products or smaller companies, one Product Manager covers the entire Framework. This is a challenge, but one that Product Managers take on. With larger products and additional staff, the Product Manager role may be split into technical Product Managers and outbound product marketers, each covering about half of the Framework.
Product Managers own any organizational gaps, and cross departmental boundaries to get their products to market. Even when they report up through Engineering, they know they have obligations to customers, Marketing, Sales, and the executive team.
Product Owners cover roughly four boxes in the lower middle column: these are mostly technical, semi-strategic tasks, and time-critical to the development team: elaborating user stories, keeping sprints aligned with customer releases, managing sprint-level backlogs, and arranging customer previews. If a development team has both an Agile Product Manager and a Product Owner, the two must be in tight and constant alignment to avoid whipsawing the team.
Thus having a Product Owner without an Agile Product Manager means that strategic technical tasks as well as strategic business tasks are not assigned. In addition, clear outbound messaging and communications with Marketing/ Sales/customers doesn't happen, forcing external groups to come back repeatedly to the development team for marketing-level information (features, benefits, target markets, segments, and qualification). Finally, executives lose visibility into portfolio-level business issues and trends. Product Owners don't have the scope of responsibility or cross-functional experience to drive product success where it most often fails – beyond the reach of the development team.
How Did We Get Here?
Product management has never been an easy role, and is in short supply everywhere. Agile demands even more of a Product Manager than waterfall, since the Agile Product Manager interacts with the team daily/weekly, has a continuous stream of smaller deliverables, is in demand for customers and partners, etc. Agile development teams want constant access to someone who can interpret and elaborate on user stories, requirements and priorities.
Effectively, Development has defined a new position that is 100% dedicated to feeding their hour-by-hour tactical needs. Since Development has little visibility into the Product Manager’s broader role, this means creating a job that does only those things Development needs right now, and is always available onsite. Also, much of Agile grew up in non-revenue IT organizations which product management has been missing or hugely understaffed.
So can't we simply have Product Owners do the portion of Agile product management work that we need inside Development? Sounds good… Product Owners are a great way to close the gap between an Agile Product Manager's inbound role and the shifting demands of the marketplace. There are a few fundamental mis-assumptions, though, built into the Product Owner role. Experienced Product Managers spot these, immediately:
1. The top determinant of a product's revenue success is whether it meets real customer needs and is targeted at appropriate market segments. 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 customers/prospects face-to-face and deeply understand what they want. Then, throughout the development process, represent customers against short-term trade-offs. If there is a Product Owner, s/he needs to channel the Product Manager throughout the day, avoiding short-term thinking that can come from sitting with Development every day, answers only to the technical team. You can't understand customers without getting out of the office a lot.
2. Product Owners can't rank backlog based on ROI. In fact, this is impossible for anyone to do, since real business metrics and financial projections don't exist at the feature/backlog/item level. With apologies to Ken Shwaber, asking a Product Owner to rank backlogs based on ROI encourages muddy thinking and hand waving.
We recommend a broader and more rigorous backlog ranking approach of "Prioritizing for Profit" that does not require item-level financial ROI but does weight revenue segments, company strategy, etc. Most important to this process: someone responsible for story-level prioritization answering to internal and external stakeholders (Sales, Marketing, Support, Development, etc.) is allowed to weight stakeholders against each other, and can characterize tasks along each dimension. We deeply believe that every single release must have at least one feature (story, improvement) requested by each major stakeholder group – and figuring this out is an organizational challenge, not a technical challenge. When we compare Agile Product Manager to Product Owner roles, training, and who gets fired for product failures, this is clearly a product management job.
3. Real revenue is driven by pricing and packaging. We've rarely seen a Product Owner who understands pricing, let alone defining a pricing strategy and getting executive/ Sales /Marketing buy-off on pricing. Unless you have a seasoned Product Manager driving software pricing and packaging, you'll be leaving revenue on the floor.
4. 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 folks rarely get this right. Their marketing materials are feature-heavy, too technical, and fail to motivate the exchange of money. Without smart product management, products sound bland and unexciting. And don't bring expected much revenue.
Then we need both Product Managers and Product Owners?
This makes good sense in a world of infinite resources. Having a Product Owner work under the Product Manager’s direction (as we've seen for years with requirements analysts and business analysts) is a great arrangement. In practice, this often falls down because [1] there isn't budget/resources to staff both positions, and the hiring manage is asked which of the two positions to fill, or [2] we confuse the Product Owner for the Product Manager and assume that strategic work will also get done.
In cases where large projects (products) are divided geographically into multiple teams, having a Product Owner is critical – just as much as having a development manager and program manager (scrum master) and QA manager assigned to each team. There's no way for a remote Product Manager to service the team. Product-level integration for geographically split teams, is still the Product Manager, though. When the executives demand one neck to choke, it's the Product Manager who is responsible for overall coordination and success of the result.
Failure Modes
Over the short term, we can easily see Product Owners (or requirements analysts) operating without close alignment with a Product Manager. Over the course of a release - or half a dozen sprints - we see a few failure modes repeatedly:
- Trading off company-wide strategic product fit in favor of product-level features. 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. Good Product Managers look across the product line for ways to make the overall collection more valuable. 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. It's easiest to believe that the three customers previewing your code represent the market. They don't (unless you are a custom development shop or internal IT group). Product Managers have had this awareness beaten into their heads after thousands of dissimilar customer meetings and presentations. First-time Product Owners tend to be naïve (or hopeful) that the input they get is true and universal.
- Adding in new features without pricing them. Product Owners worry about completing the sprint; Product Managers worry also about making money. Every new feature is an opportunity to rebundle, reprice, encourage customers to upgrade, capture more revenue. We routinely see software vendors leaving 15% of their value on the floor because they don't remember to assign incremental economic value to new releases.
- Starving the product architecture in favor of customer-visible features. Developers often don't give themselves permission to put architectural improvements into the backlog. Product Managers need to stand up for their products (assign the architecture a persona, and make sure it is heard from it during ranking sessions!) to keep the architecture healthy 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-18 month roadmaps and goals that achieve business results.
Sound Bytes
Product Managers are essential to the technical and commercial success of revenue-generating software. If budgets and staffing allow, adding a Product Owner can be of significant value to development team. Confusing the two - or staffing only the Product Owner position - invites a strategic failure to meet company objectives.
Reader Comments (19)
This is the best summary I've read on the need to separate the success of a release (PO's job) from the success of a product (PM's job) in Agile companies.
An addition that might be interesting to some readers: At Rally, we've gone the route of hiring a PO for each development scrum, while we have one PM per product. OK, that's a lie, we almost have one PM per product, some PM's have two products. As our newer products grow their revenue and user base they deserve their own PM.
THe point is, we're finding the number of POs needs to pretty closely match the number of development's scum teams. As products mature from launch into success, you will naturally grow development. Because scrums have optimal sizes around 10 or less you'll be refactoring the number of scrum teams. The failure mode is to make your POs service too many scrum teams for too long.
As an executive, what I notice first in this failure mode is that our prioritization discipline around business needs starts to suffer, along with my undestanding of the real-world tradeoffs we're making in our delivery roadmap. IOW, roadmaps fall out of date and ramifications of today's decisions on the next few releases are lost. Not a great recipe for product success. I guess the saving grace is that when releases are only a couple months apart these misses aren't as potentially fatal as they use to be :-)
I agree with most of the sentiments but frankly feel like this article is missing some comment on the premise for the need for an agile product owner. The need is flawed. If the developers "need a throat to choke" to better understand requirements and stories they should go back to the customer proxy, and that's the product manager not someone else who happens to breathe the same air most of the time.
the folks at Enthiosys have recently posted an article on this topic and use the following diagram to indicate the activities the 'Product Owner' is responsible for...
I enjoyed reading your post. The role of the product manager and product owner will differ slightly depending on the type of product you are managing, the type of organisation you work for and the industry/market space you are operating in. The roles can be significantly different between individuals with the same job title who
work for the same company and even the same department. One thing is
for sure you need both types of roles for cutting edge software and/or
on-line product development. Refer toPart #9 The role of the Product Manager in
Scrum for more details and
What’s Product Management like a Year after Implementing Agile for a case study of successfully implementing agile using the two roles. Derek all about product
management
This question has been a hot topic at work of recent times as this role has evolved (and some may say distorted) since the implementation of Agile. One of my colleagues passed on which added more fuel to the debate.
It would seem there is a greater debate about what a product manager is in terms of role definition. If you’re a product manager I’d be interested in what you do compared to others, like myself in the same field...
[...] The Cranky Product Manager knows that many Product Management bloggers believe that this problem is solved if you separate the market / customer-facing Product [...]
See also http://crankypm.com/2007/04/ on "So You Think “Agile” Methodologies Exempt You From Product Management?"
Agile often talks about refactoring to an architecture, and then you would also see refactoring away from that one, or architecture in flux. Your comment about giving the architecture a persona is a great solution, particularly if you've designed a marketure (Hohmann), technical architecture that supports your marketing strategy, such as moving to SaaS, or sublimating tasks for the late market, into your products and marketing efforts. A marketure should be a stable long-range thing.
[...] just noted a new post from the folks at enthyosis who published the following article Revenue Products need Product Managers, not Product Owners. [...]
An excellent definition of the Product Manager and Product Owners roles and their need in an Agile environment.
The article highlights but does not solve what I believe may be a common problem, we do not live in a world of infinite resources and one person may have to fulfill both roles in many organizations. How can this be accomplished in an efficient repeatable manner without quickly burning out the resource?
[...] Revenue Products need Product Managers, not Product Owners [Enthiosys] [...]
Great conversation. For those of you in the Toronto area join us at ProductCampToronto on November 2nd. Here's the link: http://barcamp.org/ProductCampToronto
[...] Revenue Products need Product Managers, not Product Owners | enthiosys agile product management A good summary of the roles of both the product manager and owner. (tags: methodology management agile product.owners product.managers) [...]
Great article / post, Rich.
I feel like, with my personal experiences, I have to point out one thing when it comes to smaller companies. Specifically, start-ups.
Now, I've only ever been a part of venture-backed start-ups, so that's all I can speak too. Your mileage may vary.
But, as a PM in these scenarios, I am not held accountable for revenue of the products I manage. I am accountable to make sure the right things are being built and delivered to market - but at the end of the quarter, it's the CEO, not me, that's going in front of the board to explain how we achieved revenue targets, or not.
Now, you may say, "well, yeah - but you are in the room with the CEO before that board meeting talking about why or why not revenue was hit or missed."
Maybe - but being a part of that process is because I am part of the management team and report to the CEO. Not because everyone is looking to me for why we have no cash flow for "my" products.
At a certain size, this would stop as a function of scale. However, smaller companies mean it's really the CEO (and in some cases, the founder) that's responsible (maybe a VP, Sales) and he has put a team in place to help him deliver the overall product to key stakeholders.
[...] Revenue Products need Product Managers, not Product Owners | enthiosys agile product management A great summary fo the role of Product Managers and the differentiation between Product Owners. (tags: product.owners product.managers product methodology agile) [...]
[...] before I started applying agile methods within a new team. I’ve been enjoying the posts from Enthiosys, and Dean Leffingwell’s Scaling Software Agility blogs, and sharing them with my product team. [...]
[...] of Product Management within the ISV (Independent Software Vendor) community. In one fairly pointed article, for example, Rich Mironov of Enthyosis comments: “Product Managers are responsible for the [...]
[...] perspective on the product owner role, you might wanna check out Rich Mironov’s article, Revenue Products need Product Managers, not Product Owners This was written by Joakim. Posted on Tuesday, February 17, 2009, at 8:20 pm. Filed under Agile. [...]
Rich, great article. Here is my opinion on the role split...if a PM does not touch all stakeholders for the commercial success of a product, including Marketing, Sales, Legal, Technical Support, Executives,etc. the role is NOT product management. Period. If someone's job is defined as working with only one stakeholder (such as product development), then the role should not be classified as Product Management. No debate found here.
I agree that a business analyst or requirements analyst role is similar to a Product Owner in the Agile sense, however I prefer the role to be described as a "Product Planner". Even outside Agile, there are too many "Product Managers" that lack the experience or skills to manage all aspects of a product success. The new emerging "Product Owner" role is also misleading and trying to distinguish the two can be difficult, especially for recruiters. I suggest "Product Planner" is more appropriate to differentiate actual job description and scope of responsibility. A Product Manager may play the role of a Product Planner, but this is not always the case vice versa especially as the organization scales.
Michael J. Salerno
Co-founder, Boston Product Management Association
[...] um texto muito interessante, entitulado Revenue Products need Product Managers, not Product Owners, sobre as responsabilidades dos gestores de produtos. O texto inteiro é controverso pois reduz o [...]