first wrote<\/a> this piece. It was intended as a counterpoint to all the agilists that were decrying how Product Management wasn\u2019t \u201cagile\u201d (or \u201cAgile\u201d). I found (and still find) the whole argument somewhat baseless, but it still persists amongst agilists (look at this example of what \u201cProduct Owner\u201d is turning into), and unfortunately, even within the Product Management community.<\/p>\nThose who talk about \u201cAgile Product Management\u201d as some unique form of Product Management are not doing anyone a service. \u201cAgile Product Management\u201d? As opposed to what? \u201cSluggish Product Management\u201d?<\/p>\n
Just because the technologists have latched onto something that seems to be having benefits for them \u2014 and believe me, the bar was set pretty low for many of them \u2014 that doesn\u2019t mean Product Management needs to latch onto that as well. Yeah, that\u2019s what we always preach\u2013 see something and create a \u201cme-too\u201d solution. Right?<\/p>\n
Product management, like business management, is dynamic, open to change, should focus on people etc. Those companies that are static, put process ahead of progress etc. quickly die off.<\/p>\n
So, here\u2019s the original piece from October 2008. It was originally titled \u201cIs Product Management Agile?\u201d but I decided the new title was a better fit for the reprise.<\/p>\n
\u2014\u2014\u2014\u2014<\/p>\n
There\u2019s 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 \u201cagile\u201d.<\/p>\n
But the reality is, Product Managers have always been agile, and finally the software developers are coming around to OUR way of thinking!<\/p>\n
Yes, you read that right. Agile is the result of engineers finally understanding what\u2019s really important and making a bold declaration that they now understand. But of course, being engineers, they won\u2019t give credit to Product Management. They\u2019re taking all the credit themselves for this tremendous insight and seachange in their profession.<\/p>\n
Don\u2019t believe me? I\u2019ll prove that Product Management has always been \u201cagile\u201d using the Agile Manifesto itself.<\/p>\n
The Manifesto has 4 elements. They are:<\/p>\n
Individuals and interactions over processes and tools
\nWorking software over comprehensive documentation
\nCustomer collaboration over contract negotiation
\nResponding to change over following a plan
\nOK. Let\u2019s take one at a time and apply them to Product Management.<\/p>\n
Individuals and interactions over processes and tools
\nMost product management teams are understaffed. In fact, in many companies you\u2019ll 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.<\/p>\n
\u201cHub of the wheel\u201d? 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\u2019t for the benefit of Product Management!<\/p>\n
As for processes and tools\u2026well, 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!<\/p>\n
Working software over comprehensive documentation
\nWhat PM doesn\u2019t 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.<\/p>\n
How many times have we taken a pre-release build and found that it doesn\u2019t 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.<\/p>\n
Regarding comprehensive documentation, we don\u2019t tell Dev teams to create 50 page spec documents. They choose to write them and then PMs are forced to sit through endless \u201cspec review\u201d meetings to ensure Dev has taken the requirements and translated them properly into something THEY understand.<\/p>\n
As for creating comprehensive documentation, PMs can never be accused of that. What\u2019s the most common complaint from Engineering about Product Management? Answer: \u201cThe requirements aren\u2019t detailed enough.\u201d \u2018Nuff said. Score: 2 for 2!<\/p>\n
Customer collaboration over contract negotiation
\nToo easy. Really, do I have to explain this one? OK, I will. \u201cProduct Management: Voice of the Customer\u201d. How often have you heard that phrase? Meaningful phrase or not, Product Management focuses extensively on customer insight and collaboration. It\u2019s another core aspect of the job.<\/p>\n
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.<\/p>\n
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.<\/p>\n
PM: We\u2019ve 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\u2019ve deprioritized (A).
\nVP: Hold it a minute. Are you saying that (A) is not important?
\nPM: Well, it\u2019s not as important as (B) and the other things we\u2019ve prioritized for this release.
\nVP: I was talking to MegaBankCorp last week, and they really emphasized the need for (A).
\nPM: Yes, I spoke to them too. But they\u2019re one of only 3 companies who have indicated they have an urgent need for (A). I\u2019ve got 50 companies that need (B). (B) is more important than (A).
\nVP: I don\u2019t think you\u2019re talking to the right people. I hear people asking for (A) all the time. Our major competitor has (A), and we\u2019ve lost deals to them.
\nPM: We\u2019ve 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.
\nVP: Don\u2019t you realize (A) is strategic? Don\u2019t you even read the industry news? You know what the problem with Product Management is?
\nPM: I\u2019m sure you\u2019re going to tell me.
\nVP: You talk to too many customers! You don\u2019t talk to enough people who don\u2019t use our product.
\nPM: People who don\u2019t use our product also don\u2019t 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\u2019t do both.<\/p>\n
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 can be done.<\/strong><\/p>\nOf 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!<\/p>\n
Responding to change over following a plan
\nNext to \u201cThe requirements aren\u2019t detailed enough\u201c, the most common complaint that Engineers have of Product Management is that PMs regularly \u201cchange their mind\u201c. Most PMs don\u2019t simply change their mind about things, but reprioritize what is important based on new data, new market conditions, new company objectives, or other external changes that take place. That\u2019s 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\u2019re losing deals because of product gaps, action must be taken.<\/p>\n
Yes, there are some flaky PMs who don\u2019t have a clue about things, but that can\u2019t 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\u2019s hard enough to predict what will happen 3 months from now, let alone 12 months from now.<\/p>\n
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\u2019re smart, but we\u2019re 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!<\/p>\n
Conclusion
\nSo there you have it. QED \u2014 quod erat demonstrandum.<\/p>\n
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\u2019s authors. Developers though were set in their ways, with an \u201cengineering\u201d mindset, pushing back on Product Management for changing priorities, not providing enough detail in requirements etc.<\/p>\n
I\u2019m glad, even if they don\u2019t 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.<\/p>\n
Saeed<\/p>\n
<\/p>\n
Stolen from :\u00a0http:\/\/onproductmanagement.net\/2012\/03\/13\/worth-repeating-product-management-has-always-been-agile\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"By Saeed Khan I can\u2019t believe it\u2019s been over 3 year since I first wrote this piece. It was intended as a counterpoint to all the agilists that were decrying how Product Management wasn\u2019t \u201cagile\u201d (or \u201cAgile\u201d). I found (and still find) the whole argument somewhat baseless, but it still persists amongst agilists (look at…<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1110","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"jetpack_featured_media_url":"","jetpack-related-posts":[],"jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/more-coffee.co.uk\/index.php?rest_route=\/wp\/v2\/posts\/1110","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/more-coffee.co.uk\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/more-coffee.co.uk\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/more-coffee.co.uk\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/more-coffee.co.uk\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1110"}],"version-history":[{"count":0,"href":"https:\/\/more-coffee.co.uk\/index.php?rest_route=\/wp\/v2\/posts\/1110\/revisions"}],"wp:attachment":[{"href":"https:\/\/more-coffee.co.uk\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1110"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/more-coffee.co.uk\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1110"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/more-coffee.co.uk\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1110"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}