Skip to content

Evolve

How to build a 90-day technology roadmap

A 90-day roadmap is not a wish list with dates: it is a decision about what to do first with the capacity you actually have. This guide explains how to define goals, prioritize, map dependencies, estimate capacity, and review the plan each month.

In this guide
Ninety-day roadmap divided into three months with priority review.

Twenty priorities are no priorities

At planning meetings everyone brings their urgency: sales wants the quote tool, operations wants inventory integrated, management wants the dashboard, and someone remembers the site certificate is expiring. In the end everything gets written down with the same date. Three months later, almost nothing is finished and everything is started.

A 90-day roadmap helps prevent that. Its value is not in the list, but in what you decide to leave out.

Why 90 days

It’s long enough to complete something that matters and short enough that context won’t change completely. It’s not a magic period: if your business moves faster, review monthly; if projects are large, break them into deliveries that fit within the quarter.

Five steps

  1. Goals: write two or three business outcomes you want to move in the quarter, in business language. For example, “respond to quotes within one business day.”
  2. Initiatives: list what could help each goal. Everything goes here.
  3. Prioritization: score each initiative by impact on the goal, effort, and risk of not doing it. Order them.
  4. Dependencies: mark which initiative needs another to be finished, access, a vendor, or a decision.
  5. Capacity: estimate how many real hours your team or vendor has in the quarter, subtracting support, vacations and contingencies. Cut the list where capacity ends.

Prioritize without magic formulas

Simple criteria
CriterionQuestionSuggested scale
ImpactHow much does it move the goal?1 to 3
EffortHow much work does it require?1 to 3
Risk of waitingWhat happens if it’s not done this quarter?1 to 3
DependenciesDoes it depend on something you don’t control?Yes / No

Don’t add the numbers blindly: use them to guide conversation. An initiative with high impact and low effort usually goes first; a high-risk item, such as an expiring certificate or an unsupported version, can be advanced even if it doesn’t move a goal.

Capacity: the step almost everyone skips

If your team has 300 hours in the quarter and the list sums 900, the roadmap has already failed before it starts. Reserve part of capacity for support and contingencies; the proportion depends on your operation, and the best approach is to measure how much was spent on these the previous quarter.

Monthly review

Each month, review what was finished, what is blocked, and whether the goals are still the same. Adjust calmly: moving an initiative to the next quarter is a decision, not a failure. Changing priorities every week is.

Applied example

Limits

A roadmap organizes work but does not guarantee outcomes within a fixed timeframe. Estimates change when complexity is discovered, and goals change when the business does.

Cutoff rules

When the list exceeds capacity, cut using these rules, in order: items that reduce a security or continuity risk come first; then items that unblock other initiatives; then highest impact per effort. Record what’s left out and why.

How to use the downloadable template

  1. Write the goals.
  2. List initiatives with their goal.
  3. Score impact, effort and risk.
  4. Sum hours and compare with capacity.
  5. Update status each month.

Prioritization criteria

Suggested scoring
CriterionQuestionScale
ImpactHow much does it advance the quarter’s goal?1 to 3
EffortHow many hours or weeks does it require?1 to 3, where 3 is low effort
Risk of not doing itWhat happens if it’s postponed?1 to 3
DependenciesDoes it block or is it blocked by another?Yes or No

Complete synthetic example

Synthetic example. A fictional distribution company lists 14 technology initiatives. It defines three goals for the quarter: reduce quote time, stop losing orders via WhatsApp, and secure backups of its billing system.

When scoring, it discards six initiatives that don’t serve any goal and leaves them in the backlog. It calculates capacity: two technical people with 60% of their time available after support, about 290 hours in the quarter. The eight remaining initiatives sum 520 hours. It cuts using the order: first backups (risk), then request logging (unblocks measurement), then the quote template. This leaves 270 hours planned and a 20-hour buffer.

Each month review progress, adjust and record why something moved. At the end of the quarter, unfinished items return to the backlog with their context. Example is illustrative.

Questions for the monthly review

  • What was finished and what result did it have?
  • What was delayed and why?
  • Did an urgent issue appear that displaced planned work?
  • Is each goal still relevant?
  • What do we remove from the plan to make space?

How to know if it worked

  • Each initiative in progress serves a goal.
  • Planned capacity does not exceed available capacity.
  • The monthly review was held and recorded.

Plan for the first four weeks

  1. Week 1: define goals.
  2. Week 2: list and score initiatives.
  3. Week 3: calculate capacity and cut the list.
  4. Week 4: start execution and schedule the first review.

Diagnostics before starting

  • List everything currently in progress, even if it’s not written down.
  • Calculate how many real hours the team spends on support.
  • Ask management for the three business priorities.
Decision scenarios
If your case is…Do this
You have more than ten open initiativesPause the ones that don’t serve a goal.
You don’t have an in-house technical teamPlan using the vendor’s capacity, documented in writing.
There is an open security riskPut it first, even if it’s not flashy.

A second example, in contrast

Synthetic example. A small fictional company has only three initiatives and one part-time technical person. Its roadmap fits on one page: one initiative per month. The difficult part was not prioritizing but protecting that person’s time from daily support. Unlike the first example, the challenge was capacity, not the list. Example is illustrative.

What to do when something fails

  • If an initiative is delayed, decide in the monthly review what to remove.
  • If a goal changes, review the entire plan.
  • If support consumes capacity, record it to adjust the next estimate.

Common mistakes

  • More than three goals.
  • Initiatives without an associated goal.
  • Not subtracting support and contingencies from capacity.
  • Ignoring dependencies with third parties.
  • Not reviewing the plan until the quarter ends.

Checklist

  • No more than three goals.
  • Each initiative has a goal.
  • Capacity adjusted for support.
  • Dependencies marked.
  • Monthly review scheduled.

Bring it to your business

90-Day Technology Roadmap

CSV template to build and review a 90-day technology roadmap: objectives, initiatives, prioritization criteria, dependencies, estimated hours, status and monthly review.

View resource
Who should participate?

The person who decides on the business, the person who does the technical work, and the person who uses the systems. Without all three, prioritization is usually weak.

What do I do with what’s left out?

Leave it in a visible backlog. When you review the next quarter, reprioritize it alongside new items.

What if an urgency appears mid-quarter?

Add it explicitly and remove something of similar size from the plan. If you don’t remove anything, the plan stops being realistic.

Who should approve the roadmap?

The person with authority over budget and priorities, with participation from those who execute.

Authorship and sources

Author: RealStack Team