Roadmap Process or Roadmap Results?

Richard Mironov -

Listening to concerns from a client about an unsatisfying roadmapping process…  his main issue was wanting a better roadmap: one that showed delivery of more features/releases sooner.

Next time you’re critiquing roadmapping processes (or being critiqued), see if you can sort the complaints into these categories:

  • Absolute priorities (“We agreed that C is more important than D, but D appears ahead of C.”)
  • My priorities (“We agreed that C is more important than D, but I still need D more than C.”)
  • Transparency and information access (“I didn’t know E and F were coming.  Where are the things I’ve been asking for?”)
  • Trust (“Development could/should be more productive.  We gave them the 10 reqs they asked for…”)
  • Timeframes and stability (“It takes us 6 week to get features of that size built, but we get completely re-prioritized every 2 weeks”)
  • Sales urgency (“Yes, I reviewed the roadmap last week, but our hot new prospect needs something special…”)
  • Poor estimation (“We thought G would be easy, but it’s not”)
  • Revenue/business model shortfall (“We must be getting Release 6.2 out sooner, otherwise we’d miss this quarter’s goals”)
  • Lack of review/input (“Tech Support didn’t plan for feature J, and won’t be ready to support it at launch”)
  • Non-participation (“You need to join this customer call, write down what they ask for, and move it to the top of the queue.”)

30 bonus points if you can split these into pure communication issues vs. ability to stick with decisions vs. substantive changes to the actual plan.

100 bonus points if you and someone from across the R&D aisle can laugh about it.  BTW, I hear agile and waterfall organizations say the same things, just with different units of time.