Lies, Damned Lies, and Timelines

tl;dr: Internal and external stakeholders expect to know the plan, and when we give them a plan, we must take care not to convey more certainty than reality merits.

When I hired my yardman, I told him that I needed him to come by every other week. I asked him which day would he come on. My yardman is a smart cookie, though. "Oh, sir, I don't like to say I will come on this day or that, because sometimes there is weather. Instead, let me say that I will come toward the middle of the week if nothing goes wrong. Would you like me to text you if I can't come toward the middle of the week?" I paused and said, "No, Leon, that's not necessary. Thank you for being frank. See you around the middle of the week."

My yardman would make a good product manager or client relationship manager or project manager. He's probably not interested, because he owns his own business and seems to be doing just fine. Part of the reason he's doing fine, I suspect, is because he doesn't make promises that he is unlikely to be able to keep.

Consider the following timeline or roadmap that we might give to a client.

There are a few things to notice about these dates. Firstly, unless the project is small or the team is large and well coordinated, these dates feel ambitious. Moreover, they're close together. Even though the scenario is obviously artificial, the dates are stacked on top of each pretty tightly. If just one date slips, it seems like everything else behind it will necessarily slip.

Sometimes, a project is bound by very tight constraints, and that's just a fact of life. Still, nothing is gained by attempting to convey more certainty than is possible. Imagine the same timeline reworked as follows:

The chief value in a timeline like this one is that it does not convey precision that can't rationally be promised. Of course, if your stakeholders demand more precision and you are confident that you can offer it, go for it.

You've been warned.

Another approach to giving dates is to caveat them carefully. You might just add clear, prominent disclaimers around the timeline that read something like:

All dates are estimates. We will fine-tune dates as we approach them.

The problem with this sort of disclaimer is that nobody really takes them as seriously as they take the dates. That's because we prefer the dates to the disclaimer. It's like telling your kid that they'll get a pony for Christmas, but maybe not. I think it's better not to make a promise than to make it with lots of caveats.

Another tool that you might use is to share a living-document version of the roadmap rather than a snapshot. Here's what I mean. A snapshot will be something like a PDF that is distributed to stakeholders. The problem with this approach is that newcomers to the document will not necessarily know that it is out of date. Even if the document is labeled with a date, newcomers won't have a way of knowing whether the document's promises still relate to reality.

A living-document version, on the other hand, will be something like a shared, collaborative document or spreadsheet, or even better, a web page in a portal. The product management team ideally updates it regularly based on adjustments to the schedule and the document's timestamp updates to reflect latest edits.

Communication is key. Always communicate any changes. If you fail to do this, your stakeholders may think you are being sneaky or that you are trying to gaslight them.

While audiences can still take screenshots or print the document, the single source of truth still remains as a reference. A number of product management tools make this approach feasible, but really, all you need is the ability to share a read-only link to your roadmap. If your teams group user stories into themes and epics, it may be possible to share reporting information from your product development tracking software like Jira or Pivotal Tracker.

There's an added value to sharing past-tense information about what has been accomplished. Doing so allows the PM team to show stakeholders the progress that has been made and then to offer conjectures concerning the future as extrapolations from work accomplished. This approach makes it clear that the future is hazy and that the best predictor of the future is the past. Roadmaps are just no substitute if they are drawn up before the project really got started or hit any complexities or if they are never updated afterwards.

Even people of great integrity sometimes fail to keep a promise because of changes in circumstance that they couldn't have foreseen. If we repeatedly make promises that all our experience tells us we cannot fulfill, we are in a very different situation. In this case, the real act of integrity is to own up to the impossibility of making exact predictions and to negotiate with stakeholders for the latitude needed to deliver real value. Sometimes it's better yet to refuse to get into situations that seem to demand irrational promises; thereby we can avoid the temptation to make crazy promises and then to do insane things to try to keep them.