Working Late

Does anyone else work better late at night? It may seem cool, but trust me, it sucks. Especially when you have to still get up with the rest of the World.

I work really well / do my best work late into the night, but when that alarm goes off at 6:30 regardless, man does it suck. My wife has to practically yell in my ear to get outta bed — and that’s no fun for either of us.

I’m still working on trying to come up with a good compromise, but have yet to find one. I hate going to bed for some reason, as I hate sleep, but I just can’t wake-up when I need to.

Ahh, paradoxes galore. Yummy. I’m off to Demmx tomorrow if anyone is reading / going / whatever.

Roadmaps & Communication

I like creating roadmaps. Maybe it’s because I like planning to much.

There’s just something so rewarding to me about charting out where a product / products are going for the next couple of month / quarters. Now that we are closing in on the end of the year, I’m taking some steps back and evaluating where some things are going to go. It’s a fun exercise.

However, at the end of the day, even thought I love creating and sharing this type of stuff because it gets me excited, I’m still cautious to make sure that right knowledge is communicated in the right way to the appropriate people.

In a start-up, your plan will be one thing one day and something completely different the next. This is what makes them cool and exciting, but it can make product management quite difficult, since much of the job relies on working within the market & with customers and charting priorities based on the data you gather.

But, in start-up land you can’t ignore innovation & ideas - especially when you have fast release cycles, or lack of market data due to lack of users. I’ve found a good method when it comes to roadmapping in an environment like this is to write things out the way you would regardless, even if you know some thing will change tomorrow.

Doing it this way ensures that you have your head around where you want to take the product, and then you can present more easily to management, and others.

Back to the point on communication — much of what a product manager is dealing with is in unformed thoughts, especially when working with 4+ products. It’s not a matter of “hiding” data or information from people. A lot of PM’s will phrase things this way - especially when talking about Sales. I used to as well, but seem to be turning some kind of corner in my head.

The way I’m thinking about it is, everyone needs to eventually get the stuff you are working on, but it’s up to the PM to decide how that stuff is distributed most effectively for the team. This means that it’s not effective or productive to talk to Marketing about how long a feature you’re thinking about will take simply because that’s the realm of development. To follow that example though, it’s only when you know how long that feature will take AND how it relates to the larger product plan does it affect product marketing plans.

In the same token, Sales is not affected by things like, “we’re shooting to release 1.5 on the 15th of January” when it’s only February of the preceding year. Arguably, no one is affected by that type of information. However, it helps me to plan that way so I can see where things sit on a calendar and if we are crunching too much into too little time.

Again, to follow that example through, Sales would find information more valuable in the form of, “we’re looking to release 1.5 in Q1 of 07″ — and then when it gets down closer, you drop another layer of, “end of January”, and then eventually, “January 15th.” However, in a start-up environment, v1.5 probably wouldn’t be seen at all, as the product could be dropped halfway through a dev cycle to work on v1.0 of something else entirely.

Again, this is what makes them great.

This isn’t HIDING detail or information. This is forming a thought in as complete a way as possible. To me, this is centrally important especially when it comes to planning and strategizing. It’s much more effective to discuss a strategy or a roadmap once it’s fully formed in your head.

Share things with those that are working on it / contributing to it directly, because “slam dunks” are bad too, but everyone is going to benefit from having something more fully formed than they will getting tidbits of half-assed / half-worked thoughts.

Casino Royale = Good Movie

I haven’t seen most of the recent James Bond movies. I grew up watching them as a kid, when my Dad would put them on TV and we’d sit down and turn up the volume really loud on his surround sound system and enjoy the action.

I admit, my favorite Bond does buck the trend. I really enjoyed Roger Moore in the title role. I always liked the way he delivered the one-liners, and some of the movies he was in were my favorites: The Spy Who Loved Me, The Man with the Golden Gun, and so forth.

However, just as Christian Bale did earlier last year with Batman Begins, Daniel Craig made his Bond much darker and truer to Ian Fleming’s original mold. I like it when this happens, when it’s supposed to happen. Clearly, a darker version of American Pie where Jim is a brooding, on the line of the law super-agent / super hero may not be the best way to re-boot a franchise of that type.

My point is, I really enjoy it when I know that I’m watching a movie that is close / very true to how the original creator intended. Batman wasn’t meant to have nipples, and James Bond wasn’t meant to overpower an actual story with bright flashes and loud bangs.

Casino Royale is a great movie, and I’m told by a bigger Bond aficionado than myself that he has placed Daniel Craig right above Pierce Brosnan on his list (under Sean Connery of course), and that’s good enough for me. I can’t wait for the next one to arrive.

Watching TV on Your Lap

There’s just something so cool about watching TV on your lap. In addition to getting my new Macbook Pro this week, I also found out that SlingMedia (the makers of SlingBox) release the beta client for OS X. Sweet!

There’s nothing better than watching David Letterman guess what kind of pies his mother made for Thanksgiving. I wish that everyone could have as great of a first American Thanksgiving experience as I did.

To all those wondering what the different is between Canadian and American thanksgiving, I don’t think there’s much. I’d say sports, but The Leafs weren’t even playing tonight, and there’s a whole slew of NFL football thats available.

And for all those thinking about how cold it is — trust me, it could be much colder. You could be in Antarctica.

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.

Next Page →