The Strategic Role of Product Management when Development goes Agile

By Pragmatic Marketing, Luke Hohmann, Rich Mironov
November 10, 2009

For years, product management seems to have been defined by what it is not as much as what it is. Developers and engineers often see product managers as technical resources, to be used for project management. Agile development methods seem to have made this orientation even worse, with product managers getting pulled into deeper tactical, technical activities. But spending so much time with internal, tactical teams means less time spent outside the company in the market. What is the role of product management in an agile world?


Volume 6 Issue 5

While software development teams have been moving toward agile methods for years, many product managers are only now becoming aware of it. An agile approach applies collaborative and continuous improvement concepts to software development. It emphasizes close collaboration between development teams and customers; frequent delivery of deployable code (in sprints); face-to-face communication with customers; tight, self-organizing teams; managing backlogs of user stories to reduce requirements churn; and identification of self-improvement opportunities.

There is no single, definitive “agile method.” Agile teams tune practices and processes for themselves to create a method that is unique to their environment. Broadly, agile methods function as both an organizational philosophy and a set of development methodologies.

When you adopt agile development methods, you encounter new concepts, new artifacts, new planning methods, and new roles and relationships. It seems that agile teams do everything in a new way. And, as you attempt to integrate agile into your existing systems, you’ll also attempt to map these new concepts to your old, familiar concepts. Requirements are now stories; iterations are now sprints.

And a product manager is now called a Product Owner… right?


Companies adopting agile methods know that product teams need a voice representing the customer. Developers need personas, market problems, and most of all, a prioritized list of requirements. Agile methods advocate a role called product owner to support the product team with customer and market information. Since the closest equivalent to product owner in most companies is the product manager, it seems natural to equate the two.

But product owner and product manager are not the same. In fact, a product owner’s responsibilities are just a small subset of product management.

What is a product owner?

The product owner is a new role, created and defined by the Scrum Alliance. Product owners live full-time with development teams—elaborating users’ stories, managing sprint-level backlogs, expanding specifications, and interpreting product vision.

Most product companies already have staff members with similar skills, such as a requirements analyst or business analyst (titles and job descriptions have shifted over time, but product companies have always needed to provide developers with detailed, feature-level information and UI guidance; someone with intimate customer experience is always necessary to build great software).

The product owner addresses the agile development teams’ intense need for real-time input on user stories, user experience/user interface, and requirements.

Spotting fundamental flaws

Product owners can close the gap between a product manager’s inbound role (that is, understanding the needs of the marketplace) and the development team’s need for product direction (that is, understanding the detail of personas and their problems).

There are, however, a few fundamentally flawed assumptions built into the product owner role that experienced product managers immediately spot. These flaws become abundantly clear when the product owner role is aligned against pre-existing functions (e.g., requirements analyst), which we would not expect to drive strategy:

  1. The top determinant of a product’s revenue success is whether it meets real customer needs. Regardless of what the development team builds, a product without interested customers is a failure. It’s the agile product manager’s primary job to meet existing customers and potential prospects face-to-face and deeply understand what they want.

    Throughout the development process, the product manager represents customers against short-term trade-offs. If there is a product owner, he or she needs to channel the product manager throughout the day, avoiding short-term thinking that can come from living with Development every day and answering only to the technical team. Remember: You can’t understand customers without getting out of the office.

  2. Product owners can’t rank backlog based on ROI. In fact, this task is impossible for anyone to do, since real business metrics and financial projections don’t exist at the feature/backlog/item level. Researchers tell us that the only way to assign revenue at the feature level is to perform conjoint analysis on every feature. Will any company perform this type of research for each product project? Probably not.

    A broader and more rigorous backlog ranking approach, “prioritizing for profit,” considers market opportunity and corporate strategic fit at the product level. Most important to this process is someone who can prioritize the issues of all stakeholders, considering the needs of buyer and user personas, key new markets, and issues of internal stakeholders in Sales, Marketing, Support, Development, and others.

    Every release must have at least one feature (story, improvement) requested by each major stakeholder group. Figuring out the features for a release is an organizational challenge, not a technical challenge. The market-driven product manager should determine what goes into the final product; a product owner cannot.

  3. Real revenue is driven by pricing and packaging. Product managers typically own pricing; product owners rarely do. And unless you have a seasoned product manager driving software pricing and packaging, you’ll be leaving revenue on the table.

  4. Creating successful benefits and feature descriptions that truly sell products requires a detailed understanding of the technology and a detailed appreciation of the customers’ problem. This takes lots of practice, hands-on field experience, and a clear view from both sides. In our experience, internally promoted technical staff members almost never get this right. Marketing materials created under this approach are often feature-heavy, too technical, and fail to motivate the exchange of money.

In cases where large projects (products) are divided into multiple teams, it makes good sense to have a product owner (or requirements analyst or business analyst) assigned to each team—just as we would have a development manager and program manager (scrum master) and QA manager assigned to each team. The point of integration for these teams, though, is a single product manager. When the executives demand “one throat to choke,” it’s the product manager who is responsible for overall success of the result.

Page 1 / 4

About the Authors

  • Pragmatic Marketing

    Pragmatic Marketing, Inc. 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 Marketing Framework, eBooks, blogs, webinars, podcasts, newsletters, The Pragmatic Marketer magazine and the bestseller “Tuned In.”

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

  • Luke Hohmann is the Founder & CEO of Enthiosys, a recognized expert on agile product management of software products and a former senior software product manager at four companies. He is the author of three books and numerous articles on software product management, and a frequent speaker at software and other industry events. He is currently a member of the Agile Alliance. Contact Luke at

  • Rich Mironov

    Rich Mironov is a seasoned software executive and serial entrepreneur. He has been the "product guy" at six tech startups including as CEO and vice president of marketing/products. He has also consulted to dozens of technology companies.

    Rich founded the first ProductCamp and chaired the first product manager/product owner tracks at the Agile Alliance’s annual conference. He is the author of "The Art of Product Management" (BookSurge Publishing, 2008), which collects the best of his long-running Product Bytes blog about software, start-ups, product strategies and Silicon Valley product management.  Rich has a bachelor’s degree in physics from Yale (with a thesis on dinosaur extinction theories), an MBA from Stanford, and provides guest lectures at various business schools about the business of software. He can be reached at

Categories:  Working with Development Agile

Post a Comment


Allowed HTML: <b>, <i>, <u>