Dual Track Roadmaps

If your roadmap goes out further than a couple of months then those items further out are doing you a disservice. To anyone looking at that roadmap, they look like things that you are definitely going to do. Even worse is the fact that those item have dates against them. This is a piece of work that you have done no discovery on meaning you have next to no confidence in the cost or value of it. That's a pretty scary thing to have sitting on an artefact which could and should be seen by anyone within your organisation. As a Product Owner I don't want anyone, from the CEO to someone in CS, making plans around a piece of work like this.

To avoid this, I could put nothing on my roadmap until I have done some discovery on it. The trouble is, the business wants visibility on the medium term plans of my product. To the uneducated it also looks as though I don't have anything to do after a couple of months time. Not the case!

Alternatively I could front load all of my discovery for the year and then move into delivery with some more confidence. But this is wasteful. Doing discovery on something I know I can't start for 9 month's is not a good idea. Even if my discovery shows that it is a good idea, the factors that make that true might well not be true in 9 month's time.

I believe the solution to all of this is Dual Track roadmaps. These show your two tracks of work: discovery and delivery. Your discovery items are all the same size and they show the time period in which you will spend some time investigating the viability of this idea. No commitment to delivering them. Your delivery items show things which you have done discovery on and are committed to delivering barring exceptional circumstances. After you have done your discovery about a piece of work, it either gets added to the delivery track or goes in the bin.

This gives a clear unambiguous view of your two tracks of work. It means that teams that aren't necessarily exposed to your lean, agile development practices can plan ahead. In addition it makes your developers happy because they are involved in the discovery process rather than getting work handed down to them without the visibility of the why. They also don't see things on the roadmap with crazy dates that some TA or worse, some PO, has plonked on in 6 month's time after sticking their finger in the air. 

See examples attached. Q2_Q3 shows the roadmap of Q2 and Q3. Q3_Q4 shows how that same roadmap looks 3 months later. Feature G turned out to be small and really valuable so that made its way to the front of the queue, whereas feature D went in the bin after discovery suggested it wasn't likely to be a hit with users.