I was preparing to deliver a webinar on Product Launch in an Agile World rent a car bulgaria and it brought up memories of my days as a developer (fond mostly). While I’m very familiar with Agile at a conceptual level I wouldn’t claim to be a practitioner. That’s for the Agile experts. However, I’m passionate about launching software products and I find it fascinating how Agile has become such a concern for Product Management, Marketing and Sales. For years Product Management, Marketing and Sales have complained that Development can’t deliver products on time with the right mix of capabilities. I’ve lived on every side of that problem and it’s never enjoyable to be on the Development side of the discussion when promised features are missing.
Now Development steps up to the plate and embraces a way to get things done faster, with more completeness and higher quality, and the triumvirate has heartburn. I’ve been talking with people in Product Management, Marketing, and Sales whose Development teams have embraced Agile (with varying degrees) and many are freaking out. The more I dig into it the less I see where there’s a problem. Let me explain further. Product Management is responsible for identifying Market Problems and developing Market Requirements. We’ve been teaching that for 15 years at Pragmatic Institute – nothing new here. Development translates the Market Requirements into a product. Check. Product Marketing drives the launch process, develops sales tools, trains the Sales team and coordinates with Marketing Communications to develop marketing programs to support Launch goals. Check. The Launch comes and the Sales Team does their thing. Check. Where everyone outside of Development is getting all hung up is with predictability.
But they’ve grown accustomed to what I believe to be a false sense of predictability. That big, monolithic, waterfall documentation that defines all the features that will be in the next release becomes obsolete just about as fast as you hit “save”. Assumptions about what is possible will change. Whether you like it or not there’s never enough time to go back and change the original product requirement docs because there’s a date that needs to be hit. With Agile development methods, Development focuses on short iterations. Each iteration produces 100% of something (coded, tested and ready to go). If you’ve decided that the best time to launch the next release is October, work backwards through the iteration schedule and choose an iteration that will be completed prior to the Launch planning window. This will be the iteration you can trust to be completed. But realize that you may not know the exact release content until the iteration is complete.
Even better though, you will see evidence that the release content is done. Here’s where I’m going to ask the folks in Marketing to be a little flexible. During the Launch planning and readiness window Development will continue to plow ahead and work on more iterations. As each iteration completes, you need to ask yourself if there are features in those iterations that justify inclusion in the Launch without negatively impacting the Launch date. Here’s the deal. If you’re a Product Manager, make sure you’re doing your job and keep feeding Development with what needs to be done next. If you don’t they’ll just start creating what they think is cool, whether it has any marketability or not. Development, you don’t get to decide when a release is ready to Launch. That’s a decision for Product Management.
Acknowledge that Marketing and Sales need a longer window to plan and ready the rest of the organization than a few weeks. They have a limited capacity to absorb rapid releases. All those great features you’re building will just get buried. Marketing continue what you’re doing. Your world is one of dates and timing. Release dates still matter. A product launch is about generating sales velocity and you need enough time to plan for an effective Launch. Here’s a link to the webinar for more on this topic.
