Wednesday, July 29, 2009

response: der produktmanager

Der Producktmanager has an interesting article today on one of my favorite topics: the agile product manager.

PM's challenges with Agile go beyond how to interact with development in "real time" - they now have to translate what comes out of development to the rest of the organization. Odds are the rest of the organization isn't operating at the same speed that development is.

What does this mean?

Exampli gratia: development has decided it wants to use an Agile methodology and throws all its old waterfall chops out the window. The PM translates market requirements so development can make use of them, writes stories, owns the backlog, sets the priorities, these are pretty well known PM activities.

But now you've got "stuff" flowing out of development much faster than in the past. Marketing and sales need to be able to make use of this "stuff" - marketing needs to understand it so it can position it, sales needs to understand it so it can sell it.

Odds are strong that no one told sales and marketing that they need to be agile. They're in their own balkanized silos, they dance to their own tunes, they have their own bosses. They probably look at development with the sort of fixed smiles you save for "special people". They're not built to do sales training every few weeks to spin sales up on new capabilities. Marketing is not built to refresh the website, collateral, partners, press, analysts every few weeks.

And don't forget all the "stuff" zooming out of development needs to be rationalized to a pre-determined strategy, fit in to a pre-determined roadmap, and be able to demonstrate value through whatever success metrics have been (wait for it. . .) pre-determined to be important.

That's a lot of documentation to update. But you need to update it all because documents matter - if you're not writing all of this down, it's not real.

Agile puts the PM into the role of a "transformer", stepping down 220 volt output from the development plug to the 110 volt sales and marketing engine. Without a transformer, whatever you've plugged in will burn hot and bright for a while. . .then burn out.

In summary: just because development can create it, test it and ship it fast doesn't mean the people who need to consume it are ready for it. Ever have a waiter bring your main dish before you're done with your appetizer? Remember that feeling.

Unless your organization is totally harmonized around the idea of fast product turns, the product manager needs to "act agile" with development but "act waterfall" with sales and marketing. PMs who create "product harmony" in this way allow each silo to operate the way it wants/needs to operate to produce optimal results. That's a formula for success.

I'm curious what your real-world experiences are in this area.

Tuesday, July 28, 2009

call for input: the cost of knowing

Hey team - I'm writing an article on a topic of Great Importance to the #prodmgmt community.

No, it's not "Bars with Free Food during Happy Hour" or "Sure-Fire Pick Up Lines for the SDCC Cosplay Show".

I'm writing about the cost of knowing.

"What the &$^$ does that mean? It sounds vaguely 'biblical' and that's unlike you to be so crass."

That's nice of you, thanks. Let me explain.

Product managers rely on all kinds of information to do their jobs. Some of that information comes easily - unit volume, sales reports, support call volume, number of downloads. All of you SaaS cats have it especially easy. You know who you are.

Some is a bit less easy to get your hands on - sales funnel metrics, operating margins, cost of goods.

And some doesn't come easily at all - focus groups, market segment research, competitive sales data.

What I'm exploring are the challenges associated with trying to justify laying your hands on hard-to-get data, and what the follow-on challenges are once you get it.

Because if you have to justify a spend to get data, you're going to have to show that you managed to get value from it.

One of my arguments is that #prodmgmt lives without data it really shouldn't do without. It justifies "not having" this data because it's "too expensive" or "we wouldn't know how to use it".

"That's swell, Bob. Sounds like an interesting article. I've got some toast I'm working on, so unless you've got something you need. . ."

Here's my ask - if you could reduce the cost of acquiring it, what sorts of data would you, my dear reader, wish you could get your trembly mitts on?

Dream big. I want to know what you don't have that you wish you did have. It's that simple.

Thanks for the input.

Monday, July 20, 2009

still: alive

Hey folks - just a quick note to let ya'll know I'm a) still alive but b) traveling like crazy and c) still alive.

To stay abreast of my current whereabouts and state of mind, please refer to my Twitter feed.

I anticipate returning to a more-or-less normal cycle of posting come August. Thanks for your patience.

bob