System Design: Data Models for Roadmap Generation

When people talk about roadmaps, they usually think about features. I think about decisions over time.

Any roadmap generation system, whether human or AI assisted, needs to answer three questions:

What are we optimizing for right now?

What constraints exist?

What signals tell us if we are wrong?

From a system design perspective, I think about roadmaps as a data problem before it's a UI problem.

At a high level, I model roadmap inputs as:

Goals (outcomes, not features)

Constraints (time, capital, skills, dependencies)

Signals (user feedback, metrics, external events)

These inputs feed into a prioritization layer that evaluates tradeoffs rather than ranks features. This is critical. Ranking assumes certainty. Tradeoffs acknowledge uncertainty.

The output of the system should not be a static roadmap. It should be a living hypothesis that updates as signals change.

I intentionally avoid over optimizing for prediction. Instead, I optimize for adaptability. A roadmap that updates quickly is more valuable than one that is perfectly planned.

The biggest design tradeoff is explainability versus sophistication. I bias toward explainability, especially in early stage products. If users don't understand why priorities shift, they stop trusting the system.

In practice, good roadmap systems don't remove human judgment. They augment it with structure.