Wednesday 15 September 2010

The Product Management Boundary

Talking to a few of my industry peers (web CTOs and CIOs) about what they do, and to a few CEOs about their expectations, something that’s becoming clear is that we’re increasingly being expected to know what to do, not just how to do it.

Traditional IT uses that age old you-give-us-requirements–we-give-you-back-[mostly]-matching-systems paradigm or variations on that theme. Something we do would typically have a sponsor who dreams up a course of action and a handful of stakeholders who detail it out. What you call those people will depend on whether you think you’re doing agile, RUP, waterfall, etc but typically you’d place them in ‘the business’ rather than technology.

That seems to be changing.

Less and less are we being handed requirements documents or project specs and then going off and doing work to order. Now we’re being asked things like; how do we reach new users? What things can we do to increase wallet share? Should we be doing something with social media? How are we going to internationalize this product? Yeah, that’s right, we’re finally dealing in problems not in todo lists, and - in a trend which is gaining popularity - product management is increasingly being based inside the technical delivery teams.

The days of a business giving us defined work and us delivering projects against it are going to come to an end. A pessimist might suggest that this is ‘the business’ escaping responsibility for defining it’s future. I’d simply argue that technology is an integral part of any modern business, not something else extra and external, and since we’re all part of the same ‘business’ anyway then why shouldn’t we take our fair share of determining the strategy?

I think this is pretty awesome and, in some cases, overdue – after all, don’t we want a bigger influence over what the future of the business looks like and how we get there?  Do it CxOs!

No comments: