Aggregate Releases

There are many different ways to release a product. First, I prefer not to use the word “ship”, and only ever do out of necessity. It’s a lagging term that harkens back to the days of software coming off a production line, having been pressed by some a “gold” CD and is all boxed up in shiny, shrinkwrapped packaging.

Blech. Boring.

I much prefer where we’re at in Web software today. Freakin’ awesome stuff going out all the time, and being released faster than you can get your VP’s and CEO’s to the latest trade shows to talk stuff up.

Let me get some stuff out in the open here before diving into the topic of the post. I don’t like long release cycles. I think they suck. I think packing up software (unless absolutely freakin’ necessary) sucks. I think Web applications and thin-layer client products rule. I know they are not everyone’s cup of tea, and that’s cool. Someone has to get things like Vista out the door.

It’s not just because they are becoming more relevent and abound in today’s environment, but I’ve loved them ever since my Dad introduced me to the Sun Ray clients when I was 14 or so. They blew me away, and still do - along with the concept of what they are all about.

So, with all that crap being said, what is this “aggregate release” that I’m talking about in this post’s title? Well, it was to do with a) getting dev stuff done, b) shortening release cycles and c) moving quickly, yet responsibly and effectively.

Typically, a release cycle works as follows:

I don’t like this. I definitely like to think that I’m not just one of those PM’s that talk about being market-driven, but I actually am. This is why I’m a big fan of what I’m calling aggregate releases. They allow you to get of what the market wants out the door more regularly and faster.

OK, OK. I haven’t been around the block long enough to know if this concept exists under some other corporate-fancy sounding name, and was actually called out way long before I evern stumbled across it. So sue me.

Here’s how it works — and this dips into a bunch of other posts that I’ve done on this blog, so bear with me a little here. Stuff like this is sometimes arduous to explain in writing, but it makes way more sense when discussed live.

First off, you need to have a clear picture of your product. The problems it solves, the vision, etc… I covered this previously, and am calling it The Party of Four model, for lack of a cooler name.

After the “discovery” cycle, figure out how the actual product will work by writing stripped-down requirements. I covered this in my previous post, and Scott Sehlhorst was friggin’ awesome enough to give a different point-of-view on why all those big, thick docs exist for our brother & sister companies that don’t have the advantage of only being 12-20 people =)

Those two big steps aside, now your vision and requirements are in dev. What next? Well, I like to create a product strategy somewhere in there, but I’ll save that for another post.

Time to get out the sketchpad.

One un-real thing I’ve learned in the past few months was from the Director of PM over at Newsgator. He’s got this awesome post on how the program managers there work thru releases. I ripped them off. I do the same thing. At first, it was met with slight contention, but now, folks are into it. I highly recommend this, even if you’re a Product-wonk like me, and shunned by development. I’m lucky enough that I’m not. Not yet, anyway.

So, now what? Well, typically, the guy running the dev show (in my case, the CTO) says, “gee, I know we’d like to be able to time things to work together, but that’s just going to take longer.” Hells yeah! He’s dead-on, and a genious.

I can’t take credit for this concept — it was all the resident guru I work with (read: CTO). But, that being said, a light went off and I got it right away.

Just as the Grillin’ in the Storm blog above shows FEATURES / key points, I’ve got MILESTONES. This I also covered a while ago thanks to one of my best friends (another genious), Cory. So, while features may make their way on to the sketchpad O’ release, think of them as milestones.

OK, I hope everyone is still with me. If you are, kudos.

So, you have your product model, you have your requirements, and you have your sketch pad. Now what? How does this “aggregate release” term apply?

The “release” is not actually complete (i.e., you cannot move on to the next version, sketch pad hanging on the wall, etc…) until all of the milestones are met in full.

That’s it. You assign dates to milestone completion. The last one is the “release date.”

How does this help? Here’s an example.

We’re working thru this process right now, in fact. There’s a really key milestone that will be delivered and ties right back into the model / produc strategy I set out earlier (e.g., core pricing model changes). So, the pricing coupled with a flagship feature is written up as a press release by marketing.

So, do we have to wait for other milestones in the release to be complete to do PR for it? Nope. Pick the milestone that works best, and just get ‘er done. Yes, there will be crosses / overlaps in certain things getting done, and marketing and other activities happening. But, I gots news — this happens regardless. There is no such thing a perfect release cycle.

So, put down your protractors and yard sticks trying to figure out when the moon will be waxing crescent before you can release v1.4a.22278.AGH. Just break it out into milestones and go from there.

Does this sound crazy? It did to me the first time I really thought about it. But it offers so much more flex in the process, so long as you can keep folks together in a tight group, and along for the ride. If something comes unwound, it’s easy to go way off track with this and not get things done in a seemingly cohesive / appropriate manner.

Wow, this is a long damn post. I’ll have to cover the potential pitfalls another time. It’s getting late, and I have some milestones to hit tonight.

Nov 17, 06 | Filed Under Product Management

 

Comments

2 Responses to “Aggregate Releases”

  1. Slava Says:
    November 29th, 2006 at 8:59 pm

    Love this post. When the hell are you gonna gather up all these ideas and publish your complete theory of Product Management?

  2. Adam Bullied Says:
    November 30th, 2006 at 12:39 am

    Haha — well, I don’t know if I’m quite qualified. There are folks that are much better PM’s than I’ll ever be out there that should get books first. Roger Cauvin, Scott Sehlhorst, Steve Johnson, etc…

    But, that being said, I truly appreciate the compliment. I’m glad that the content makes sense and can help! If you end up using any of the concepts, I’d love to know how they work out…

Leave a Reply