Is Product Management Agile?

There’s a lot of talk about Agile Product Management these days, and for obvious reasons. The thinking is that because of Agile development, Product Managers need to change how they function and adapt themselves to a new way of developing software and become “agile”.

But the reality is, Product Managers have always been agile, and finally the software developers are coming around to OUR way of thinking!

Yes, you read that right. Agile is the result of engineers finally understanding what’s really important and making a bold declaration that they now understand. But of course, being engineers, they won’t give credit to Product Management. They’re taking all the credit themselves for this tremendous insight and seachange in their profession. 🙂

Don’t believe me? I’ll prove that Product Management has always been “agile” using the Agile Manifesto itself.

The Manifesto has 4 elements. They are:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

OK. Let’s take one at a time and apply them to Product Management.

Individuals and interactions over processes and tools

Most product management teams are understaffed. In fact, in many companies you’ll only find individual product managers working alone with teams of developers. They have no choice but to interact face-to-face. And not just with Development, but with every other group in the company and many parties outside of the company.

“Hub of the wheel”? You know what that translates to in the real world? Meetings, and lots of them, with the primary objective to keep all teams aligned and aware of progress, status and plans. Those cross-team meetings aren’t for the benefit of Product Management!

As for processes and tools…well, most PMs will tell you they do what it takes to get the job done, and the only tools they have are usually email, Excel, PowerPoint and Word, possibly some crappy (free) wiki software and Post-it notes. No fancy (or even basic) requirements management tools for most Product Managers. Individuals and interactions: Yes. Processes and tools: Not much. Score: 1 for 1.

Working software over comprehensive documentation

What PM doesn’t want working software? If only the final product that came out of Dev and QA was guaranteed to always work as expected. PMs want working software so much they perform QA, file bugs, run beta programs and hound the testing teams to ensure all the important use cases actually work.

How many times have we taken a pre-release build and found that it doesn’t install properly, or fails when upgrading from a previous version, or has licensing problems or runs really slowly using real world data sets. Ensuring working software gets out the door is top of mind for every PM, and even though helping QA the product is not technically part of our job, many of us do it anyway to raise the probability of actually delivering working software.

Regarding comprehensive documentation, we don’t tell Dev teams to create 50 page spec documents. They choose to write them and then PMs are forced to sit through endless “spec review” meetings to ensure Dev has taken the requirements and translated them properly into something THEY understand.

As for creating comprehensive documentation, PMs can never be accused of that. What’s the most common complaint from Engineering about Product Management? Answer: “The requirements aren’t detailed enough.” ‘Nuff said. Score: 2 for 2.

Customer collaboration over contract negotiation

Too easy. Really, do I have to explain this one? OK, I will. “Product Management: Voice of the Customer”. How often have you heard that phrase? Meaningful phrase or not, Product Management focuses extensively on customer insight and collaboration. It’s another core aspect of the job.

But, there are countless true stories of Engineering VPs who exhibited disdain for what customers actually want or need. These people are so smart they know what customers need, with little if any input from the customers themselves. Case in point.

A survey of 500 customers showed clear priorities for a number of big ticket items that needed to be added to a product. Capability <A> was ranked #15 by customers but was a pet project of the VP Eng. Capability <B> was ranked #2 by customers. We only had the resources to do one of those 2 items, along with everything else that was planned.

PM: We’ve laid out the requirements in priority order. < B> is critical for the next release and given the target release date, resources and survey results, we’ve deprioritized <A>.
VP: Hold it a minute. Are you saying that <A>  is not important?
PM: Well, it’s not as important as <B> and the other things we’ve prioritized for this release.
VP: I was talking to MegaBankCorp last week, and they really emphasized the need for <A>.
PM: Yes, I spoke to them too. But they’re one of only 3 companies who have indicated they have an urgent need for <A>. I’ve got 50 companies that need <B>. <B> is more important than <A>.
VP: I don’t think you’re talking to the right people. I hear people asking for <A> all the time. Our major competitor has <A>, and we’ve lost deals to them.
PM: We’ve lost 1 deal to them on <A>, The sales team agrees that <B> is much higher priority than <A>, and the 500 hundred customers I surveyed agree as well.
VP: Don’t you realize <A> is strategic? Don’t you even read the industry news? You know what the problem with Product Management is?
PM: I’m sure you’re going to tell me.
VP: You talk to too many customers! You don’t talk to enough people who don’t use our product.
PM: People who don’t use our product also don’t tell us what they want added to the product. But, if you have the resources to do both <A> and <B> in this release, then be my guest. But <B> is top priority if you can’t do both.

Result: VP storms out of the meeting. Sends and email the next day indicating that after analyzing the effort and resources, both are not possible in the coming release so only <B> can be done.

Of course, not all Dev leads and VPs are as stubborn. But when it comes to wanting to work with customers, as opposed to sitting in meetings trying to get Engineering to buy-in on what is needed, Product Managers have always advocated for that. Score: 3 for 3.

Responding to change over following a plan

Next to “The requirements aren’t detailed enough“, the most common complaint that Engineers have of Product Management is that PMs regularly “change their mind“. Most PMs don’t simply change their mind about things, but reprioritize what is important based on new data, new market conditions or other external changes that take place. That’s core to the role of Product Management. The world is a dynamic place, and when your competitor is bought out by and industry giant, or you find that you’re losing deals because of product gaps, action must be taken.

Yes, there are some flaky PMs who don’t have a clue about things, but that can’t be helped. Most capable PMs are reasonable people who need to focus on the business and leverage the engineering resources to help drive business benefit. It’s hard enough to predict what will happen 3 months from now, let alone 12 months from now.

But if a development cycle will take 12 months to complete, Product Management must be collecting the data to define that release many months in advance. Hey, we’re smart, but we’re not the Oracle of Delphi. We make decisions. Decisions are based on the information we have today. If something material happens after a decision is made that requires a change in product plans, the change must be made. Product Management always understood that. Engineering seems to be finally realizing that. Score: 4 for 4.


So there you have it. QED — quod erat demonstrandum.

Product Managers have been living, breathing and advocating the elements of the Agile Manifesto for years before the Manifesto was even a firing synapse in the brains of any of it’s authors. Developers though were set in their ways, pushing back on Product Management for changing priorities, not providing enough detail in requirements etc.

I’m glad, even if they don’t want to admit it publicly, that Engineers are finally seeing the light. Now, if we could only get Management to allocate more headcount to Product Management, life would almost be perfect.



16 responses to “Is Product Management Agile?

  1. Passionate PM

    Well said, Saeed – a very nice article, in deed.

  2. Saeed: well, ok so Product Management has agile characteristics. However, isn’t the whole comparison thing sorta like comparing apples to oranges? I might be willing to go along with you if we were talking about PROJECT MANAGEMENT; however, we’re not. Product management focuses on a lot of tasks that are not product centered – customer focus groups, interactions with sales, etc. These tasks have little or nothing to do with S/W development and yet they are a critical part of the PM job.

    Perhaps a better way of saying it is that the S/W development team needs to agile and the PM needs to be flexible.

    – Dr. Jim Anderson
    The Accidental PM Blog

  3. @saeed: I love it! Very fun.

    @Dr. Jim: I think you can take a step back and say that dev teams are responsible for implementing software solutions, and given that responsibiliity, agile teams follow the manifesto in their quest to implement. You can also say that a product manager, responsible for creating a great product, can also be agile by following the principles of the manifesto in the execution of her duties.

    In the end, I think this says that the manifesto provides good ideas, applicable to fields beyond “implementing software”

  4. @PPM

    Thanks for the compliment.


    Glad you like the article. See my comment to Jim for more detail on this. Minus the specific implementation details such as Scrum, I see Agile as a means for software development to change it’s culture and be more accomodating to real world dynamics.


    Virtually everything PMs do is product centered. Even things like helping sales people with deals is product centric. But, I do see where you are coming from.

    While the post is a tiny bit tongue in cheek, there is a serious point in it. Agile principles correct for a problem that has long existing in software development.

    In short, it was a lack of acknowledgment in software development of the dynamic nature of the real world and the fact that software development is not like other engineering disciplines.

    When thought of as a discipline like “engineering”, the engineering aspects used in the physical world are applied to the software world. When building a bridge or a house or a computer chip or something else, the analysis, planning and design that happens up front is critical. You can’t just start building a bridge for example, and then figure out the details as you go along. You model everything ahead of time, render it in 3d, build scale models, conduct material, structural and site tests, and THEN build it. Even while building it, small changes may be needed to accommodate for new information learned along the way.

    But for software, because of it’s “soft” nature, the difficulty in truly understanding the details on how it will be used, as well as the changing market needs as it is being built, that is not how it should be built. But, because it was viewed as “engineering”, then the analyze and plan practices of the physical world were adopted and used extensively.

    The reality is that given the complexities and unknowns of software, and the dynamic nature of the market, a more adaptive approach was needed. The founders of Agile understood this, and defined a very eloquent call for change within the software development community.

    Sales, Marketing, Product Management etc. all worked adaptively. Software development did not.

    While I truly welcome this change in the culture of software development, it must be acknowledged that it’s not as revolutionary as some people seem to think.


  5. Great Article.

    However, I have seen cases where the product managers wrote detailed documents explaining everything from the market analysis to the location of the cancel button. It is not uncommon to see PM’s who spec out the implementation rather than the requirement.

    One thing I think PM is supposed to do is keep the consistency and intention of the product alive. Simplest example would be consistent use of terminology across the product according to the intentions of the customers and product managers. This can not be achieved in real life without a lot of attention to details and can not be left to common sense of engineers.

    I see this is one of the weaknesses of agile. an excellent PM might help here as he monitors the frequent change still create a consistent solution and preserve its business goal.

  6. Ophirk,

    Thanks for the comment. I agree, there are PMs who go way overboard and don’t understand the difference between a requirement and a spec. But, that is not the general case. Most PMs write requirements that probably need more information or context. But even the most complete requirements will not have all the info that engineers need to convert the requirement into a spec. I think this is where some PMs make mistakes and go overboard with details.

    As for the “location of the cancel button”, as you describe it, that should be the responsibility of interface designers or interaction designers.

    I’ve worked with some good interaction design people. While technically part of engineering, they are user interface and end-user focused, and drive the look, feel, workflow etc. of the product based on direct interaction and research with users. IMHO, absolutely essential for any significant software project.


  7. Saeed,

    This was a great article. I have been reading about how gaga the industry has been with Agile and been wondering, isn’t that all common sense and don’t many “professions” follow that principle.

    Too many times people get stuck up in a particular example rather than trying to understand the “idea” behind the example.

    – Ameet

  8. Ameet,

    Thanks. Glad you liked the article. Keep in mind that the Agile Manifesto is about 7 years old, so it’s taken a while for it to take hold.


  9. Saeed, very interesting article! I talk to PMs regularly who tell me their teams have moved to Agile and are feeling like they “don’t need PM” as much now. They (the developers who “don’t need PM”) do not understand what PM brings to the table. This post is a solid resource to help them understand — in their own context — what PM can and will do for them. -Michael

  10. Michael,

    Developers who state they don’t need a PM because they’ve moved to Agile don’t understand what Product Management is, and also don’t understand what Agile is. If the Executive team agrees with the development view of PM, then the same holds true for the business. And if that is the case, I’d recommend that PMs in that situation either educate their executives real quick, or move on to a company that has a real understanding of the value of Product Management.

    That statement about Product Management is akin to Sales saying they don’t need Marketing because they have adopted a relationship selling methodology and Marketing has no value there. It’s a position based on ignorance.

    While a little tongue-in-cheek, I wrote this article to point out some obvious realities of how business works and how this move by Development to be “agile”, to adapt to change and focus on the customer, is nothing new. The rest of us, including Sales, Marketing, Product Management etc. have been preaching and living that for a long time.

    Understanding the larger business context is still a problem for Engineering. While they want to be customer centric, they also have to be aware of the business context they work in. Part of that means understanding the roles and importance other teams in the business have in the overall business success. Those teams include, of course, Product Management.


    • Saeed, you wrote in your last comment:

      “Developers who state they don’t need a PM because they’ve moved to Agile don’t understand what Product Management is, and also don’t understand what Agile is.”

      This statement is insighful and true. Realizing the full benefits of agile development – even just the most important benefits – requires that the entire product team participate in iterative development.

      But you are overstating the case when you claim that product management has always practiced agile. As with development, it is impossible for one department to practice agile in isolation. Agile product management requires that designers, developers, and testers help product managers bring demoable software to customers on an iterative basis. Bringing demoable software to customers on an iterative basis enables product managers to overcome BUFR.

      Furthermore, common practices of product management directly contradict the notion that product management has always been agile. In the comment section of the blog entry I published addressing precisely this issue, I wrote:

      “First, take the typical 50 page requirements thrown over the wall to developers. To the extent that product managers resisted creating such documents, it wasn’t because they were agile. It was because they were either lazy or didn’t want to get into design details.

      Second, I challenge you to find an example prior to the popularity of agile where the product manager pushed for frequent, regular iterations. If product managers were truly agile, you should be able to find numerous examples.”

      You never responded to this challenge.

  11. Pingback: The Cranky Product Manager never fails to disappoint, plus a blog you should read | The Cranky Product Manager

  12. Interesting take. Can’t say I’ve ever met a developer who was excited about writing 50-page spec documents. Perhaps it’s development managers who have to shoulder the blame 🙂

  13. Pingback: Adam Bullied vs. Enthiosys: Don’t Fight! « On Product Management

  14. Pingback: Agile and Product Management - Some Links | Agile Advice - Working With Agile Methods (Scrum, XP, Lean)

  15. Pingback: Happy (belated) birthday to us (again)! « On Product Management