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:

7 Responses to “Agile Product Management”

  1. Matthew Bowe sagt:

    Great discussion points! I’ve always jokingly said, Agile creates more problems than it solves. Really, though, it SURFACES problems in the organization so they have to be dealt with. And, I would also agree with you that if the entire team of stakeholders is not on the same page, it can make the PM (or BA)’s job much more difficult.

    • Matthew,

      great point. In terms of surfacing, I think that there are two separate areas:

      – Companies want to make development projects more agile. Here sprints, etc make perfect sense (or at least they can work).
      – You need to make sure that the rest might follow a different agility pattern (as it might not make sense to just dump the sprints, etc into the complete organization).

      My guess is that the interface is important between development and the rest (speaking technically: you need to uncouple both systems). At least, if you want to achieve that the solution to one problem does not create others.

      Andreas

  2. Whether you call it product manager or product owner or Fred, what matters is that the dev team have real and up-to-date info on the market. The challenge for many in agile is that developers want 24/7 access to product managers and ALSO want up-to-date information from the market. Alas, one cannot do both. product managers need to allocate time with development and also plan time in the market. My rule is to spend no more than one day each week with the dev team (time for planning on the front end and demos on the back end of the sprint); that leaves time for working with sales, marketing, support, and execs–as well as time available to spend time with customers.

    The other challenge of course is that agile development dramatically improves development but impacts the rest of the organization. Agile shouldn’t be implemented in isolation. All downstream departments are affected so they need to embrace agile methods as well.

    Steve

    • Steve,

      you are making a good point. Also in my experience, a kind of capacity levelling is essential in making you a good PM (and perhaps the only way to survive, if you are the one guy, who needs to fill all these roles in person, which you mentioned). An additional improvement in terms of agile would be that you reserve more time for release independent items (so to speak, you work one day for devt, and their immediate needs, 3 days for the others, and 1 day for the futue needs).

      „Isolation“: Yes, up to a certain extend, it is required to decouple PM from Devt to enable agile. One reason, other than capacity is „maturity“. In my experience, a development, which is finished, is not always finished, but requires some iterations. Simply speaking: In the waterfall area devt worked on one requirement after the other, and at the end, we put all together, and improved consistency. After that we went to marketing, and rolled it out. If devt now works with agile methods, you need to somehow take care not to loose the benefits of this consistency phase.

      Andreas

  3. Thanks for your feedback. That role of product management (define a product in a way that it can be commercialized in terms of high-performance) is certainly becomming more and more important in an agile world.

  4. Cecilia Brunback sagt:

    What a writeup!! Very informative and easy to understand. Looking for more such blog posts!! Do you have a myspace or a facebook?
    I recommended it on digg. The only thing that it’s missing is a bit of new design. Nevertheless thank you for this information.