Agile.
That word means different things to everyone. To me, it really means being efficient – and leveraging the best parts of a team.
Of course, there are many different facets and “things” to agile – scrum, extreme, DSDM, getting real, etc… But what do these all mean to organizations and product managers?
Pragmatic Marketing’s Annual Product Management and Marketing Survey can definitely shed some light on it for us. I’ve taken a pretty straightforward approach to this post, because hey — I’m a pretty pragmatic guy (no pun intended). I like to facts to be presented to me, with some analysis / thoughts / opinion around them and then I can draw my own conclusions.
So that’s what I’ve tried to do.
Just as a preface – I firmly believe in agile practices. And not just because that have cool terms and names like scrum and sprint and stories. But because they really do lend themselves well to where I have chosen to spend my career – in technology start-ups. Lightweight, super-effective, and while not everyone buys in to the methodology, I’ve never seen the core of them fail a small company.
With that, lets get to it.
Agile Product Manager Demographics
The first step is looking at the typical agile product manager. Let’s look at some demographics:
- Average agile PM salary: $104k
- Typical experience level for agile PMs: 6-10 years
- The large majority have degrees – predominantly bachelor degrees and MBAs
- Most define themselves as being somewhat technical
- Average age is 39
- Predominantly Male
This is very interesting. I think this may scare some people – especially the younger folks in the audience. Don’t be.
You don’t need to have 10+ years and be over 35 to be successful as an agile PM. However, I do think this proves there are a lot of organizations out there that newer PMs can get involved in – and there are some really experienced folks out there that can step-up to the plate and be great mentors.
And that just means the World will get even better products as a result, which is always a good thing.
So now that we have an idea of the typical agile PM demographic, let’s get the meat of the data – what do agile PMs spend their time on?
Agile Product Manager Activities
There are a couple of complexities to this aspect of my analysis. The first is understanding that I don’t believe in requiring a Product Owner to be present in order to successfully have agile-based product teams. That being said, they can play a tactically positive role based on the scale of the organization. Really, they need to be there to help the PM out so they can remain active in their most important activities – which should be strategic.
One of the biggest traps agile PMs can fall in to is firefighting. Because things are happening so quickly, there is a strong tendency to really get bogged down in the day-to-day. So – let’s see if that’s happening.
I’m actually pretty shocked at how this turned out. I thought for sure I would see some huge variances in certain activities, so I’ll attack the general points.
There’s some great stuff in here – and it shows that PMs are spending their time in the right places, and it doesn’t appear as though agile PMs are fighting many more tactical fires than non-agile PMs. I’d be lying if I said it didn’t make me smile that almost 20% of folks that responded really aren’t spending time on the sales process.
I think this does show that agile PMs could be spending some more time on a roadmap, however. I always like to keep a high-level view of the backlog on-hand that gets updated regularly and discussed. In addition, I think all PMs could be spending some more time on defining and reviewing metrics. Those things are critical and they do tend to get ignored; I’m guilty of this as well.
My next part will discuss some other key tasks for PMs, and this type of comparison. As well as more discussion about product owners, and the reporting structures for agile PMs. You can already start to see some more posts popping up – Scott has a great analysis up, and there will be certainly more to come.
{ 5 comments… read them below or add one }
Very cool. While your chart shows that the averages for time-spent are very similar between agile and non-agile product managers, I wonder if there's some more insight to be found in the data.
Agile has been coming on fast and furious, while non-agile is pretty well established – in terms of what product managers do. I wonder if agile product managers are “all over the map” in terms of how they approach the job, as each PM climbs a (somewhat) independent learning curve. It would be interesting to look at the distribution of responses and compare. Maybe a good litmus test is roadmapping. While 70% of the PMs in both groups reported “roadmapping” as something they do, I wonder if there's a different distribution of “time spent” that shows up in the data.
I also suspect that “roadmapping” means different things to agile / non-agile product managers. A waterfall PM would probably not consider “what are we doing two weeks from now” as part of their roadmapping activity – but an agile product manager may consider this product-backlog-prioritization activity to be part of roadmapping.
I also wonder if team sizes are different for agile folks, product-revenue-managed, etc. I also wonder if “product owners” look like “agile product managers” in the data too. And why does someone self-report as one versus the other.
Thanks for the pulling together the data – this is very fun stuff, and I'm really looking forward to your next one.
The only extension to this is the third type of product manager… From what I have seen, most are making a complete mess out of Agile and this leads to three types of product managers: 1) Traditional Product Manager with MRDs/PRDs, 2) Traditional Product Managers in Agile Environments with MRDs/PRDs and 3) New Wave Product Managers in Agile with backlogs. From what I see, #1 and #2 are still working consistently with the same responsibilities, but #3 is likely dragging the average down for the “Non-Agile PM”. I think this is why the numbers are a little closer than you expected. Despite that, I think the buzz on the street is starting to educate the #3s and these Agile vs. Non-Agile numbers will continue to trend closer in the future. – Stewart
The demographics are very realistic, I do know for a fact that there are Agile Product Managers in their late twenties out there, whether they're doing a good job or bad job is another story. Experience plays a huge role here because IMO, to be an Agile Product Manager you have to have a solid Project/Product Management experience, as it builds on it.
Agile development is very effective when there is an incremental improvements for the products. If you are developing a completely new feature or product one needs MRD and PRD. Engineering wants to know the bigger picture and direction. It becomes difficult to explain these things in user stories. I choose a combination of both for big rocks (requirements ) and followed by pure agile for incremental enhancements.
Once you get used to agile it becomes a way of life. I am overall impressed with the process. I get things faster and better. That is what i as a product manager really care about. I don't see myself changing or reallocating time on other activities after moving to agile. I see it more like an evolution of development process and nothing beyond that.
Agile development is very effective when there is an incremental improvements for the products. If you are developing a completely new feature or product one needs MRD and PRD. Engineering wants to know the bigger picture and direction. It becomes difficult to explain these things in user stories. I choose a combination of both for big rocks (requirements ) and followed by pure agile for incremental enhancements.
Once you get used to agile it becomes a way of life. I am overall impressed with the process. I get things faster and better. That is what i as a product manager really care about. I don't see myself changing or reallocating time on other activities after moving to agile. I see it more like an evolution of development process and nothing beyond that.