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…
