ProductMarketing.com

on roadmaps

I had a funny discussion about roadmaps recently.

Me: If you can't hit your dates, then you shouldn't distribute roadmaps.
Client: But we must distribute a roadmap to sales people.
M: And what happens when you do?
C: They give it to clients.
M: And what happens?
C: They attach the roadmap to a contract.
M: How's that working for you?
C: Well, we usually miss our dates.
M: If you can't hit your dates, then you shouldn't distribute roadmaps.
C: But we must distribute a roadmap to sales people.
M: And what happens when you do?...

In Don’t Build a Stupid Product Roadmap!, Scott Sehlhorst at Tyner Blain writes,

A product roadmap is the product manager’s equivalent of a project manager’s rolling wave planning. In a sound-bite, you provide short-term details (for the next release), and long term “broad brush” discussions. If you don’t plan your product to address the needs of a particular market, and then execute against that plan, the only way you will succeed is by luck.

That's it. A roadmap is a plan, not a commitment. It says, "here are our current plans. Our objectives may change and we'll change our roadmap accordingly."

As they say, If you don't know where you're going, how will you get there?

In our Roadmapping seminar, we provide five different tools for articulating product strategy. The roadmap is evidence that you actually do have a strategy. The roadmap is the tool of choice for communicating with executives, sales people, and clients. And in fact, seeing your product roadmap is often a legitimate request from your clients and your sales people.

However, and I've ranted about this before, things don't change nearly as quickly as everyone thinks. That is, market problems exist for years and years. It's your awareness of those problems that changes day-to-day. I'd prefer that your long-term roadmap focus on industry problems and persona goals. In talking with a client about product capabilities, this client's feature request becomes critical. Talking to another client results in another critical feature request. As you talk about features, you discover the delta between the problem and your current solution. But if product managers actually interviewed the clients instead of just reacting to sales demands, we would see these problems years in the future.

You don't hear problems with your mouth. You need to create an environment where you can hear problems... with your ears open and your mouth closed. Better yet, see the problems by observing your ideal persona in a working experience.

You can observe a lot by watching.--Yogi Berra

on precision

Those who cannot remember the past are condemned to repeat it.-- George Santayana

My mind seems to work in a funny way. A program’s quirk got me thinking about precision.

I tend to be overly organized. I use lots of folders to categorize: office, photos, movies, product management, presentations, humor, and so on. For a while I tried cross posting if you will, putting aliases or shortcuts in one folder pointing to the actual document in another. I think it is rather natural to try to categorize items. I know I should just throw everything in My Documents without any organization and let Google find them for me but I don’t. And invariably I end up with the same document stored in multiple places. I found a great tool for searching for duplicate files: zsDuplicateHunter, available for Macintosh, Windows, and Linux. I’m sure there are others but this is the one that I use. It’s amazing to me how often it finds duplicate files even when I think my computer is clean.

But here’s my point (finally). The program uses unnecessary precision. It tells me that the search has 47.6 seconds remaining. Why is the .6 relevant? For that matter, is 47 seconds relevant or even true? Isn’t “less than a minute” more accurate?

I learned about precision back in public school. 1 divided by 2 is 0.5. Period. In this instance, more decimals are not more accurate. Telling me 0.5000000000000 is both irrelevant and harmful, as it implies a level of precision that is not supported by the data.

I see this error of precision in estimating dates for roadmaps and requirements. A developer guesses a man-week of work, which someone translates to five days, and someone else translates to 40 hours. It shows up on a Gantt chart as 40.0 hours. But a week could be two days if the developer gets in the zone and doesn’t encounter any surprises, or it could be a month if the developer gets pulled into a dozen other problems.

I fear that we have an unrealistic expectation of precision from our project schedules. Compare the precision of development estimates to sales estimates. How precise are the numbers in your sales forecasts? What accounts will you close on what date for what revenue amount? No sales person could provide that information. Yet we somehow expect exactly that from the development schedule.

An old estimating joke is this: take the estimate, add one, and change the unit of measure. One week becomes two months; one month becomes two quarters.

A guess is a guess. Let's not attribute precision where none exists. If we track our history of guesses, we can assign a factor of accuracy. Take a look at estimates of the past to see how accurate they were and use this against your future planning. Don’t infer precision without the data to support it.

Webinar: Building Effective Product Roadmaps with John Milburn

When there is more to do than can be done, how do you direct where resources should be expended? How do you get alignment of strategy, dollars, people, and programs that will result in an effective plan and product roadmap? How do you communicate your plans in a consistent and meaningful way? Learn techniques to align and focus the organization around the market, not just your products. Hear more in Building Effective Product Roadmaps with John Milburn.

Align your product strategy with the market

How do you deliver the right products, not just the most features? Where should you wow the customer? When is "good enough" enough? Find out in the Pragmatic Roadmapping seminar to learn how to achieve success by aligning your product strategy with the market.

Eclipse Roadmap

I don't know if this is a good example but it is an example of a roadmap approach. The Eclipse Roadmap is intended to be a living document which will see future iterations. This document is the first version of the Eclipse Roadmap, so it is labeled as version 1.0.

The Promised Land

Before the testing and bug fixing, before the technical design and product plan, before the business and technical requirements, comes the Product Roadmap. Jacques Murphy describes Product Roadmap to the Promised Land.

Roadmaps

This month's Product Bytes discusses technology product roadmaps. Click here to read the newsletter.

Microsoft's support policy

Want to know Microsoft's support policy for operating systems? Microsoft has published the levels of support for a period of 7 years from general availability. This is a pretty good example of how one does a roadmap. The FAQ states: The Windows Desktop Product Life-Cycle Policy is designed to establish a clear and predictable policy for product support timelines and license availability, to assist customers and partners with managing their support needs, product planning and information technology planning within their organizations based on knowledge of the support timelines for Microsoft products. Search their web site for Product Life-Cycle Policies.