I often get asked what characteristics a product owner should exhibit. Even though the answer depends on a number of factors including the type of the product, its importance, complexity and newness as well as the size of the project, successful product owners I have worked with share the attributes discussed below.
Visionary and Doer
The product owner is a visionary who can envision the final product and communicate the vision. But the product owner is also a doer who sees the vision through to completion. This includes describing requirements, closely collaborating with the team, accepting or rejecting work results, and steering the project by tracking and forecasting its progress. As an entrepreneur, the product owner facilitates creativity; encourages innovation; and is comfortable with change, ambiguity, debate, conflict, playfulness, experimentation, and informed risk taking.
Leader and Team Player
“Good business leaders create a vision, articulate the vision, passionately own the vision, and relentlessly drive it to completion,” says Jack Welch, GE’s former chairman and CEO. The product owner is just such a leader. As the individual responsible for the product’s success, the product owner provides guidance and direction for everyone involved in the development effort and ensures that tough decisions are made. For instance, should the launch date be postponed or should less functionality be delivered? At the same time, the product owner must be a team player who relies on close collaboration with the other Scrum team members, yet has no formal authority over them. You can think of the product owner as primus inter pares, first among peers, regarding the product.
Being a leader and team player can be a hard line to toe. By no means should the product owner dictate decisions, yet at the same time neither should the product owner be indecisive or employ a laissez-faire management style. Instead, the individual should act as a shepherd for the innovation process, guiding the project and seeking team consensus in the decision-making process. Making decisions about the product collaboratively ensures the team’s buy-in, leverages the team’s creativity and knowledge, and results in better decisions. Working this way requires facilitation and patience because team members often have to disagree and argue first before a new solution can be synthesized from the different ideas and perspectives.
Communicator and Negotiator
The product owner must be an effective communicator and negotiator. The individual communicates with and aligns different parties, including customers, users, development and engineering, marketing, sales, service, operations, and management. The product owner is the voice of the customer, communicating customer needs and requirements and bridging the gap between “the suits” and “the techies.” Sometimes this means saying no and other times negotiating a compromise.
Empowered and Committed
The product owner must have enough authority and the right level of management sponsorship to lead the development effort and to align stakeholders. An empowered product owner is essential for leading the effort to bring the product to life. The product owner must have the proper decision-making authority—from finding the right team members to deciding which functionality is delivered as part of the release. The individual must be someone who can be entrusted with a budget and at the same time has the ability to create a work environment that fosters creativity and innovation. Finally, the product owner must be committed to the development effort.
Available and Qualified
The product owner must be available and qualified to do a great job. Being the product owner is usually a full-time job. It is important to give product owners enough time to sustainably carry out their responsibilities. If the individual is overworked, the project’s progress suffers and the resulting product may be suboptimal. Being adequately qualified usually requires an intimate understanding of the customer and the market, being passionate about the user experience, and the ability to communicate needs and describe requirements, to manage a budget, to guide a development project, and to be comfortable working with a cross-functional, self-organizing team.
Nobody is Perfect
Before you now look for the perfect product owner or worry that you might not fit the bill, be aware that product owners usually need time and support to transition into the role and to acquire the necessary skills. And nobody is perfect: Every product owner has some strengths that facilitate playing the role as well as some weaknesses that can make it challenging. A product owner may be very good at envisioning the product, talking to customers, and creating the product roadmap but may not be used to work closely with a bunch of techies or lack the necessary release planning skills, for instance. A common challenge is finding employees with the necessary breadth and depth of knowledge and experience to do the job well.
More Information
You can find out more about the product owner role in my book Agile Product Management with Scrum: Creating Products that Customers Love available now on amazon.com. The book dedicates a whole chapter to the product owner role and provides more information about the desirable product owner characteristics. Why not register for one of my upcoming product owner classes to learn through dialogue and exercises what it takes to be an effective product owner. I also teach in-house product owner courses and run in-house product owner workshops.
This copy of my new book Agile Product Management with Scrum arrived a few days ago on my desk fresh off the press. Needless to say, seeing the final product after two years of hard work was very exciting, and I was well chuffed!
But I could not have written the book without the support of many people. Two played a particularly important role: Mike Cohn acted as my shepherd patiently reading and re-reading chapters as they evolved. My wife Melissa Pichler did not only provide feedback and encouragement on sections and chapters as they emerged but also gave me the time and space to write the book.
Many thanks to everyone else who helped with the book by reviewing chapters or by sharing information (in alphabetical order): Lyssa Adkins, Geir Amsjø, Markus Andrezak, Gabrielle Benefield, Robert Bogetti, Thomke Buhl, Marty Cagan, Sabine Canditt, John Clifford, Alistair Cockburn, Jens Coldeway, Kaustabh Debbarman, Pete Deemer, Chris Fry, Steve Greene, Roland Hanbury, Kevlin Henney, Ben Hogan, Clinton Keith, Andreas Klinger, Hans-Peter Korn, Jochen Krebs, Craig Larman, Bill Li, Lowell Lindstrom, Catherine Louis, Rodrigo Luna, Artem Marchenko, Jason Martinez, Ralph Miarka, Philip Missler, Bent Myllerup, Jeff Patton, Tobias Pichler, Brett Queener, Cesário Ramos, Dan Rawsthorne, Simon Roberts, Stefan Roock, Rene Rosendahl, Johanna Rothman, Kenneth Rubin, Martin Rusnak, Hans-Peter Samios, Bob Schatz, Andreas Schliep, Ken Schwaber, Christa Schwanninger, Karl Scotland, Martin Shaw, Lisa Shoop, James Siddle, Michele Sliger, Preston Smith, Dieter Stefanowitz, Jeff Sutherland, Mads Troels Hansen, Bas Vodde, Geoff Watts, Harvey Wheaton, Rüdiger Wolf, Elizabeth Woodward, and Lv Yi.
The book is available now at amazon.com! It should just be a matter of days before the book is on sale in Europe.
We all want to create great products – products that customers love and that meet or exceed our financial goals. But the odds of failure are high: Cooper states a failure rate of 25% to 45% for new products in his book Winning at New Products (third edition); some studies reveal even higher odds of failure. Markets develop unexpectedly and customer reaction is hard to predict.
Luckily, agile practices help us increase the likelihood of creating great products. While there are many factors at play, I have found that three practices are particularly important.
Shared Product Vision
Ensure that you have a shared vision in place that describes the target customers and users, the needs the product is going to address and what the product will roughly look like and do. Consider not only the key functional attributes but also non-functional ones including user experience and operational qualities such as performance and robustness. Use prototypes and mock-ups to develop the vision and to gather feedback from target customers and users.
Minimal Marketable Product
Envision the minimal marketable product – a product with minimum functionality that meets the selected customer needs. This shortens time-to-market and allows you to find out quickly how the market responds. If the response is not great then adapt then product to better meet the customer needs. Note that even if you carefully select the target customers and users to gather early feedback as described below, their views might not be representative for the entire market or market segment. And hardly ever is the first version of a product perfect.
Early and Frequent Customer Feedback
Third, gather early customer and user feedback by inviting (selected) customers and users to sprint review meetings and by releasing product increments early and frequently. This integrates customers and users into the development process, and it lets the product evolve based on their feedback. It also shows you quickly if you are shooting for the right goal or if your product vision is ill-conceived.
Find out more about creating great products in my book Agile Product Management with Scrum or contact me for more information. The book discusses creating a shared vision, envisioning the minimal marketable product, prototyping, early and frequent releases, and involving customers and users in the sprint review meetings in greater detail.
“The product manager’s job is to oversee all aspects of a product or service line to create and deliver superior customer satisfaction while simultaneously providing long-term value for the company,” writes Linda Gorchels in the third edition of The Product Manager’s Handbook. This sounds similar to Ken Schwaber’s description of the product owner role in the Scrum Guide: “The Product Owner is the (…) person responsible for (…) ensuring the value of the work the team performs.” So what’s the difference between a product manager and a product owner?
Working as the product owner implies taking on many product management responsibilities including understanding the market, describing product functionality, and preparing the product launch. This makes product managers well suited to play this new role. But a product owner is more than just a re-branded product manager: Product owners tend to take on a wider range of duties, which makes the role multi-faceted and challenging. The following formula captures this insight:
Product Owner = Product Manager + x
My experience suggests that the x above comprises additional strategic duties including envisioning the product and maintaining the product roadmap as well as further tactical ones, such as collaborating with the development team throughout the development effort, writing user stories, carrying out release planning, and managing stakeholders. Consequently, product owners often require more authority and more focus to do their job well. Note that product ownership is teamwork in Scrum: Requirements are no longer identified and described by one person. Product owner, ScrumMaster and team collaborate on a regular basis to groom the product backlog.
Working as a first-time product owner is hence a new experience and challenge. The right training and coaching measures can help product owners get up to speed faster. “Early immersion and training of the product owners in agile principles, product backlog creation, user story design and estimation and planning is key to the success of any agile team. Also, beyond initial training, continuous product owner coaching throughout the rollout is necessary to ingrain the new process into the culture,” write Fry and Greene about their experience at Salesforce.com in their article “Large Scale Agile Transformation in an On-Demand World.”
You can find more information on the product owner role, its duties and helpful practices in my book Agile Product Management with Scrum. I also advise and coach product owners. Have a look at my services and get in touch to discuss how they can benefit your product owners.
A new article on business analysis and agile based on interviews with a group of people including Ken Schwaber, Alistair Cockburn, Ellen Gottesdiener, and myself reminded me to share my thoughts on the role of business analysts in Scrum. But before we talk about the role, let’s first explore how business analysis activities are carried out in Scrum.
As I explained in my post “Demystifying the Product Owner Role,” the product owner takes care of the stratgeic product management aspects, such as creating the product vision and the product roadmap, but also the tactical ones, particularly grooming the product backlog. Since grooming includes decomposing and refining requirements — for instance, by capturing items as detailed user stories with acceptance criteria — it is fair to say that the product owner performs some business analysis activities. But product definition and business analysis are not restricted to one individual in Scrum: Grooming the product backlog is teamwork. Product owner, ScrumMaster and team collaborate on an ongoing basis to ensure that the product backlog contains the right items and that it is ready for the next sprint planning meeting. They jointly discover, decompose, and refine requirements. Stakeholders such as customers, users, management, service, sales and marketing are involved as appropriate, for instance, in the sprint review meeting when the product increment is demoed and discussed and when new requirements may be identified or existing ones removed from the product backlog.
Now what’s left to do for business analysts in Scrum? I have seen business analysts working as team members as well as taking on the product owner role successfully. In both cases, though, the individuals experienced a change in their daily work. Business analysts working as a team member often support their peers in product backlog grooming activities. As the business analysis activities are now carried out collaboratively, the business analysts often have time to take on other responsibilities, for instance, working with the testers or the technical writer. As a business analyst working on the team, you should hence expect to pick up new skills, broaden your expertise, and be open to work in new areas.
Business analysts working as product owners also face change. Depending on the type of product and project, they may have to acquire new skills, such as envisioning new products, managing the product roadmap, and planning the release. However, if you work as a business analyst turned product owner on a large project where you collaborate with a feature team, you may find that the change is not quite that deep. Do make sure though that you are respected and appropriately empowered. And watch out that as a business analyst, you do not morph into a proxy product owner. Be either a team member or the product owner, but not a halfway house.
So Scrum is not bad news at all for business analysts, and the individuals still have a job to do. But just like other specialized roles, working on the team means engaging in a broad range of activities and becoming what’s sometimes called a generalist-specialist.
You can find out more about business analysis activities in my book Agile Product Management with Scrum and by attending one of my Certified Scrum Product Owner (CSPO) classes. The class allows you to practice some of the agile business analysis techniques, such as progressively decomposing and refining requirements, and to discuss your specific business analysis challenges.
Agile product management has been en vogue for quite some time. But a clear definition of the term is lacking. Different people associate different meanings with it – from simply using the product backlog to extending Scrum by employing complex new frameworks. I view agile product management as fundamentally different from traditional approaches. To better understand the differences, let’s see how agile and old-school product management compare. The following table – taken from my book Agile Product Management with Scrum – summarizes five key changes.
| Old School | New School |
| Several roles, such as product marketer, product manager, and project manager, share the responsibility for bringing the product to life. | One person—the product owner—is in charge of the product and leads the project. |
| Product managers are detached from the development teams, separated by process, department, and facility boundaries. | The product owner is a member of the Scrum team and works closely with the ScrumMaster and team on an ongoing basis. |
| Extensive market research, product planning, and business analysis are carried out up front. | Minimum up-front work is expended to create a vision that describes what the product will roughly look like and do. |
| Up-front product discovery and definition: requirements are detailed and frozen early on. | Product discovery is an ongoing process; requirements emerge. There is no definition phase and no market or product requirements specification. The product backlog evolves based on customer and user feedback. |
| Customer feedback is received late, in market testing and after product launch. | Early and frequent releases together with sprint review meetings generate valuable customer and user feedback that helps create a product customers love. |
Agile methods embrace an age-old truth: They see change as the only constant. If flux and unpredictability are dominant forces, then our ability to accurately forecast markets and predict customer behavior is limited. Instead of employing a primarily analytical approach with big upfront market research and business analysis and detailed, frozen requirements, agile product management follows an empirical approach: Gathering customer and user feedback on prototypes and early product increments facilitates inspecting the work results and adapting the product accordingly. The product evolves based on customer and user feedback. This not only saves time and money but it increases the likelihood of developing a great product.
Being able to envision what a new product or the next product version should look like and do is essential for getting there. Traditionally, organizations tend to carry out extensive market research, product planning, and business analysis activities up front resulting in a product concept or a market requirements specification. Some fall into the other extreme: They rush into the first sprint without having thought about the product’s customers and users and its value proposition.
Neither of these two approaches is desirable. The first one ignores the likelihood of change. It assumes that customer needs and how they are best met can be correctly predicted upfront rather than viewing flux and unpredictability as dominant factors in software development. The latter leaves the team without a common goal making it virtually impossible to understand what it takes to develop a successful product. Since envisioning the product results in a product vision in Scrum, looking at the product vision will help us understand what visioning should comprise in an agile context.
As its names suggests, the vision describes what we believe the future product will roughly look like and do — a sketch of the future product, as I put it in my book Agile Product Management with Scrum. The vision should act the overarching goal, galvanizing and guiding everyone involved in the development effort, and is the product’s reason for being. It selectively describes the product at a coarse-grained level, capturing the product’s essence—the information considered critical to develop and launch a winning product. An effective vision should answer the following questions:
How much effort is necessary to answer the questions above depends on a number of factors including the degree innovation and the complexity of your product. As the product matures, the visioning work tends to decline. (After the successful launch of a product, I usually employ the product roadmap to capture the goals for the upcoming product versions.)
To minimize the visioning work, focus your vision on the next product version, and envision a product with minimum functionality that addresses a narrow set of customer needs. Quickly release a first product increment, or demo it to customers and users to validate the vision. Listen to the responses to see if you are shooting for the right goal. Then adapt.
You can find more information on creating a product vision in my book Agile Product Management with Scrum. The book has a whole chapter dedicated to product planning and discovery in Scrum.
Like a garden growing wild when left unattended for too long, the product backlog becomes unwieldy when it’s neglected. The backlog needs regular attention and care; it needs to be carefully managed, or groomed. Grooming the product backlog is an ongoing process that ensures that the product backlog is DEEP. It comprises the steps listed below. These are not necessarily carried out in the order stated.
Although the product owner is responsible for making sure that the product backlog is in good shape, grooming is teamwork in Scrum. Items are discovered and described, prioritized, decomposed, and refined by the entire Scrum team – Scrum allocates up to 10% of the team’s availability for grooming activities. Don’t forget to involve stakeholders including customers, users, marketing, service and sales as appropriate.
Grooming the product backlog collaboratively creates a dialogue within the Scrum team and between the team and the stakeholders. It removes the divide between “the business” and “the techies.” It eliminates wasteful handoffs, and avoids miscommunication and misalignment. Requirements are no longer handed off to the team; the team members co-author them. This increases the clarity of the requirements, leverages the Scrum team’s collective knowledge and creativity, and creates buy-in and joint ownership.
When do the grooming activities take place? Some teams like to do a bit of grooming after their Daily Scrum. Others prefer weekly grooming sessions or a longer grooming workshop toward the end of the sprint. Grooming activities also take place in the sprint review meeting when the Scrum team and the stakeholders discuss the way forward; new backlog items are identified and old ones are removed.
Make sure you establish a grooming process so that the activities are carried out reliably, for instance, by starting with weekly grooming workshops. A well-groomed backlog is a prerequisite for a successful sprint planning meeting. The backlog now contains the right items and its high-priority items are ready for consumption in the upcoming sprint.
Find out more about product backlog grooming in my book Agile Product Management with Scrum: Creating Products that Customers Love, or attend one of my product backlog grooming workshops.
Imagine your boss tells you: “Congratulations, we’d like you to take on the product owner role for our important new-product development project! And we’ve done some upfront work for you: Here is the initial product backlog.” You thank her and take the memory stick she hands you, and then walk back to your desk, where you put the stick into your laptop. After opening the product backlog, you discover that it contains 1800 detailed items. “Wow, what a product backlog,” you think and, “where should I start?”
This little story illustrates an interesting conflict: The product backlog is intended as a beautifully simple tool. But real-world product backlogs are often too long and detailed, and therefore difficult to use. The solution is to ensure that your product backlog is DEEP: It should be detailed appropriately, estimated, emergent, and prioritized. I find that particularly the first and the third property are often overlooked. I owe the acronym to Mike Cohn by the way. Mike uses it in his latest book Succeeding with Agile and he has also blogged about it. Let’s now explore the four qualities in more detail.
Detailed Appropriately
The product backlog items are detailed appropriately, as illustrated in the figure below. Higher-priority items are described in more detail than lower-priority ones. “The lower the priority, the less detail, until you can barely make out the backlog item,” write Ken Schwaber and Mike Beedle in their book Agile Software Development with Scrum. Following this guideline keeps the backlog concise and ensures that the items likely to be implemented in the next sprint are ready. As a consequence, requirements are discovered, decomposed, and refined throughout the entire project.
Product backlog prioritization determines the level of detail.
Estimated
The product backlog items are estimated. The estimates are coarse-grained and often expressed in story points or ideal days. Knowing the size of the items helps prioritize them and plan the release.
Emergent
The product backlog has an organic quality. It evolves, and its contents change frequently. New items emerge based on customer and user feedback, and they are added to the product backlog. Existing items are modified, reprioritized, refined, or removed on an ongoing basis.
Prioritized
All items in the product backlog are prioritized. The most important and highest-priority items are implemented first. They can be found at the top of the product backlog, as illustrated in the figure above. Once an item is done, it is removed from the product backlog.
Groom it, Baby!
To ensure that the product backlog is DEEP, we have to regularly groom it. Grooming the product backlog is an ongoing, collaborative process that involves the product owner, ScrumMaster, and team as well as stakeholders. My next post will explore grooming the product backlog in more detail.
To conclude the story from the beginning of this post, my preferred course of action as the designated product owner is to explain to the boss that the product backlog is too detailed and long, which makes it difficult to evolve it based on customer and user feedback. This in turn reduces the likelihood of delivering a successful product. The product backlog resembles a disguised requirements specifications, which is a common trap to fall into. My suggestion is use the product vision to derive a new product backlog that fulfils the DEEP criteria and to discard the old one — even if that’s not necessarily what the boss wants to hear.
Read on
If you enjoyed reading this post, you will love my book Agile Product Management with Scrum: Creating Products that Customers Love. The book provides a whole chapter on working with the product backlog effectively.
Applying the product owner role can be challenging. The role is multi-faceted, has a wide range of responsibilities, and its application is context-sensitive: It varies depending on the type of product, the product lifecycle stage, and the project size, the domain knowledge of the team amongst other factors. It’s not surprising that the path to effective product ownership is littered with pitfalls and traps. This post will help you recognise and avoid some of the most common product owner challenges.
A project with an underpowered product owner is much like a car with an underpowered engine: The car runs, but it struggles when the going gets tough. An underpowered product owner lacks authority. There may be several causes: The product owner does not have enough management attention; the sponsorship comes from the wrong level or the wrong person; management does not fully trust the product owner or finds it difficult to delegate decision-making authority. As a consequence, the product owner struggles to do an effective job, for instance, to align the Scrum team, stakeholders, and customers or to exclude requirements from the release.
Underpowered Product Owner
Being overworked is not just unhealthy and unsustainable on a personal level; overworked product owners quickly become bottlenecks and limit the project’s progress. Symptoms of an overworked product owner include neglecting product backlog grooming, missing sprint planning or review meetings, and not being available for questions. There are two main causes of product owner overburden: not enough time to perform the role and not enough support from the team. Availability tends to be an issue when the product owner role is just one of many jobs competing for time and attention or when the product owner looks after too many products or teams. Not enough support from the team is rooted in a wrong understanding of product ownership: Even though there is one product owner, most of the product owner work is performed collaboratively. The team and ScrumMaster must support the product owner. Scrum allocates up to 10% of the team’s availability in the sprint to work with the product owner, for instance, to decompose and refine product backlog items together.
Some organizations split the product owner role and distribute its duties across several people, for instance, by employing a product manager and a “product owner.” The product manager takes care of the product marketing and strategic product management aspects, owns the vision, is outward-facing, and keeps in touch with the market. The “product owner” is inward-facing, drives the sprints, and works with the team. In these cases, the so-called product owner is little more than a product backlog item writer. This approach reinforces old barriers, blurs responsibility and authority, and causes handoffs, delays, and other waste.
Partial Product Owner
A distant product owner works separately from the team. This can range form working on the same site in different rooms to product owner and team being separated across continents and time zones. I have found recurring issues with distant product owners, including mistrust, miscommunication, misalignment, and slow progress. There is a reason: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation,” as the Agile Manifesto for Software Development states. You should hence aim to colocate product owner, ScrumMaster and team. This can give you a significant productivity and morale increase. If colocation is not an option, the product owner should spend as much time as possible in the same room as the rest of the Scrum team. Remote product owners should be on-site at least for the sprint planning, the review, and the retrospective meetings.
Diatant Product Owner
A proxy product owner is a person acting as a placeholder for the actual product owner. I have found proxy product owners used to compensate for overworked, partial, and distant product owners. For instance, a business analyst who does most of the product backlog grooming work and answers questions from the team on a daily basis is a proxy for the actual product owner who decides the product backlog prioritization and accepts or rejects work results at the en of the sprint. Using a proxy product owner is an attempt to superficially treat a systemic issue. Rather than employing a quick fix, you should address the underlying issues.
Proxy Product Owner
A product owner committee is a group of product owners without anyone in charge of the overall product. There is no one person guiding the group, helping to create a common goal, and facilitating decision making. A product owner committee is in danger of getting caught in endless meetings with conflicting interests and politics—something also referred to as “death by committee.” Always ensure that there is one person in charge of the product, a chief product owner who guides the other product owners and facilitates decision making, including product backlog prioritization and release planning as my post “Scaling the Product Owner” explains.
Product Owner Committee
If you enjoyed reading this post, you will love my book Agile Product Management with Scrum: Creating Products that Customers Love. The book discusses common product owner mistakes in more detail and provides advice on how to rectify them.
A simple product owner hierarchy
A complex product owner hierarchy
The Product Owner plans, composes, distributes, and tracks work from his or her level down…. The higher the level is, the harder the Product Owner’s … job is. The responsibility of Product-level jobs usually requires someone with Vice President-level or Director-level title and authority.
The product owner role in Scrum has attracted plenty of interest and controversy. Some people believe it rebrands the traditional product manager. Others think it is a team lead or Scrum’s take on the project manager role. And some say the product owner is a helper role, a product backlog item writer so to speak. None of theses views is true. But each has some truth in it.
Let’s have a look at what Ken Schwaber, the co-founder of Scrum, writes about the product owner in the Scrum Guide: “The Product Owner is the one and only person responsible for managing the Product Backlog and ensuring the value of the work the team performs. This person maintains the Product Backlog and ensures that it is visible to everyone.” (May 2009 edition, p. 5) This definition sounds rather harmless until we consider its implications. It requires the product owner to lead product discovery, to help identify and describe requirements, and to ensure that the product backlog is ready for the next sprint planning meeting. It also means that the product owner has to engage in product planning, visioning and product road mapping, decides what goes into a release, carries out release planning, provides feedback to the team and reviews work results, and manages customers, users and other stakeholders. And Ken Schwaber recommends in his book Agile Project Management with Scrum: “The Product Owner’s focus is on return on investment (ROI).” (2004, p. 18) If we take this advice seriously, then product owners will have to look after products over an extended period of time – at least until ROI can be determined – if not after the product’s entire lifecycle. Having one person in charge from bringing a new product to life to discontinuing the product also creates continuity and eliminates wasteful handoffs.
The different responsibilities make the product owner a challenging and multi-faceted role that shares some of the responsibilities traditionally attributed to a product marketer, product manager and project manager. But make no mistake: As tempting as it may be to compare the product owner to traditional roles, it’s fundamentally flawed. The product owner is a new role that cuts across existing job and department boundaries. The specific shape of the role is context-sensitive: It depends on the nature of the product, the stage of the product lifecycle, and the size of the project, among other factors. For example, the product owner responsible for a new product consisting of software, hardware, and mechanics will need different competencies than someone who is leading the effort to enhance a web application. Similarly, a product owner working with a large Scrum project will require different skills than one collaborating with only one or two teams.
Who should play the product owner role? For commercial products, the product owner is typically a customer representative, such as a product manager or marketer. An actual customer tends to assume the role when the product is being developed for a specific organization, for instance, an external client who requires a new data warehouse solution or an internal client (e.g., the marketing department) asking for a web site update. I have worked with customers, users, business line managers, product managers, project managers, business analysts, and architects who filled the product owner role well in the given circumstances. Even CEOs can make great product owners.
Being the product owner is no solo act. The product owner is part of the Scrum team and closely collaborates with its other members. While the ScrumMaster and team support the product owner by jointly grooming the product backlog, the product owner is responsible for making sure that the necessary work is carried out. The product owner needs the support from the other Scrum team members. Otherwise, the individual will end up being overworked and will miss out on the knowledge, creativity, and experience of ScrumMaster and team.
Find out more about the product owner role in my upcoming book Agile Product Management with Scrum: Creating Products Customers Love. The book is accessible online at Safari Online Books. The print version is due to be out in March.
RSS