Are agile PMs Baloney?

by Adam Bullied on Feb 11, 09

This could catch me some heat, but I thought it was an interesting conversation so I figured I’d put it out there.

I was having a discussion with a friend over lunch a couple of weeks back, and he made a point that I kind of believed in, but never said out loud, which was essentially that the concept of an “agile product manager” really doesn’t hold much water.

OK, there – it’s out there now. I can’t take it back. And what may be even more sacrilegious – I agree with him.

“Agile” in and of itself is a development framework; I won’t even venture far enough out to say it’s a methodology. Although I’m sure some disagree, but it’s just semantics at this point.

My belief has always been, product management doesn’t change that much regardless of whether you are in tech (B2B or B2C), consumer products (like soap or fabric softener), cars, electronics, etc… Essentially it all boils down to the exact same things: you have a market, and they have a problem. You are charged with crafting the most ideal way to solve that problem, and then making that vision a reality.

Regardless of HOW those charged with executing that vision (or building the requirements) choose to do that, your paradigm doesn’t change. Developers can be working in waterfall, or they can be working in agile. You, as a product manager, shouldn’t care.

Aside from delivering market requirements and making sure things are getting done, the rest is noise.

Yes, you could write feature ideas on sticky notes. You can call those ideas a backlog. You could review them at regular intervals. Does that make you an “agile” PM? Not really – it just means you are doing your job.

Now, don’t grab your pitchforks and torches to come after me yet. Just think about it for a second.

A dev team or engineering team can choose to implement the requirements you, as a product manger, give them in any way they like – so long as they hit their schedule and estimated dates. How does that impact you? It shouldn’t. If you think it does, you are too involved in development – and being that involved in a conscious choice.

I think where most people get hung-up is the requirements themselves. If you are writing them as “as a user, i want to do X, so that I can achieve goal Y” – does that make you an “agile PM?” Not really. How is that any different than, “the system shall do X so user can achieve goal y?”

They both need mock-ups. They both need acceptance tests. They both need to be implemented.

Of course I’m going a little extreme here to make the point. Agile and waterfall have their distinct differences. And yes, they do affect product – but that’s because product works with engineers to get the product they are managing built so it can be released / sold / whatever.

At the end of the day you, as a product guy or gal, are still doing the same things: researching the market, identifying problems, devising solutions, talking to customers, providing requirements, monitoring releases, crafting positioning, etc…

Don’t get hung up on whether or not you are “agile.” You still have to get the exact same things done – regardless of the time table development is using to release them.

Let the flame war begin…

  • http://www.onproductmanagement.net Saeed

    Steve,

    Thanks for the plug. Here's a couple of links to relevant posts I've made on the subject.

    Is Product Management Agile?
    http://onproductmanagement.net/2008/10/30/agile…

    Agile/Scrum Reality Check
    http://onproductmanagement.net/2008/09/28/agile…

    Agile/Scrum and Product Management
    http://onproductmanagement.net/2008/04/29/agile…

    Adam, sorry for posting all these links to my blog, but I think the posts are completely relevant to the discussion at hand.

    Saeed

  • http://writethatdown.com Adam Bullied

    Totally agree – the more the better!

  • http://writethatdown.com Adam Bullied

    Totally agree – the more the better!

  • http://writethatdown.com Adam Bullied

    Totally agree – the more the better!

  • http://www.pmhut.com PM Hut

    I love it when i read such objective posts on Agile/Scrum. If you think that the Product Manager role is trivial, then what do you think when there are 2 roles, the Product Manager and the Product Owner?

    I did publish an article on the http://www.pmhut.com/scrum-product-manager-product-owner-roles-and-responsibilities' rel=”nofollow”>role of the product owner/product manager. What's interesting is that the author merged the 2 roles from the get-go (Btw, in case you had the chance to read the article, look at the challenges part).

  • http://www.pmhut.com PM Hut

    I love it when i read such objective posts on Agile/Scrum. If you think that the Product Manager role is trivial, then what do you think when there are 2 roles, the Product Manager and the Product Owner?

    I did publish an article on the http://www.pmhut.com/scrum-product-manager-product-owner-roles-and-responsibilities' rel=”nofollow”>role of the product owner/product manager. What's interesting is that the author merged the 2 roles from the get-go (Btw, in case you had the chance to read the article, look at the challenges part).

  • http://www.pmhut.com PM Hut

    I love it when i read such objective posts on Agile/Scrum. If you think that the Product Manager role is trivial, then what do you think when there are 2 roles, the Product Manager and the Product Owner?

    I did publish an article on the http://www.pmhut.com/scrum-product-manager-product-owner-roles-and-responsibilities' rel=”nofollow”>role of the product owner/product manager. What's interesting is that the author merged the 2 roles from the get-go (Btw, in case you had the chance to read the article, look at the challenges part).

  • http://productmantra.blogspot.com Darayush Mistry

    Came here from a on the Enthiosys site “How To Sound Smart (But Be Really Naive) …” Loving the conversation here. I think the job of a PM is somewhere in the middle, not as skewed towards tools/frameworks as indicated on the Enthiosys blog and not as insulated from newer tools/frameworks as this post is trying to suggest. But I do agree with the gist of this post that the core of the PM job has not really changed, the tools have.

    Job skills are based on fundamentals and tools augment them. That's why education is based mostly on fundamentals and add some applied perspective with tools.

    I believe the skills and tools aspect of PM should not be mixed up. I'd take a PM with good fundamental skills any day and train them to use the latest and greatest tools/frameworks rather than have someone very fast on the tools/frameworks but weak in fundamentals.

    I think there are fundamental skills that a Product Manager should understand and possess and good tools/frameworks like Agile/Scrum just augment them. Don't get me wrong I'm not saying you don't have to acquire additional newer skills to learn these new tools/frameworks to make your self more efficient/effective in what you do.

    However to me it's a layer that you put on top of the core skill set.

  • http://productmantra.blogspot.com Darayush Mistry

    Came here from a on the Enthiosys site “How To Sound Smart (But Be Really Naive) …” Loving the conversation here. I think the job of a PM is somewhere in the middle, not as skewed towards tools/frameworks as indicated on the Enthiosys blog and not as insulated from newer tools/frameworks as this post is trying to suggest. But I do agree with the gist of this post that the core of the PM job has not really changed, the tools have.

    Job skills are based on fundamentals and tools augment them. That's why education is based mostly on fundamentals and add some applied perspective with tools.

    I believe the skills and tools aspect of PM should not be mixed up. I'd take a PM with good fundamental skills any day and train them to use the latest and greatest tools/frameworks rather than have someone very fast on the tools/frameworks but weak in fundamentals.

    I think there are fundamental skills that a Product Manager should understand and possess and good tools/frameworks like Agile/Scrum just augment them. Don't get me wrong I'm not saying you don't have to acquire additional newer skills to learn these new tools/frameworks to make your self more efficient/effective in what you do.

    However to me it's a layer that you put on top of the core skill set.

  • http://productmantra.blogspot.com Darayush Mistry

    Came here from a on the Enthiosys site “How To Sound Smart (But Be Really Naive) …” Loving the conversation here. I think the job of a PM is somewhere in the middle, not as skewed towards tools/frameworks as indicated on the Enthiosys blog and not as insulated from newer tools/frameworks as this post is trying to suggest. But I do agree with the gist of this post that the core of the PM job has not really changed, the tools have.

    Job skills are based on fundamentals and tools augment them. That's why education is based mostly on fundamentals and add some applied perspective with tools.

    I believe the skills and tools aspect of PM should not be mixed up. I'd take a PM with good fundamental skills any day and train them to use the latest and greatest tools/frameworks rather than have someone very fast on the tools/frameworks but weak in fundamentals.

    I think there are fundamental skills that a Product Manager should understand and possess and good tools/frameworks like Agile/Scrum just augment them. Don't get me wrong I'm not saying you don't have to acquire additional newer skills to learn these new tools/frameworks to make your self more efficient/effective in what you do.

    However to me it's a layer that you put on top of the core skill set.

  • http://writethatdown.com Adam Bullied

    Totally agree, Darayush. I couldn't have said it better myself!

  • http://writethatdown.com Adam Bullied

    Totally agree, Darayush. I couldn't have said it better myself!

  • http://writethatdown.com Adam Bullied

    Totally agree, Darayush. I couldn't have said it better myself!

  • http://writethatdown.com Adam Bullied

    So true. I've been in way too many instances where the expectation was, “keep your head down and get development what they need” – at the expense of figuring out what the market truly is.

    And the product suffers as a result.

    Of course you have to work closely with development. Maybe more so than other functions (maybe except for Marketing) – maybe not. I think that depends on what you (as the PM) are getting out of each group within a specific scenario.

    You may find in one company Sales requires more attention than customer support, or marketing, and so on. You can have a best guess, but until you are in there dealing with day-to-day minutiae it's almost impossible to tell.

    But at the end of the day, PMs can't be firefighters for too long. Sure, everyone has to do that once in a while – but not to the detriment of the business to which the product serves.

  • http://writethatdown.com Adam Bullied

    So true. I've been in way too many instances where the expectation was, “keep your head down and get development what they need” – at the expense of figuring out what the market truly is.

    And the product suffers as a result.

    Of course you have to work closely with development. Maybe more so than other functions (maybe except for Marketing) – maybe not. I think that depends on what you (as the PM) are getting out of each group within a specific scenario.

    You may find in one company Sales requires more attention than customer support, or marketing, and so on. You can have a best guess, but until you are in there dealing with day-to-day minutiae it's almost impossible to tell.

    But at the end of the day, PMs can't be firefighters for too long. Sure, everyone has to do that once in a while – but not to the detriment of the business to which the product serves.

  • http://writethatdown.com Adam Bullied

    So true. I've been in way too many instances where the expectation was, “keep your head down and get development what they need” – at the expense of figuring out what the market truly is.

    And the product suffers as a result.

    Of course you have to work closely with development. Maybe more so than other functions (maybe except for Marketing) – maybe not. I think that depends on what you (as the PM) are getting out of each group within a specific scenario.

    You may find in one company Sales requires more attention than customer support, or marketing, and so on. You can have a best guess, but until you are in there dealing with day-to-day minutiae it's almost impossible to tell.

    But at the end of the day, PMs can't be firefighters for too long. Sure, everyone has to do that once in a while – but not to the detriment of the business to which the product serves.

  • Pingback: Adam Bullied vs. Enthiosys: Don’t Fight! « On Product Management

  • Pingback: Development Capture of Product Management « Life (or something like it)

  • Pingback: To the Agile Community - WTF is wrong with you? | The Cranky Product Manager

  • http://radioevangelist.wordpress.com Steve Burgess

    Tremendous discussion – glad to hear that others struggle with this issue.

    On the face of it, those who come down on the side of “it doesn't matter whether the team is using agile, waterfall or voodoo as their work pattern” are correct. At least, all things being equal.

    But, as a product guy who has worked in all three environments (yes, including voodoo workpatterns ;-) ), my experience tells me that I DO care what work pattern the team uses if the team cannot produce the needed results using that method.

    This is based on the presumption that the primary goal of the Product Manager is to produce results that exceed the market's expectations.

    For example, a project that is defined by a small team, co-located, with a fully engaged group of SMEs and business leaders is well suited for an agile work pattern. A project that is defined by a large, geographically dispersed team with SMEs and business leaders who “drop in” occasionally is best served by a waterfall work pattern. So, as a product manager, if I can have a choice of the methodology my dev manager uses, I would choose the one that best fits the total need of the project.

    So – to the fundamental question of Adam's first post – is there such a thing as an “Agile Product Manager?” Well, yes – in the sense that the “agile product manager” can viscerally understand what workpattern is going to be most likely to get the job done and then be able to actually function in that environment. Is there such a thing as a Product Manager who only works in agile? No – because agile is not the right solution for all projects (please defend me from the barbs and arrows for saying that).

    So – that's my opinion. Have others experienced this as well?

  • http://radioevangelist.wordpress.com Steve Burgess

    Tremendous discussion – glad to hear that others struggle with this issue.

    On the face of it, those who come down on the side of “it doesn't matter whether the team is using agile, waterfall or voodoo as their work pattern” are correct. At least, all things being equal.

    But, as a product guy who has worked in all three environments (yes, including voodoo workpatterns ;-) ), my experience tells me that I DO care what work pattern the team uses if the team cannot produce the needed results using that method.

    This is based on the presumption that the primary goal of the Product Manager is to produce results that exceed the market's expectations.

    For example, a project that is defined by a small team, co-located, with a fully engaged group of SMEs and business leaders is well suited for an agile work pattern. A project that is defined by a large, geographically dispersed team with SMEs and business leaders who “drop in” occasionally is best served by a waterfall work pattern. So, as a product manager, if I can have a choice of the methodology my dev manager uses, I would choose the one that best fits the total need of the project.

    So – to the fundamental question of Adam's first post – is there such a thing as an “Agile Product Manager?” Well, yes – in the sense that the “agile product manager” can viscerally understand what workpattern is going to be most likely to get the job done and then be able to actually function in that environment. Is there such a thing as a Product Manager who only works in agile? No – because agile is not the right solution for all projects (please defend me from the barbs and arrows for saying that).

    So – that's my opinion. Have others experienced this as well?

  • http://radioevangelist.wordpress.com Steve Burgess

    Tremendous discussion – glad to hear that others struggle with this issue.

    On the face of it, those who come down on the side of “it doesn't matter whether the team is using agile, waterfall or voodoo as their work pattern” are correct. At least, all things being equal.

    But, as a product guy who has worked in all three environments (yes, including voodoo workpatterns ;-) ), my experience tells me that I DO care what work pattern the team uses if the team cannot produce the needed results using that method.

    This is based on the presumption that the primary goal of the Product Manager is to produce results that exceed the market's expectations.

    For example, a project that is defined by a small team, co-located, with a fully engaged group of SMEs and business leaders is well suited for an agile work pattern. A project that is defined by a large, geographically dispersed team with SMEs and business leaders who “drop in” occasionally is best served by a waterfall work pattern. So, as a product manager, if I can have a choice of the methodology my dev manager uses, I would choose the one that best fits the total need of the project.

    So – to the fundamental question of Adam's first post – is there such a thing as an “Agile Product Manager?” Well, yes – in the sense that the “agile product manager” can viscerally understand what workpattern is going to be most likely to get the job done and then be able to actually function in that environment. Is there such a thing as a Product Manager who only works in agile? No – because agile is not the right solution for all projects (please defend me from the barbs and arrows for saying that).

    So – that's my opinion. Have others experienced this as well?

  • mediadude

    Tremendous discussion – glad to hear that others struggle with this issue.

    On the face of it, those who come down on the side of “it doesn't matter whether the team is using agile, waterfall or voodoo as their work pattern” are correct. At least, all things being equal.

    But, as a product guy who has worked in all three environments (yes, including voodoo workpatterns ;-) ), my experience tells me that I DO care what work pattern the team uses if the team cannot produce the needed results using that method.

    This is based on the presumption that the primary goal of the Product Manager is to produce results that exceed the market's expectations.

    For example, a project that is defined by a small team, co-located, with a fully engaged group of SMEs and business leaders is well suited for an agile work pattern. A project that is defined by a large, geographically dispersed team with SMEs and business leaders who “drop in” occasionally is best served by a waterfall work pattern. So, as a product manager, if I can have a choice of the methodology my dev manager uses, I would choose the one that best fits the total need of the project.

    So – to the fundamental question of Adam's first post – is there such a thing as an “Agile Product Manager?” Well, yes – in the sense that the “agile product manager” can viscerally understand what workpattern is going to be most likely to get the job done and then be able to actually function in that environment. Is there such a thing as a Product Manager who only works in agile? No – because agile is not the right solution for all projects (please defend me from the barbs and arrows for saying that).

    So – that's my opinion. Have others experienced this as well?

Previous post:

Next post: