Tech roadmap might be treated independently of the business

The tech roadmap can sometimes diverge from the business roadmap. The business priorities might change, but the tech roadmap might not be adjusted. Even worse, the existing roadmap might be made to look as if it’s supporting the business direction.

Which might make you build the wrong things

For instance, you might have planned on building supplier self-registration. Before building it, however, reducing the operational reload was revised to be of higher priority. You can reconsider what would most effectively serve that goal, or you could justify building this feature by saying that having the suppliers register themselves also reduces operational workload.

If the two roadmaps drift out of sync, you will actively build the wrong things. And if you try to force the new objectives on the existing roadmap, you will build suboptimal things.

Instead, the roadmap should be short-term and have few items

Short-term

The key is for the tech roadmap to be only short-term. You might take note of features you might want to build down the line, but you shouldn’t commit to them or schedule them.

Basecamp, for instance, doesn’t do anything beyond six weeks. For early-stage startups, I think this is a good rule of thumb.

Few items

Secondly, the roadmap should only have a few items. It should be a long queue. Effort spent on designing everything in the queue is a waste unless you build those features immediately.

If anything has been in the queue for longer than a couple of months, it means you don’t need it now. You should remove it. If you don’t you will constantly try to think of where it could fit.

Bias your prioritization towards initiatives that have an immediate impact instead.