Other Menus

280 Group Optimal Product Management Blog
Product Management Training & Consulting
Agile Product Management Changes

Agile Product Management Changes: How it Affects Your Day-to-Day Job

Agile Product Management Changes are Commonplace

If you are a product manager currently working in an Agile software engineering environment, this post is for you. If you are a product manager current working in a Waterfall environment, but which will be changing over to Agile development, then this post is for you, too. With either engineering process, if you want to manage your product strategically, this post is for you.


Let’s imagine that one day you’re having coffee with your chief engineer. He had just sent you a text message saying that there were big, big changes happening in Engineering and he was very excited. He wanted to meet with you right away.

So when you met, your engineer, let’s call him Bob, was very excited. Bob proceeded to tell you that Engineering was changing the way that they develop software. It’s a whole new methodology, a new way to do their jobs, and it even will affect how you, the product manager, will do your job.

Bob explained that you would no longer write a massive Market Requirements Document. No more long, detailed lists of ALL the needs for the product, prioritized, and explained in detail to be completed before Engineering could start their work. No more issues around changing the requirements once that work is started. Bob says that all of that is going away.

Instead, Bob tells you that to do a project, Engineering will need a short Product Vision and “user stories.” These “user stories” will be only one sentence, and all these user stories will go into a list called the Product Backlog.

Bob tells you, last of all, that you will not need to give all these user stories to Engineering at the start of the project. Instead, there will be “sprints,” which will last two weeks, and you just provide a subset of user stories to Bob’s team at the start of each sprint. Instead of throwing these user stories “over the wall”, you will have to meet with Bob’s team to discuss their meaning before they get started and be available to clarify them as the sprint progressed.

“Wow, I’m going to have to re-learn my entire job,” you think as you smile and make polite conversation with Bob. Inside, you were really, really nervous.

The Reality of Agile Product Management Changes

Relax. Don’t be so concerned. Your job is changing in the way you communicate requirements to Engineering, but the rest of your work as a product manager doesn’t really change. You can still manage your product strategically.

User Stories vs. Market Requirements Document

Let’s look at how Engineering sees your job changing. Before the change, you wrote a Market Requirements Document that had the complete set of needs, following the format:

  • User MUST be able to -or-
  • User MUST be able to – or-
  • User MUST be able to –

The word MUST implies that the solution is a part of Minimal Viable Product. For requirements that are not part of Minimal Viable Product, you use the word SHOULD along with a relative priority.

  • User SHOULD (Priority HIGH or MEDIUM or LOW) be able to -or-
  • User SHOULD (Priority HIGH or MEDIUM or LOW) be able to – or-
  • Some similar way to describe a beneficial outcome.

Now with the user story format, you will write requirements in this format:

  • As a I want to so that I can -or-
  • As a I want to so that I can -or-
  • As a I want to so that I can

The relative position of user stories in the backlog is the way you communicate priorities.

So how significant are the differences in these two formats? Not very. It’s the same information, in a slightly different format. That’s all.

Market Research and Analysis

But going deeper, what work did you perform to write those Waterfall need statements?

Presumably you did market research to define your key personas and their needs. (Of course you did!) You did sufficient competitive analysis to understand which competitors can hurt your company’s profits and which competitors you want to hurt. And didn’t you ( or your Product Marketing counterpart) do a Market Strategy analysis to ensure that you (or the Product Marketing Manager) know how to take this product to market, what messages will resonate with your target customers, and how to get those messages heard by your customers?

Yes, you did all that so you could make decisions based on a fully thought out strategy. We aren’t saying that you need to generate big, fat documents. You should, however, make decisions based on data, and not what the HIPPO (Highest Paid Person’s Opinion) wants.

But what about the Agile user story? Engineering expects you to write user stories with business value. How do you determine business value? You do the same kind of analysis as you would for a Waterfall project, at a level that’s appropriate for the expected revenue of the Agile project. The decisions are, or should be the same and made for the same reasons.

There is one key difference between Waterfall and Agile. Until you take user stories off the Backlog and present them to Engineering, you don’t need to do all the analysis. Thus, you can continue to do your overall business analysis in parallel with Engineering doing software development. This is a Good Thing.

Good luck.

Download the first two chapters of Agile Excellence for Product Managers the book that inspired our new Agile course here:


Meet the Author

Phil Burton is a Principal Consultant and Senior Trainer for the 280 Group. His projects have covered the entire product life cycle and Phil has expertise in product definition, launch, messaging and positioning, collateral creation, competitive analysis and Agile methodologies.

Phil Agile Product Management Changes

Phil Burton
Senior Principal Consultant and Trainer

3 Responses to Agile Product Management Changes: How it Affects Your Day-to-Day Job

  1. Cindy Apr 14, 2016 at 3:54 pm #

    Having worked in both environments, the challenge is in doing the holistic analysis that was originally built-in up front in the process (waterfall.) Now by doing work in pieces, there’s potential for gaps in the end-to-end view. So, word to the wise – have a full analysis and customer needs articulated up front – even if IT will be developing in story segments.
    This will help everyone be successful overall in delivering the envisioned product.

  2. Phil Burton Apr 15, 2016 at 1:03 pm #


    I agree with you 100%. As a consultant, I have talked with a lot of clients and a lot of students in my product management classes. Every says, somewhat apologetically, then they don’t follow Agile “strictly.” They are “Agile-ish,” as one person described it. So I started asking, “What is ‘ish’ about your Agile process?” They always describe a “hybrid” process similar to what you described.

    I think the key is not to be apologetic about their process, but to recognize that they are merging a product management process with an engineering process, so that they can still be effective and maintain a strategic focus to their jobs.

    Thank you for your comment.


  3. Jason Munson Apr 29, 2016 at 1:25 pm #

    +1 for Cindy as well. The upfront documentation (a’ la hybrid) is still extremely valuable, as it helps the Product Manager and the delivery team think about the complete vision and requirements before starting on the work.

What are your thoughts? We'd love to hear from you!