The tech roadmap should follow the business roadmap
It should be very flexible to changing requirements.
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.
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.
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.
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.
Previous Bug priorities should relate to your ability to collect money
- What you don't build is nearly as important
Because that means you didn't spend time on something that isn't useful.
- High Output Management by Andrew Grove
Very good look at management including lessons how to optimize production that are very relevant
- Only The Paranoid Survive by Andrew Grove
A good look at planning product development
- Options, Not Roadmaps
A very good explanation of this that I wish had existed
- Six Week Cycle
The description of the Basecamp product development lifecycle
Suggest an improvement to this page (email@example.com)