#Agile Product Management vs. #Agile Project Management

I think the time has come where the Agile proponents (myself included) need to be very clear on whether they are speaking from an Agile Product Management or Agile Project Management point of view. Some of the more controversial posts on Agile Practices seem to be aligned very well with Agile Product Management, but perhaps somewhat less so with Agile Project Management.

How do I define the two?

Agile Product Management : Typically the project team is producing a product. A product can be defined as a solution that either is being sold to multiple clients or has the potential to be sold to multiple clients. The time horizon for the work and decisions are more future thinking and longer term as value is always based on increasing the potential for multiple sales.

Key indicators: Stakeholders include end clients and product company team members that are not part of the development team. There may not be a formal contract or Statement of Work.

Agile Project Management : Typically the project team is producing a solution to address a specified business need and address a business case. Many of the decision may need to be tempered to ensure the project team can make current commitments. Focus is less on future thinking and more on current commitments. (although not totally ignoring the requirement to have the solution to flexible in the future)

Key indicators: Stakeholders include end clients and project team members. There is a formal contract or Statement of Work.

Agile Product Practices

The practices that are somewhat more aligned more with Agile Product Management than Agile Project Management are:

  • Minimal documentation outside of User Stories and executable Test Cases
  • Absence of formally defined  scope
  • Absence of estimation of scope

Although these practices can be minimized or eliminated for Agile Product Management, it is not realistic to expect the same for Agile Project Management. When working with clients on Agile projects, there are certain constraints that clients operate under that may not allow for these Agile Product Practices to be used.

I believe we need to start separating our Agile Practices into the two camps to start to discuss which practices work best in each. If we don’t do this we risk having Agile Product Management that isn’t as Agile as possible, and Agile Project Management which takes on excessive risk by trying to apply practices that may not be the best fit.

My perspective is always more on the Agile Project Management style as that is the circumstance I encounter the most in the engagements I have.


Author: Terry Bunio

Terry Bunio is passionate about his work as the Manager of the Project Management Office at the University of Manitoba. Terry oversees the governance on Information Technology projects to make sure the most important projects are being worked on in a consistent and effective way. Terry also provides leadership on the customized Project Methodology that is followed. The Project Methodology is a equal mix of Prince2, Agile, Traditional, and Business Value. Terry strives to bring Brutal Visibility, Eliminating Information islands, Right Sizing Documentation, Promoting Collaboration and Role-Based Non-Consensus, and short Feedback Loops to Minimize Inventory to the Agile Project Management Office. As a fan of pragmatic Agile, Terry always tries to determine if we can deliver value as soon as possible through iterations. As a practical Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Traditional and Agile approaches. Terry is a fan of AWE (Agile With Estimates), the Green Bay Packers, Winnipeg Jets, and asking why?

4 thoughts on “#Agile Product Management vs. #Agile Project Management”

  1. Totally agree. I’ve been delineating this as emergent or convergent outcomes. I think your distinction is more clear and concise, but I could see an R&D project requiring emergence, and a product company trying to hit a specific customer deliverable. That said, I like your distinction and this post is dead on.


  2. Interesting distinction that I never quite got but your definition of the two actually works for me. I am a contract, adaptive PM and I would say I practice agile project management. The companies I work for are generally corporate type busienss and governmental / quasi-govt organisations so they are trying to produce a solution to a business need not producing a product to be on sold and make zillions. No matter how agile they want to be or think they are they always have a minimum level of process they expect to be applied and documentation they require. I work on them from the lean angle of “just enough”. I always try and avoid the excesses of too much documentation by saying we will do just enough to meet their needs. An agile product management mindset and associated practices would scare the living day-lights out of the majority of these organisations. An agile project management approach gives them confidence to embark on an agile journey because they see things they are familiar with in a normal software development project althoguh they might be slimmer, while providing me with the flexibility I need e.g. not getting swamped in administrative paperwork related to docs, GANTTS and change control – to really help them out.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.