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.
If you would like to learn more about Product Management role in an Agile environment, take our new training course: Agile for Product Managers and Product Owners, available in-person or as an online course.
Download the first two chapters of Agile Excellence for Product Manager 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.
Senior Principal Consultant and Trainer