Entries Tagged 'Roadmaps' ↓

I am starting to kick the tires on a roadmap. I am building an honest-to-goodness roadmap and it feels good it after more than four years of just talking about them.

As I started to think about which features should be in my roadmap, I began to think about what bits of information do I need that would sell my stakeholders that the features are valid. As a side note, I am pushing my roadmap closer to the front of the process and will try to focus it on problems and not features.

So I am throwing this question to you. We talk a lot about collecting facts or evidence before making decisions. I wonder specifically what everyone means by this. I have my own ideas, but I am interested in your thoughts. Please comment below.

If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post.

---

I received another request in my “suggest a post” area (thanks!).

The use of the Product Road Map for internal planning vs in support of the selling process?

I am going to make one assumption that the author of this suggestion is referring to the external sales selling process and not an internal selling process (i.e getting roadmap buy-in).

In my opinion and I think everyone else will agree, having a roadmap for internal planning purposes is not an option. It is mandatory! The roadmap for selling is generally frowned upon.

Roadmap as a Planning Tool

Some of this is rehashed from previous posts, but your roadmap is your strategy. It is your long-term plan for success. It’ll contain the details of your value network, vision and mission statement.

I know, I know. Typically your roadmap is a power-point presentation or a spreadsheet, but it is time to mature that process. Your roadmap should contain descriptions of your partners, your buyer and user personas. It should contain describe your vision and the plan to to achieve that vision. (Unless you are a single product company you will want to provide some additional commentary on how this vision helps the company achieve their vision.) Typically, this plan is described with your release plan for the short term (less than 12 months), a feature plan for the longer term (more than 12 months) and any business development plans. Your mission statement defines your product’s purpose and primary objectives. Its prime function is internal – to define the key measure or measures of the product’s success. I have written in the past about metrics. Everything should be written using a language that shows alignment across your value network, vision and mission.

As you can see, the content is driven from the planning for your product. The nice thing about using a roadmap, is that it allows you to bucket all your strategic thinking into one document.

Roadmap as a Sales Tool

Now despite the comment above that using your roadmap as a sales tool, you will sometimes not have a choice. Prospects may want to see your vision. You’ll need to make everyone aware the risks with showing prospects the roadmap. It could delay the sales cycle if they wait for future features or set poor expectations if they believe the roadmap will not change (and it will change). There is nothing wrong with sharing your vision, but the appropriate expectations need to be set for the Sales team and the prospect.

If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post.

---

I suspect that one of the major impacts to your roadmap is a budget change. And by change, I mean a reduction in available funds for product development. I suspect a lot of you dealt with this last year as you suffered through many rounds in workforce reduction. I am curious how you handled that.

Picture this scenario, late last fall you reviewed all your feature requests, dusted off the roadmap, the business case is shiny again and it is all aligned with your vision and the corporate vision. With your budget approved, you are ready for 2010. Enter January 2010 and due to slightly missing the Q4 numbers you are now forced to chop $75,000 from your budget. Basically the equivalent of one developer. What do you do?

• Band together with the other product lines and pray for Management to realize that chopping 75k is guaranteed to affect more than 75k in revenue this year?
• Offer to combine forces with another product to share revenue (knowing that you will likely never be able to undo this) in hopes that your new increased revenue will offset your requirement to reduce cost?
• Suck it up, chop the developer and leave the roadmap unchanged and modify the business case (i.e. budget) to reflect the reduced cost but leaving the revenue numbers unchanged? The more with less scenario or in this case same with less.
• Suck it up, chop the developer and scale back the roadmap and business case (i.e. budget) to reflect the reduced cost and revenue numbers?

I am less inclined to do anything that will affect revenue for future years. Depending on how many rounds of workforce reduction you have survived, I am less comfortable selling the same with less scenario. If you are in your first or second round, go with that. Teams generally perform better after the first and second cuts. I am not hopeful they will “see the light” and let you keep a full team in hopes of achieving your revenue targets. Although, this is probably the scenario I start with. Sell the vision, sell the facts and get buy-in on the business case. Failing that, cut, reduce and move forward.

I am hopeful someone will share a situation where a budget cut has affected their roadmap and how they responded.

I meant no offense to any development types by suggesting we cut you, it was a just a random example. We really hate cutting our roadmap in any scenario.

If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post.

---