Agile Product Management

These days, software systems are large, and they become challenging and expensive to create. In the recent years, many companies tried to formalize the development process, just to be able to better manage this complex process. Most companies used the waterfall method, in which one after the other department worked on its part of the software development cycle.

Often, this process led to a large overhead, de-motivation of software developers, and became expensive to manage. On the other hand, many of us Product Managers rolled in requirements, an even though development implemented them as requested, we (and the customers) were not satisfied with the results.

Principles of Agile Developments

To address these challenges, agile development methodologies became common in many software-development organizations during the last years. As we are now often living in an agile world, as development goes agile, we in Product Management need to re-position us, and our tasks.

In a recent article, I started to look into the topic → Agile Development. Here I will add own thoughts, and recommend some of my recent readings on that topic.

Good Old Days

In former years, many Product Managers worked on requirements, and specifications. At the end we explained the product to the market.

While requirements explain the customer’s problem in a few words, a specification details the solution to this problem. Upon completion, the development department took over these specifications, and worked on the design, and the implementation of the specified line items.

Usually, Product Management then participated in the sign-off and testing phase, right after development. And, we created the rollout information.

With the waterfall method, the complete cycle between the planning of development projects, the roll-in, development, test, and delivery of the final product could easily consume years, while the resulting product went large in size. Two major problems existed:

• It was not quite clear, who was actually responsible for the specification. If Product Management just delivered the requirements, development complained that it does not know, what to develop. If we created a full specification, they asked us, not to mingle ourselves too much into the design of the product.
• The cycle was so long that we forwarded our requirements, and then lost control of the outcome for quite some time. This often led to situations, where the market dynamics overtook our development cycle, and at the end we created products, which missed the needs of the customers.

Refocusing

Agile methods put some control back into the hands of the development department, and target to improve the overall management of the development processes. They basically consist of very rapid and short development cycles (sprints), which use a given set of requirements (backlog) as foundation.

And they deliver a defined product at the end of each cycle. Two important roles are the role of the Product Owner, and the role of the SCRUM Master.

If just development changes to these methods, problems for the Product Management are likely to occur if the transition is not managed properly.

• The first question is: Where do the requirements come from, and who will be taking care to collect them? Either the development project takes over, probably with the result that the product looses customer intimacy. Or, development demands requirements from Product Management in an instance. In both cases, we need to reorganize the processes, which we use in Product Management. To solve this issue, it is required that the complete company adapts to the new working model, and not just a development department on its own.
• The second question will be: What is the PM role in this? In my oppinion, the good news is that also agile development needs persons, who are able to translate customer needs into products, and, which are able to combine the technology-view with the business-view (and these persons do not sit in development).  However, the rollin-role needs to be rewritten.
• The third question will be: How to be able to deal with the new dynamics? For Product Managers to be able to manage the new needs, I think, we need to become experts in market requirements, and we need to become customers. While in former times, we had sufficient time to gather customer requirements after project start (and we could start from scratch), we might now be involved into agile projects, which demand from us to become answers in an instance. This requires from us in Product Management that we start to think and to feel like our customers do (so that we do not need to ask).  This in turn requires that we organize our work into two distinct baskets: Work for the current delivery, and work, which is uncoupled, and directed towards the future.

Further Reading

Pragmatic Marketing has written several → Articles on Agile Product Management. In particular, I recommend you to look into Steve Johnson’s article →  Living in an Agile World: The Role of Product Management When Development Goes Agile.

The → Agile PM Blog is a further interesting source of reading.

Also refer to the link section of my blog, where I publish links to interesting articles, or other websites.

Weiterführende Informationen

Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links:

This entry was posted on Dienstag, Juli 28th, 2009 at 8:52 pm. It is filed under Agile&Scrum, Thema des Tages and tagged with Agile Development, English Content, PM Role, Rolle des PM, SCRUM. You can follow any responses to this entry through the RSS 2.0 feed.