Introduction
The problem with any formal examination of Product Management is that it is probably the least well understood of all the software project development disciplines and varies greatly in definition and implementation from one organization to another. While some organizations have made a successful business from teaching and providing guidance around Product Management practices it remains a skill difficult to pin down in its scope and responsibility.
Pragmatic Marketing is arguably the most well known of the companies offering Product Management training, perhaps not surprisingly as Product Management has been the specialty of the Arizona based business for more than two decades. Its market-driven product management framework is almost legendary amongst Product Managers, having an appearance similar to the periodic table of elements which perhaps lends it an air of authority purely by association. However, the framework merely serves to demonstrate why Product Management is so hard to pin down, which is, that it potentially includes so many activities that very few, if any, real PM jobs actually includes them all.
With each Product Management position being a variable selection of tasks often changing over time, the Product Manager herself becomes a person whose job specification is always in doubt and is frequently misunderstood by others, especially upper management. You will see this variation in job description demonstrated if you look at a series of on-line job postings for product managers. The role is so varied that in some organizations the Product Manager is responsible for product development while in others the role is not even in the product development department, let alone managing it!
And all this variability exists in Product Management of those ‘old-fashioned’ development methods in which the entire product development moves through a series of long, well defined phases with the hope that it turns out right the first time. This is, admittedly, a facetious description as I am only too familiar with the bad rap that waterfall-style projects have gained in recent years as the evangelists of the Agile family of development methods have preached long and hard, with a fair degree of success, to get Agile accepted by the software development community as ‘good’, and waterfall type developments as the curse of the dark side. In this article I shall not be weighing in on that argument, (well, not much) but merely looking at how the various forms of development known as Agile, or Agile-like have affected the role of the Product Manager for better or for worse.
Before I go any further, let me clear up the little matter of Product Management versus Project Management. Any confusion between the two is not helped by the occasional Product Manager role including responsibility for the software delivery. Product Managers should sit in the gray area between the customer and the development team and not at the head of the development team itself; the Product Manager helps to specify the product, the Project Manager delivers it. The similarity in the names of these two key roles, not to mention the identical initials, doesn’t help with any confusion (in this article, PM refers to Product Management.) If Product Managers were called ‘Solution Guides’ instead, the misunderstanding may be less common. Solution Guide is actually a pretty accurate descriptive label for many of the responsibilities that a Product Manager has, and with little authority, it is rare that a Product Manager actually gets to manage anything.
The Traditional Product Manager
So, what is the traditional role of the Product Manager? As we said earlier, the Product Manager sits in that area between the stakeholders and the development team, with one foot in the problem domain and one foot in the solution domain; a rather unique and critical position. I have often described a Product Manager as the person standing between the customer and the developers looking outwards to understand what problems need to be solved, looking inwards to ensure that right solution is developed and looking outward again to then ensure that the right message is conveyed to the customers and marketplace. That is not to say that everything goes through the Product Manager, that would create a serious bottleneck, but the Product Manager should be aware of everything that goes in either direction. To do this it is helpful for a Product Manager to use a software tool for the management of requirements where the tool is accessible by all team members in order to facilitate the necessary level of communication.
As we discuss the changes to PM it can be helpful to keep in mind eight key areas of generally accepted Product Management responsibility or involvement and see how they change under an agile project regimen. These areas are:
- Market awareness
- Strategic direction
- Business decision making
- Stakeholder representation
- Development liaison
- Marketing support
- Sales enablement, and
- Product Oversight (Preparation of all departments)
The Product Manager is Dead
If you were to accept what some experts say then you would believe that the Product Management role within Agile environments no longer exists. It has gone. The Product Manager is no more. This seems to be a rather drastic change to have occurred to Product Management; and if we believe it then we must ask, “Where have all the Product Managers gone?” Let’s see whether we can find out.
One of the difficulties all Product Managers have faced in the past is that they had much of the responsibility and none of the authority. Nobody works for the Product Manager. A Product Manager has a team of precisely one, but must somehow make sure that everyone in the organization is doing their bit to ensure things go according to plan. When things did go according to plan, it was the Project Manager and team leads that were to be congratulated, but when things went awry, the Product Manager was often seen as not having known about the problems or of failing to communicate the problems in advance. The Product Manager has been a one-stop target for blame. OK, so this is a rather negative view, but it is true that along with janitorial duties and tax collectors, PM is sometimes a rather thankless task.
While one of the practical effects of Agile processes is the short, iterative-style development cycles, it is often said that Agile is more about attitude than practicality. Agility is about teamwork. The traditional specialist roles delineated by project phases and cubical partitions have been replaced by small, tight-knit teams in which individual skills are complemented by the ability to work together and turn a hand to whatever needs doing. This team spirit also applies to responsibility. Rather than individuals carrying this weight, everyone is responsible collectively for the success or failure of the project. But shared responsibility goes further than that.
User Requirements
One of the objectives of Agile processes is to meet the needs of the customer, which also happens to be one of the primary objectives of the Product Manager, so in one sense at least, product management and Agile practices would seem to be complementary. But as we have said, there is a team approach to Agile projects and where requirements are concerned team members are encouraged to communicate directly with the stakeholders, thus bypassing the traditional Product Management role; in fact stakeholders are often included in what has been referred to as the stakeholder team. This reduces the previous individual responsibility Product Managers had for representing the stakeholders. By spreading this accountability across the team, the Product Manager, if he still exists, no longer stands alone as the sole flag bearer for the user.
Requirements Management
The primary method of representing the stakeholder in the past has been through the elicitation and management of user requirements, a common PM role. Work could not begin in earnest until the Product Manager had delivered a complete set of requirements, signed-off by the customer and often contractually binding.
But in Agile processes, the requirements remain far more fluid, only being fleshed out as and when they are needed. This provides greater opportunity to adjust to lessons learned as the project progresses and allows the stakeholder to make decisions based on what they see in regular release builds. This further removes the responsibility from the Product Manager as requirements development becomes a collaborative affair achieved piecemeal rather than en masse, using collaborative software support tools.
This change in requirements management and the move away from product management ownership of the user requirements is sometimes difficult for those in product management roles to adjust to - it can feel as though the job is less important and seriously diminished - but once they get used to it, there is an almost audible sigh of relief as the burden of singular accountability is lifted from their shoulders.
The Product Management role then, is seemingly being eroded by the employment of Agile methods and practices. In fact, there are some who promote the use of the term Product Owner as the role that manages user requirements and discourage the use of the term Product Manager entirely, thus completing our previously asserted demise of the Product Manager! It must be stressed that the Product Owner is NOT a replacement for the Product Manager; there is overlap in job descriptions, but their overall drive is different.
So far we have seen how the role of Product Management in Agile projects has not so much changed, but shrunk, and now seemingly disappeared completely with the rise of the new position of Product Owner.
The Product Owner
The Scrum Alliance provides teachings to those they call, ‘Certified Scrum Product Owners.®’ To quote from the Scrum Alliance web site, CSPO’s “have been taught the Scrum terminology, practices, and principles that enable them to fulfill the role of Product Owner on a Scrum team. CSPOs are typically the individuals who are closest to the "business side" of the project.” It goes on to say, “CSPOs maintain the product backlog and ensure that everyone knows the priorities.”
We can see from these two statements that a CSPO is supposed to fulfill many of the duties previously claimed by the Product Manager, but without that title. At least it is clear, even to Agile advocates, that someone needs to understand the market, prioritize the requirements and act on behalf of the stakeholder when the stakeholder is unavailable, but that someone is now the Product Owner. However, typical PM tasks missing from the role include strategy decisions, marketing and sales support as well the preparation and liaison of all organization departments, which is why this new position is not a replacement for PM.
To add confusion, the Scrum Alliance also states that CSPOs are, “charged by the organization to "get the product out" and are expected to do the best possible job of satisfying all the stakeholders.” Here we now have some of the traditional Project Management activities rolled into the Product Owner, which is itself a subset of the Product Manager responsibilities, therefore exacerbating the confusion we discussed earlier between a Product Manager and a Project Manager. One might be forgiven for concluding that the Product Owner combines the previous roles of Product Manager and Project Manager. Fortunately, as we shall see, this is not the case.
Figure 1: Product Owner as King?
As an aside, it is interesting to note that the book, “Agile Product Management with Scrum: Creating Products that Customers Love” by Roman Pichler, while being full of useful information, does not talk about Product Management at all, but is about Product Owners. Such contradictions cannot help practitioners new to these concepts.
So, we now know that the Product Owner replaces part of the Product Manager role and part of the Project Manager role, but this brings us no closer to understanding what, if anything, has happened to the Product Manager himself.
User Stories and Beyond
Having broached the subject of requirements management, let us take a moment to look at another way in which Agile processes advance the change of RM and therefore, potentially the PM role.
Along with the change in requirements management practices comes the change in requirements representation. Agile concepts encourage the creation of user stories and use cases. These are not just different ways of organizing the same information, they are different concepts that deliver different ways of seeing the same problem. It is not sufficient to simply rewrite ‘shall’ statements as use cases; the essence of the user story would not be captured.
Agile concepts also encourage the graphical representations of the problem space through the representation of interactions between the various players, or actors, in the system. However, there are disadvantages to visual requirements when it comes to traceability: it is much more difficult to refer to an area or element within a diagram than it is to refer to a textual statement or a single element in a table. For example, ensuring that graphical requirements have full test coverage can be quite a challenge.
A combination of text and pictures is often a good compromise, so when considering a software test management or requirements management tool, look for one that supports both pictures and text and that provides specific support for text organized as user stories or use cases.
Let us now return to the Product Owner and how that role seems to be at variance with that of the Product Manager.
Project Management
As we have seen, most definitions of Product Owner include some level of responsibility for software delivery. This is important because it means that the role of Project Manager no longer exists in Agile projects in the way it did in more traditional development methods. There is a danger here in a potential conflict of interest. The task of ensuring that the stakeholders get what they want is a push-and-pull hustle with the task of getting the software delivered on time, because despite the change in the planning and scheduling methods in Agile development, there are still delivery deadlines. With one person trying to do both, there can be the temptation to compromise on requirements in order to make the development organization happy by achieving an on-time delivery.
It is true that Agile approaches require stakeholders as part of the team which can help mitigate this risk, but ultimately the stakeholder is an outsider and company demands are likely to prevail. Also, that safety valve does not exist when a generally available, commercial product is being developed that has no individual target customer. Another way to manage this conflict is to continue to have some form of Product Manager as a separate role, who can be involved in overall product delivery decisions, (which we shall see later is not the same as software delivery.)
Another way to mitigate this risk is to give the balance of the responsibility for delivery to a different role. This can be a Delivery Manager, Development Manager or in Scrum terms, the Scrum Master. However, the Scrum Master’s primary responsibility is to ensure that Scrum principles are being followed and in that sense the role is one of process management not project management. But it can go further by ensuring that the flow of requirements from the Product Owner is smooth and manageable, and in that sense, the role can help balance the user needs and the development needs. A Delivery Manager is a little more flexible having the job of planning and executing the process for delivery of the software, which can be seen as a rather narrowly focused Project Manager or perhaps a powerful team leader.
So, with the need to have further oversight of product deliverables, perhaps the demise of the Product Manager is not quite so decisive.
The Product versus the Software
To gain further insight into the difference between a Product Manager and a Product Owner, we should consider the difference between the software and the product, which are not actually the same. Even for products that contain no hardware element, the software is not the only deliverable. There may be user guides or other documentation, there may be packaging for physically delivered product or web page hosting and delivery for those that are not. Training and support options as well as warranties, installation processes and help desk protocols can all be seen as part of the ‘product’. Without them there is no delivery. Without them, a company cannot see a revenue return for the investment. With the software as only one component of the product, there is the need for someone to provide overall product oversight and this is the job of the Product Manager.
This distinction between product and software can also be seen if we consider the reason why the Project Manager and the Product Manager are so called: the Project Manager supervises the software project delivery whereas the Product Manager oversees the entire product delivery. We can now see why organizations running Agile projects still require a Product Manager, although they may not say so: Agile processes address only the software element of a product and say nothing about how all the other aspects of Product delivery such as training, documentation, etc. should be managed. Because of this difference between the software and the product, the Agile role of Product Owner would be better called the Software Owner, but let’s not try to change accepted naming conventions, no matter how misguided they are.
So, by considering the entire organization and not just the software development, we can see that the Product Manager is alive and well. It is worth stressing that because the software is still the most vital part of the product, good communication and collaboration between the Product Manager and Product Owner is critical.
Stakeholder Feedback and the Business
Customers don’t know what they want. While this might not be strictly true, it has an element of reality about it. Customers think they know what they want but it is far easier to articulate what is wrong with something that already exists than to create an idea of something that is not yet real. It is often the case that in requirements elicitation meetings, the primary role of the facilitator is to turn the participants away from a long list of what is wrong with the existing system and to focus on needs instead of complaints. Rather than battling this demonstration of human nature, we can use it to our advantage with prototypes. By showing the stakeholder one idea, (hopefully as close to the actual need as possible) they can tell us everything that is wrong with it. Perhaps this is a cynical way to express the process, but the practice is very effective.
With the stakeholders as part of the team, it is easier to get that rapid feedback on a prototype or even an interim release, feedback which can then be used to make changes and to develop further the requirements in the backlog, (in Scrum terms.) This again highlights the difference between a Product Owner and a Product Manager. Where the latter is looking at the broad picture of the market needs and corporate goals, the Product Owner has a more narrow focus on stakeholder needs and how to meet them. The Product Owner is closely integrated with the prototype or release review, the Product Manager is usually not. This can help us gain back some of the status Product Managers may feel they have lost. Not only do Product Managers have a wider role to play in the context of deliverables than just the software, they also have a more global view of the business by understanding the market in which the organization operates and guiding longer term strategic decisions which will affect development and hence the Product Owner.
Other Product Management Activities
So far we have focused mostly on software development activities and the part played by the stakeholders, the Product Manager, the Product Owner and the Delivery Manager. Also, we have seen that Agile practices apply to the software development process and not to the rest of the organization. Consequently, the other Product Management activities we listed at the beginning, such as strategy, marketing support and sales enablement, remain largely the same regardless of development method.
What is required where these disciplines are concerned is an understanding of the potential impact Agile software development has on these areas. For example, roadmaps tend to have greater fluidity. The priority of the pending requirements (backlog) can change without warning which can have a potential impact on things like sales enablement and promotional materials. On the other hand, frequent iterations with intermediate releases can provide material for marketing activities and key customer updates, so there are both pros and cons in Agile development for the Product Manager.
The Product Manager is Alive and Well
In conclusion we see that indeed, Product Managers do not exist in Agile-oriented projects, but not because the role is dead, but because the role operates outside the realm of the software project. Product Management exists within Agile-oriented organizations, but it is an organizational level activity with responsibilities, decision making and influences far beyond the scope of the software itself. By relieving the Product Manager of some of the details of day-to-day software requirements management, the long list of responsibilities we discussed at the start, is reduced to a manageable size, giving the Product Manager a better chance to do each of the remaining tasks well.
There is merit to this delineation, such that even organizations using traditional waterfall software development processes would do well to consider adding a Solution Guide to their org. chart to complement the Product Manager and Project Manager roles. And if this title seems too diminutive, just change it. How about ‘Software Solution Manager’?
Figure 2: Changing Roles
Without the Product Manager in Agile-oriented organizations, neither the Product Owner nor the Delivery Manager can do their job as the business context for the software solution is lost. The triangle of these three roles is a strong organizational structure which should help to inspire mutual confidence and reassurance as well as offer assurance to the organization as a whole that they have all their bases well and truly covered.
The Product Manager is alive and well and living in the corporate world, not the project environment.