Saturday, February 11, 2012

Why I Discourage Roadmaps

Invoking the image of the greatest orators of all time, every month I would gather the stakeholders together and eloquently guide everyone through the product roadmap: the vision of our product and how we would execute it.

It was glorious....

...wait...what am I talking about??!! Our monthly roadmap discussions were a NIGHTMARE. All that tension, haggling, posturing, politics… So about 7 months ago, I axed roadmapping. Looking back, it was such a waste of
time money. Whenever we'd get together, we'd spend about an hour or two to 'update' it. The most absurd part would be discussing what we'd be doing in a year.

A year in the technology world might as well be an age.

Road mapping comes to mind today because I've been reading a lot about Product Managers working on their roadmaps, techniques and tools. It's also on my mind due to a recent discussion I had with about 40-50 product managers. The moderator kicked off the discussion with a 2 part question: 'Do you have a roadmap and how often do you update it?'

Think about that question. Doesn't it strike anyone else as odd?

Before Exploring That, A Digression....

Ever read Heidegger's 'Building Dwelling Thinking' (Bauen Wohnen Denken)? If you have, then you'll remember him writing about why structures should have particular characteristics. I'll illustrate his point by asking you visualize a door which you'd find in any building. 99% of doors are the same - about 2 feet wide and 7 feet tall. Ever really think why? Doors have this particular shape because most humans are about 2 feet wide and under 5-7 feet tall. When you apply this concept to architecture in general, you'll see that buildings are generally predictable in their design and have lots of prerequisites. For example, no one is going to commission a 10 story, circle shaped building made out of putty with doors that are 2 feet high. Besides being technically impossible, no one would enjoy living or working there.

This is very important because many (most) software products are planned as if they were creating buildings. When a building is planned, you have very precise architecture plans (i.e. the software equivalent of a Roadmap) and you follow it exactly. You can do this because:

1) We've been making buildings for 1000's of years and know 99% of the do's & dont's.
2) Architecture has many, many prerequisites and properties that simply cannot be changed (remember Heidegger and the shape of doors).
3) There's no need (or possibility) to respond to market conditions while the building is going up. When you're building the new World Trade center, you're not going to change the design halfway through because a competitor has unexpectedly changed the game of architecture.

When it comes to software, NONE of those are true.

1) We've barely been making software. Something as 'simple' as estimations on effort are rarely accurate.
2) The limits of what software can do is only growing and there are little to no prerequisites.
3) The market is only getting more competitive and more volatile - long term plans quickly become obsolete.

Getting back to that question I mentioned before: "Do you have a roadmap and how often do you update it?". I'll offer a translation for you: "After you plan your Roadmap, how quickly is it so wrong that you have to change it?"

Does that sound more like it?
Exceptions and 'What Then?'

Of course exceptions do exist and I'll be explicit of the context. I'm not talking about a process where there is some combination of hardware-software dependencies (Apple) or platform unification (Google combining all their services together).

Next, if I advocate getting rid of 'Roadmaping', what then? What does the planning and communication look like?

When it comes to communications and planning, that's where the job and art of being a Product Manager lies. If you just do a bunch of research, pour it into a document and then mold it into a plan, you are failing your customers and your team. If your customers are telling you they 'need a button here' don't turn around and tell the rest of the team that. Instead engage the customer and on your own determine the best experience for them. When you've formulated that into a problem to solve, present that problem to your team along with proposed solutions. Just keep in mind that your proposed solution might not be the best. Someone on your team might do better. Remember, everyone on your team (Marketing, QA, Designers and Developers) is also a problem solver.

At the very heart of it, Product Management is about finding the right problems to solve and what the solutions feel like - not what the solutions are.

Don't give your team a 'Roadmap' filled with solutions. Instead, present a collection of experiences to be realized and problems to be solved. Some problems are small (short term) some are large (long term). It's then up to you to facilitate this conversation,  make it productive and help everyone understand how it's all related.

[Update 02.17.12: I just found out that 37signals had a similar idea. The author approaches it as more of a overselling & 'it's just guess work' problem.]