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.
