Thinking roadmaps differently

I’ve never enjoyed product roadmaps that are constrained to a timebox. Here’s why:

- Motivates for scopes that fit the timebox. Less effort on planning if we “fill it up”. What if we could solve the problem in less time?
- Demotivates continuous problem solving, because success = delivering on time.
- Optimizes for rigid compromises because “we need to show management the plan”. What if I discover something with more potential midway?

If this is happening to you and you have management buy in to not have a time-locked roadmap, try mapping initiatives like this:

- Discovering
- Designing
- Developing

Discovering is defined by exploring a problem, the mechanics that influence it, and what opportunities lie ahead. There is enough degree of confidence that value will be created if the problem is solved.

Designing is defined by active discovery of what the solution could look like. There is high confidence that “something” is necessary. Designing isn’t just “product design”. Creating rules for a process or documenting steps of a service are actions in the design phase.

Developing is defined by delivery and execution. There is a high degree of confidence in the roll out of a solution, whether in the form of feature, process or service.

Every role in the squad (PM, PD, Eng, etc) has work to be done in every stage for all initiatives. Of course, this format needs 1) a general mindset of “build smaller, ship faster, learn sooner”, 2) trust by management that the team will deliver in the shortest timeframes.

I’m yet to see a customer-first reason for a timebox as a better way to build products, apart from appeasing managers.