/rewind to september 2006/
I feel bad for software product managers. As a
I'm watching a number of our product teams as they transition to agile development methodologies, and while I can tell the developers are grooving on it, I'm not quite so sure about the product managers. It could be I just catch them at odd hours.
So in the hopes of coming to understand the challenges my dear colleagues are facing as part of this transition, I went a-searching for some lore on agile software product
And whaddya know, I found a whole blog dedicated to it. I shouldn't have been surprised.
For some reason its author chooses to remain anonymous (like the Cranky Product Manager, who has good reason to do so). My guess is the author works on NewsGator, but I could be wrong. It could all be a sophisticated bit of misdirection.
The more I learned about "agile product management" as a discipline, the more the challenge became trying to figure out how product marketing can adapt to the agile development process as manifested in the luminous being of the agile product manager.
Bottom line - what does agile product management mean for product marketing? Off the top of my head. . .
- We can help the aPM (agile Product Manager) with iteration sequencing, based on market urgency and availability of ready prospects.
- We can - if we're really clever - give the aPM insight into which features are really being used based on market surveys or other magic, so that the aPM can allocate testing resources to where they're most needed. Why test the bejeebus out of stuff that no one uses? It's the classic split between buying and usage features.
- We can - and should - guide the aPM's analysis of how much of a feature to bite off the first time around. This is my favorite. aPMs, gawd bless their clever hearts, are often developers deep down, and they have a built-in pride that in some cases prevents them from building a less-than-complete solution - even when they should.
Like their development counterparts, the agile Product Manager thinks in terms of iterations - some of which could be candidates for shipping, if done correctly. Getting successive versions of a solution into the hands of users is the best way to find out if you've gotten it right. Product marketing - if it wants to be agile too - should adapt to think less of monolithic launches and more of "evolving" solutions; done correctly, these solutions should have the capacity to roll into the hands of customers at different rates.
In a way, agile product marketing is postmodern product marketing - it takes an orthogonal view of how software solutions are delivered, used and promoted when compared to the traditional air-lift launch.
Ideally, agile Product Marketing should be able to take a solution stream and condition sales, customers and channels to receive the stream. Doing so won't be easy - just think of all the back-office systems that need to be touched to do this, all the collateral that needs to be updated, salespeople who need to be briefed, channel partners who need to be notified, marcom programs that need to be prepared, analysts and reporters who have to be conditioned to pay attention differently. . .don't forget pricing. . .
The go-to-market complex for start-ups is simple - drop the new build on your FTP site. For the rest of us, it gets complicated. It's one thing for development to deliver products using an agile methodology - but then they have to go to market. "Delivery" from dev doesn't constitute "market availability" - even if you're one of those fancy new-fangled Web 2.0 or SaaS vendors. Compiled Code isn't Ready for Sale. And it's getting the rest of the organization Ready for Sale that poses the greatest challenge for the agile Product Marketer.
More on this later. Who knows, I could just be smoking dope here.