Product Management and Agile

By Pragmatic Institute July 30, 2008

Extreme Programming and other forms of agile development are sweeping into the vendor world. With emphasis on quick iterations and brevity in artifacts, the new approach to planning documentation is a breath of fresh air.

There are some who say that product management is the enemy, that product managers will try to impose structure, that product management will require detail where none is necessary. Fundamentally, some say that product management stands for everything that agile is not. How does product management contribute to Agile?

What is agile?


We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

People and results are good; process is merely a means to an end. Definitely! Who could disagree with this?

And yet.

Process and tools are safeguards for individuals and interactions. Comprehensive documentation is necessary to deliver and maintain working software. Negotiation is often how we codify customer expectations. A plan is a technique that allows responding to change.

I don't think that agile advocates the elimination of process, tools, and discipline. I think (or at least I hope) that it advocates that process, tools, and discipline are in support of individuals, interactions, and the delivery of working software.

Why agile?

Agile development isn't so much a new approach to programming as it is a response to bad management. In the past, too much effort was spent on documenting exactly what would be delivered before a line of code was actually written; too much energy was wasted getting precision on estimates long before those estimates could be considered reliable. Everyone in development knew that these methods weren't working. But management didn't know. So developers became increasingly frustrated with the planning process. Management enforced dates that no one believed; management required detailed documentation and schedules long before the details were known. No wonder developers were frustrated.

We used to be agile long ago. A customer would ask for a report and we'd show up with 132 character wide grid paper to design the report. 'Company name? Okay, 40 characters plus a space is 41. Invoice date? 6 characters plus 1 space. What else?'

Then development became a key part of business. And the head of development wanted to know how long you'd be working in accounting because the manufacturing project needed your skills too. And customers wanted to know how much the report would cost before they committed to the cross-department billing. And then HR wanted to know how many actual hours were spent in each area for internal billing of your time. These are all legitimate requests, aren't they?

Working as a developer in a business involves working as a business—which means resourcing and scheduling highly skilled workers.

The big problem that agile is trying to address is not so much that management is bad; it's really that management is early. They want to know too much too soon, long before the development team actually knows. They ask for estimates, get our guesses—and they are guesses—and then announce delivery dates for the project.

Management mandates rigor and precision before the scope of the work is truly understood. 'How long would it take you to build something?' Well, depends on what something is, doesn't it? 'Yes but give me a date anyway.' Management over-commits development all the time.

Developers see the product managers as senior management's police force. And I have to admit that this is somewhat legitimate. Haven't many product managers imposed dates on projects they don't truly understand? Haven't many product managers enforced process and documentation beyond what is necessary?

So finance people and sales people and marketing people are making scheduling decisions for development projects they don't understand with inadequate information. Sounds like a recipe for disaster. And it is. Thus, agile was born!

Where does product management fit?

Product management is fundamentally about delivering repeatable products to a market of customers. This requires a deep understanding of market requirements. The problem is that most development methods are designed for one-off projects rather than repeatable products. So where does product management fit in an agile development environment?

One of the key aspects of agile programming is an onsite customer. While this makes sense in a one-off environment when customer and developer are in the same building, it's unworkable in a vendor model. How do you have an onsite customer in a vendor model? Answer: the product manager serves as the customer representative in planning and requirements definition.

Building a repeatable product requires feedback from many customers, not just one. So someone needs to aggregate the requirements from many sources into a single coherent set of requirements. Answer: the product manager defines the requirements and the product roadmap for a market of customers.

Delivering a product to a market of customer requires synchronizing the software, hardware, services, documentation, marketing programs, and sales tools to present a complete product to the marketplace. Answer: the product manager must integrate all schedules so we can deliver and support the product in the market.

In agile programming—and frankly in any programming model—the effective product manager serves as representative of a market of customers.

But there's another role: the effective product manager also serves as a shield for the product team, protecting the team from sales and management commitments that will derail the project. Building a product is like driving a train: it takes a long time to start and a longer time to stop. And once the train leaves the station, it's very hard to change direction.

We support agile

As product managers, we should support the ideals of agile development. We want some process but not too much process. Smaller iterations give us more flexibility in adapting to change. Less time spent documenting leaves more time for programming. We want to assist development and the rest of the team in delivering a complete product to a market, creating a product that people want to buy.

Categories: Working with Development Requirements Agile
Pragmatic Institute

Pragmatic Institute

Pragmatic Institute (formerly Pragmatic Marketing) has continuously delivered thought leadership in technology product management and marketing since it was founded in 1993. Today, we provide training and present at industry events around the world, conduct the industry’s largest annual survey and produce respected publications that are read by more than 100,000 product management and marketing professionals. Our thought-leadership portfolio includes the Pragmatic  Framework, eBooks, blogs, webinars, podcasts, newsletters, The Pragmatic magazine and the bestseller “Tuned In.”


To learn more about our courses and join the growing international community of more than 150,000 product management and marketing professionals trained by Pragmatic Institute, please click here.

Looking for the latest in product and data science? Get our articles, webinars and podcasts.