Why XPM Is Key

What the hell is XPM? extreme Product Management. Cheesy buzz term? Oooh, yeah. Important? Yes. Why? Let’s discuss.

I’m not a big company guy, which I think I’ve established over the course of several blog posts. Small companies are typically tight on many things — some which are:

So, what are they NOT tight on?

So far, cool, right? Well, not really. Hows does this pan out in the end? Folks can get real ansy in a small org when things take too long. Small companies can move faster than IBM or GE, right? Yes. But remember, moving fast is only one piece — stopping / turning on a dime is something else.

Waterfall projects are a pain in the ass, IMHO. Why? Well, because typically, at least in my universe, no one can tell the future. Now, I could be on my own here, but I’ve never been able to predict (with some semblence of accuracy) what is going to happen 6-8 months from now. So, where does this leave PM’s? With a need to be extreme. But, I hate that term — I prefer agile.

Traditionally, you give developers requirements 1 time, they implement, and that’s it. If the requirements are wrong, then the PM gets slapped around / chained up / whipped / etc… Why is it that someone who is essentially tasked with telling the future gets in trouble when they are wrong? It’s a simple fact — requirements will never be right in all cases. Using an agile PM concept can solve this by allowing a PM to put requirements in front of a developer, and iterate on them (within reason / bounds) to ensure that the end result will pass BAT, and it’s what was envisioned.

Of course, I’m a silly kid without any grey hair, so don’t trust me — you can trust Steve Johnson. You can trust Roger Cauvin. You can trust all those PM’s with 15-20 years experience that I listen and adhere to and learn from daily, to make sure I can at least voice on this blog what I feel is a successful way to do things.

Why limit the success of a product by being able to tell the future? I do agree, that with something that’s agile, boundaries have to be established. Otherwise, you run the risk of never actually shipping anything due to perfectionists. However, factoring in the need to iterate on the foundation of what is actually being developed, at least from where I’m standing, is a great way to ensure things are more successful than trying to drive everyone into a dense white fog without being tethered together at the wrists. Reset, re-adjust, re-balance, whatever — set the milestones, work towards them, and have everyone on board with the idea that: yes, requirements are going to change to make sure what we ship is killer.

Now, I have used the term “concept” in this post more than once. I also believe that shoving “agile methodologies” down everyone’s throat is not the way to go. However, making sure that market knowledge / requirements are not just pipe dreams (and they all to often are), is critical. Don’t just say you listen to customers — actually listen to customers and do your homework.

And for me, it all ties into not relying on someone being good / accurate at pulling out their crytsal ball. Don’t set dates for things to be delivered if the requirements aren’t understood, and developers don’t agree. After all, they need to know what it is they are committing to before committing to it. Saying everyone is going to go really fast and then leaving it to chance and “good solid hard work and long hours”, is not common sense. I’m not advocating process-heavy, goliath type stuff. I’m advocating concepts & understandings within an organization that can be used during execution to help ship cool / great products.

I’m advocating agility.

Aug 11, 06 | Filed Under Business, Product Management

 

Comments