Magical Thinking and the Zero-Sum Roadmap

Richard Mironov -

Recent conversations at several clients highlight an often-repeated set of magical thinking: beliefs by internal clients that development resources are infinite, and beliefs by product managers that prioritization can convince anyone otherwise. Both are wrong, but seductive. Here goes…

The starting point for this conversation is the typical product roadmap: crammed full of prioritized work and heavily negotiated with the development team. Almost every optional item has been postponed, and there’s still some risk of delay. This is a product plan with no “white space,” no large chunks of unallocated engineering capacity, no slop or slush funds or hidden treasure.That gives us Mironov’s Roadmap Theorem #1: you can’t put something new into the current development plan without taking out something of equal or larger size. When stated this plainly, it should be as obvious as the law of gravity. Hand slapped against forehead. Doh!

(Agile translation: “this backlog is very deep, already prioritized, and all of the upcoming iterations are strategic. New items can’t jump to the top without pushing something down that’s more critical.”)

But internal customers (Marketing, Sales, Support, Channels, executive staff) always approach this with some form of disbelief or negotiating position or magical thinking: that 10 pounds of development can fit into a 5 pound iteration. I’ve heard all of these in the last week:

  • “But it’s really important.”
  • “We already promised it to a customer. (Oops)”
  • “We’ve been talking about this for more than a year (so we *must* have assigned resources to get it done).”
  • “Engineering should be more productive.”
  • “We’ve gone agile (which should give us infinite capacity).”
  • “Your priorities must be wrong.”
  • “How hard could it be? A tiny fix, a few lines of code.”
  • “It’s small enough to fit into one iteration.”
  • “I’m sure your boss agrees how important this is.”

All of these are valid in an emotional sense. Many represent good negotiating positions, assuming that product management is hiding extra engineering capacity under a basket somewhere. That we assign resources based on the most inventive requests. That “asking” immediately translates into “getting.” That a convincing argument creates technical resources.

Would that it were so. See theorem #1 above, though. Product managers know that the list of demands is infinite, and the vast majority will never be addressed.

Here are two kinds of product management responses:

[1] Soft-pedaling the actual situation, avoiding conflict by being polite.

We often respond to requests with coded language, mush and euphemisms. Instead of clear communication (“there’s no way this will get done in 2010” or “we have decent work-arounds” or “that channel partner doesn’t rate special treatment”), we waffle with:

  • “I need to prioritize that against the plan (and hope you forget it later)”
  • “Let me run that past engineering (who will tell me it’s huge)”
  • “It’s in the backlog (which will take decades to work through)”

FYI, our internal counterparts are smart. They quickly figure out if our kissy noises are just air, or if we really mean what we say.

Another approach…

[2] We keep some overflow engineering capacity for emergencies.

This looks like a better approach, since surprises and disasters always appear. We can secretly conspire with development managers to pad schedules, or explicitly set aside 10-15% of engineering time for unplanned items. Seems only prudent.

Which brings us to Mironov’s Roadmap Theorem #2: Everyone will find out about your emergency capacity. There are no secrets. In practice, that means all of the above arguments are suddenly very valid. Every sales rep has a strategic account, every unauthorized commitment must be met, and every channel partner has special needs. This puts product managers squarely back into the political process: deciding which arguments rate serious consideration.

Emergency set-asides have the potential to derail your entire product planning process. As “specials” and “one-offs” consume more and more engineering resources, your long-term projects get less attention. (Don’t ever go above 20%.) Your constituents may decide that emergency requests are the only route to satisfaction. If that happens, your roadmap becomes a quarterly CYA exercise.

Sound Byte

Our internal customers are not interested in why their requests are low-priority, only in how they can get things addressed sooner. Clear communication about what’s really important, together with solid roadmaps and carefully managed overflow capacity, can ease the pain a little.