Is Product Management Agile?
Product Managers have always been agile! It’s true. Don’t believe me?
I’ll prove it to you by 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.
Let’s take these elements 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.
As for processes and tools ... well, most PMs will tell you they do what it takes to get the job done, and don’t impose processes on anyone. And the only tools they typically have are email, Excel, PowerPoint and Word, and possibly a wiki or some other basic tools. No fancy 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 Development and QA was guaranteed to always work as expected. Product Managers 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 Product Manager. And even though helping QA the product is not technically part of the job, many Product Managers do it anyway to raise the probability of actually delivering working software.
Regarding comprehensive documentation: Product Managers never told Development teams to create long specification documents. That was just the way they operated in a waterfall environment. Don’t get me wrong; there’s value in proper investigation and design. It’s a critical part of building any complex software product. But, what ended up happening was Product Managers were required to sit through long and tedious “spec review” meetings to ensure Development had taken the requirements and translated them properly into something THEY understood.
As for creating comprehensive documentation, Product Managers can never be accused of that. What’s the most common complaint from Engineering about Product Management? Answer: “The requirements aren’t detailed enough.” :-) I’m sure every Product Manager has heard that at least once or twice.
Score: 2 for 2.
Customer collaboration over contract negotiation
Product Management is often called: “Voice of the Customer." How often have you heard that phrase? Product Management focuses extensively on gaining customer insight by interacting with them.
Product Managers visit customers, talk to them, and try to understand what makes them tick. They use surveys and other tools to collect information. Product Managers involve customers in the development process via milestone reviews and beta programs. It’s a core aspect of the job.
But, this is not always the case with Engineering. There are countless true stories of Engineering VPs (for example) who’ve exhibited disdain for what customers actually want or need. I’m not labeling all VPs the same, but I would be remiss if I didn’t raise this as an issue Product Managers face regularly.
The following is a true story of one such incident. I’ve paraphrased the dialogue a little for brevity, but otherwise, it is factually correct.
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 an 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 Development leads and VPs are that stubborn. But when it comes to wanting to work with customers, versus sitting in meetings trying to get Engineering to buy-in on what is needed, Product Managers have always advocated for the former.
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 Product Managers regularly “change their mind."
Most Product Managers don’t arbitrarily change their minds about things, but reprioritize what is important based on new data, new corporate objectives, 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 an industry giant, or you find that you’re losing deals because of product gaps, action must be taken.
Yes, there are some inexperienced Product Managers who don’t do their homework and regularly change their minds, but most capable Product Managers are reasonable people who 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.
Product Managers may be smart, but they aren’t psychics. Product Managers make decisions. Decisions are based on currently available information. If something material happens after a decision is made that requires a change in product plans, the change must be made. Product Management has always worked this way, but waterfall development methodologies didn’t. With Agile, Engineering can now be more flexible and adaptive to change.
Score: 4 for 4.
So there you have it. QED.
Product Managers have been living the elements of the Agile Manifesto for years. We just may not have known it!
Now, even though there can be better alignment between Product Management and Engineering, there is one thing that is missing from the Agile Manifesto that, if added, would bring complete harmony between the two organizations.
One of the biggest gaps between Product Management and Engineering is the divergence of the two groups when it comes to business objectives. Product Management must prioritize the business needs and optimize the requirements to address those needs. On the other hand, Engineering focuses almost exclusively on the technical issues, and is often detached from the business priorities.
In theory, the Agile Principle 'Business people and developers must work together daily throughout the project' ensures that business priorities are met. The assumption here is that through constant, in fact, daily communication, business priorities are conveyed to Engineering and thus they are met within a project.
The problem is that it removes the responsibility for Engineering management to ensure technical decisions made during the development process don’t hamper the business later on once the product is released.
Too often decisions are made by Engineering because of technical constraints without truly understanding the impact on the overall business. Product Management cannot be there at every decision point to ensure that all developers and testers make the right decisions. And the result is that too often products don’t install properly or odd constraints are included in the product due to technical decisions made during the development process.
I once saw the following happen with a software product. A customer had purchased the product and licensed some modules. When they installed the product, the license keys for at least one module didn’t work. The module’s functionality couldn’t be enabled. The Support team identified it as a bug in the licensing functionality and escalated it to Product Management.
The PM went to the head of QA to find out more about the problem. The conversation went something like this:
PM: Hey, just wanted to confirm whether this bug with licensing is really a bug?
QA: Yes it’s a bug.
PM: Then it’s a regression, right? Because I know the licensing worked in the previous release.
QA: Yes, it’s a regression.
PM: So, how did we miss this? Who tested the licensing?
QA: [Looking at the PM more intently] No one tested licensing.
PM: Uhhh ... what do you mean by “No one tested licensing”?
QA: Licensing wasn’t tested because there were no licensing changes between releases. We have to prioritize the work we do. We can’t test everything. What do you expect? Zero bugs? That’s never going to happen.
PM: Agreed, you can’t test everything. And I don’t expect zero bugs? What I do expect is zero surprises. Licensing is how we make money. It has to work or there is no business.
QA: Look, there will be a patch out soon. And as I said, we can’t test everything. We didn’t test licensing. And I’ll tell you, if my boss was here right now, he’d support me in my decision.
Thankfully, it turned out that the QA Manager’s boss didn’t agree with him. The QA head was not a junior guy. He’d worked in software for about 10 years. Yet he didn’t understand how important licensing was to the business. From his perspective, it was no different than any other “feature." But in this case, licensing isn’t simply a feature, it’s the key to enabling revenue.
All departments, including Marketing, Sales, Product Management, Finance and Development must be aligned with the goals of the business and each group must understand their role in ensuring business success. In general, Engineering teams are not exposed to the business needs and goals. They’ve primarily relied on Product Management to communicate those objectives to them. But not anymore!
If the Agile Principle listed earlier is broadened and enshrined as an element of the Agile Manifesto, harmony can be attained. Thus I propose the following 5th element be added to the Manifesto:
Business alignment over technical efficiency
In the spirit of the Agile Manifesto, it’s important to remember that each element is structured such that both aspects in the element are held as valuable, but the one on the left should be valued more.
In this fifth element, technical efficiency is very important. It’s a key aspect of the software development process and it’s a fundamental expectation of Engineering. But that efficiency cannot lead to decisions that would trump or block overall business needs.
With this fifth principle in place, Development and Product Management can work more closely and confidently in ensuring their decisions and actions consistently align with the business and its goals.
Looking for the latest in product and data science? Get our articles, webinars and podcasts.