Document Actions
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 software development, Product Managers need to change how they function and adapt themselves to a new way of developing software. By Saeed Khan
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 if 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 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 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 do I expect is expect 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. But, 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 it’s goals.
Saeed Khan is a 20-year veteran of the software industry with deep experience in product management, product marketing, and education. He has written a number of articles for Pragmatic Marketing's publications. Saeed is based in Toronto Canada, and can be reached via his blog at http://www.onproductmanagement.net
Agile Product Management
Thanks for the positive comments. One thing I'd like to add is about the requirements gathering progress and how to communicate requirements to Development.
Requirements gathering is an ongoing process. It doesn't just happen in the brief period before a release is planned. One of the problems with non-Agile development processes was that while the PM team was collecting requirements in an ongoing matter, development could only consume requirements at specific times -- i.e. the period when they were planning a development cycle.
There was both good and bad about that. On the bad side, it meant that some requirements had to wait a long time to get into a development cycle. On the plus side, you had a good period of time to collect and prioritize whatever requirements were deemed important.
With Agile, the ongoing requirements gathering of PM continues, but there are more opportunities for Engineering to consume them, thus the delays seen with other models are shorten, but do not go away.
Why? Because while development does their work in sprints, Product Management (and the rest of the business for that matter) must think in terms of releases. The notion that software is ready to release at the end of any sprint (in theory) is meaningless unless the entire downstream business (and external partners etc.) can so something with it.
This is a point that is often lost on many development teams who adopt Agile methods. With SaaS or host web apps, that "release agility" can be beneficial, but you can't simply put new features out sprint after sprint and assume it can just be released to customers or users.
So, in summary, Agile development processes mean Engineering can be more flexible and adaptable and better aligned with how the rest of the company actually functions. But they shouldn't put the cart before the horse and assume that because they've changed, the rest of the company must do so as well.
Saeed
Buyer-Beware
Development hides behind the agile manifesto on a daily basis. Getting a commitment that even the most critical functionality be delivered is impossible. There is nothing more frustrating than, "I'll let you know on 'Project Complete' date if it is there or not." This is not an overstatement. (Yes, we do sprints, so we do know about some things every two weeks, but a big picture is impossible to get.)
So, I have read about and lived the world of Agile for nearly two years, and I still wonder (as I did 2+ years ago when were looking at it) what motivates the developer? My experience is nothing. They work at their pace regardless of the demands of the business. And, yes, this starts right at the top, so I do not "blame" the developer per se.
Production of code is down 40-50% per release. Quality is way down. My favorite thing is how we quote our quality numbers in terms of raw defect parameters. So, we produce 50% of code, and defects go down from X to Y defects, and we quote a 20% decrease in defects. Look how wonderful agile is!! Only those of us who are honest know that defect have actually increased by a significant percentage. And, to add insult to injury, we only count defects reported within a given period of time post-release for this metric. If you add all defects between releases, you realize how poor regression testing has become as well.
I come from a manufacturing world where Agile originated and it works great! Having a production floor that can react to the market in a quick and efficient way is great. But, the production floor had to keep specific production and quality levels for the company to succeed. What would I have done if a production manager told me, "That run will be done when it's done..." and, I had a big order that needed to be started by a specific date to be done on time?
In manufacturing, Agile works great, because I can predict the output of a machine. Agile has a lot of issues when dealing with humans in that, where the "motivation" for a machine and production manager is cycles/hours, where is the "motivation" for the developer who says, "You'll get what you get, when you get it, based on the degree to which I feel I should work to get it, because that is Agile to me."
You may argue we did something wrong, which we may have. But, without a driver, e.g., "functionality X" must be there by this date, what motivates the Agile process? Agile in manufacturing is switching production lines quickly to meet new and sometimes unpredictable demand. What is it in development? The market does not change that quickly for our product lines. The only thing that changes is the last customer a VP visited or the loudest complaint heard. We ARE agile in responding to these, but should we be? Where is product management gone?
I laugh at the likely response to the above paragraph which is "X takes what X takes..." True. But, what about the dialogue that used to happen which was, "X will take this long, so we may not get all of Y. Is that okay? Is there something other than Y that we can fit in?" Agile does not permit even a discussion on what X will take. The gull of PM's!
I'll be blunt and really tick a few people off in the process. Agile is a great wall for development to hide behind, because they have no ability to forecast how long even the smallest task will take to complete. For years, development blamed product management for their failing, e.g., the spec changed (so, account for changes-add 20% to your estimate.) The rest of the world works like this, so why not developers?
One day, I will write a book or blog about our experiences. We may be a great or terrible case study. Developers are thrilled at their increased input to the solution delivered (based on talking to one customer) and their new found control on what they work on at the pace at which they work. Management is thrilled that we (appear) to be delivering high quality product. Some customers are thrilled that their little feature which only affects them and a couple of others is found in the next release, because they participated in a focus group and talked to the developer who has no other frame of reference, so the feature gets in. With all this great stuff, no wonder Agile is the talk around my company.
However, the flip side is there is no roadmap which greatly worries customers. Those customers who once had input (we used to canvas customers regulary in numerous venues versus only talking to 3-5 customers in a focus group) have found their voices are gone. Product Managers... Well, there is no such thing anymore. You can now call what were once product managers either project managers or business analysts. Turnover at this position has been very high (100% and growing). Yes, the job description has changed so as to not disillusion would-be candidates anymore once they were on the job for a release or two. And, my favorite part about agile is we are no longer agile as a company!!!!
We used to be the talk of the industry, because we made decisions quickly based on customer feedback, our own experiences, and gut feel. Now, everything requires a focus group. If a product manager mentions a trend or new feature set that needs to be added to the product, their research, no matter how robust, is irrelevant. One VP will say, "The last customer I met didn't mention that..." Or, another VP will say, "We're not hearing that in implementations..." Or, my favorite, is when a developer says, "That doesn't make sense." And, their opinion is valued tenfold greater than the PM's. So, we ignore and abandon what got us here in order to fix a development problem. Why not consider all inputs as we once did?
Over the years, PM's offered many solutions to help with the problem of estimating product delivery, and none were taken seriously, because ultimately, any solution required development to commit. Agile relieves them of that burden.
So, Buyer Beware!! I believe in Agile as a technique for delivering (hands-to-keyboard) software. It is a tool, a really good tool. It is not a business plan, nor a product strategy, nor should it be an excuse for non-delivery/commitment. However, this is exactly how we are using it, and the results are terrible and will get worse as more and more customers become aware of how they are getting less and less with a lower level of quality.
Agile Product Manager
I, like many others, have the good intentions to write about my experiences building a more Agile product management process. I've started with some of the basics on www.theagileproduct.com.
I look forward to a lively discussion of Agile product management as more firms try to adopt and adapt it to their business.
Agile Product Manager
Buyer Beware
Someone in Sr. Management needs to either take charge and address the situation or be held accountable if the situation is as bad as you sound. If you want to discuss issues and possible solutions with me directly, you can email me: skhan at eigenworks dot net.
Is PM Agile
Thank you very much for this great article. In a recent interview, the VP of Eng grilled me about my experience with Agile which I only had with a modified approach of it. This information will greatly help me respond to such queries in that PM has "always" been agile...
Ron
Business-Driven Product Management
In my blog (http://www.ateala.com/blog) I talk about the notion of Business-driven Product Management - the idea that product decisions are made that reflect the business objectives of the company. These are not the high-level executive oriented goals of the company (e.g. grow revenue by 20% or become a more employee-centric company); but instead real operational objectives that drive the product investment priorities. In other words, with finite development resources, companies must direct them to work on items that have the greatest return - and that's driven by the business objectives. For example, expand into market XYZ; make the delivery and support simpler. With these types of objectives you can then decide how important the request is to meeting the objective.
In an Agile development environment the backlog becomes a prioritized list of items based on business objectives. I see that the challenge, especially in companies transitioning from a non-Agile style of development, lies in the ability of the product management team to quickly get to the point where development understands what they need to build - i.e. they have to put together the requirements documents as quickly as possible. They have to stay ahead of development. In non-Agile environments you have the luxury of time to research and plan; with Agile you have to, on a continuous basis, look to your market and write requirements ... you cannot break away from requirements writing to do research - development will then build what they see as needed.
So even, as Saeed has proved against the Manifesto, product managers have been Agile, it's the process or the cycle that guides when they need to do their work that needs to be changed.