My 3-Step System to Build a Technical Roadmap in 2 Weeks
(Even If You Start With Chaos)
So we talked about vision, and now let’s put it in practice. One major item that connects to vision is the team technical roadmap.
“But that’s not my job,” you might ask.
You are absolutely right. It isn’t your job if you are not a Tech Lead or an Engineering Manager.
However, you don’t have to be one to start it. Don’t wait. Start now, as a developer.
If your team already has a technical roadmap, use the system in this post and analyze whether the roadmap includes all the important details.
Technical Roadmap is Your Team’s Lighthouse
A technical roadmap typically is a list that includes:
Goals
Priority
Category
Impact / Risks if we don’t do it
Here’s what it usually looks like as a table:
It can also include other parts like:
Team’s goal for the next year
How is the roadmap connects to the division or company’s roadmap
Timeline & Gantt chart
Etc.
However, we’ll focus on building a list for now.
The 3-step system: GPU
So how do we actually build a technical roadmap?
That’s where the GPU system comes in. GPU stands for:
Gather inputs
Prioritize
Use it
It’s intentionally simple because the goal is to create enough clarity for everyone to move in the same direction.
Let’s break it down.
#Step 1: Gather Inputs
At the start, you want to talk to people:
Take Business Inputs
Talk to your Product Managers or business partners. Ask them:
What are we building in the next 3-6 months?
Are there any major changes coming?
Any pain points for them to using the software?
Take Engineering Team Inputs
Your members know what’s broken. They deal with it every day.
Ask them:
What slows you down the most?
What part of the system do you want to improve?
You can do this in 1-on-1s, team retrospectives, or a quick survey. Ask everyone, both senior and junior engineers.
Take Data Inputs
And then you look at the data:
Common incident causes
Recurring issues and bugs
What has been sitting there in the task backlog (E.g, Jira)
At the end of this step, you should have a messy list of 10-30 items.
You don’t judge anything yet. You just collect.
#Step 2: Prioritize
This is where your vision skill starts to come in.
Time to turn that chaos into a roadmap.
Add Categories to Items
There should be one category for each item.
If an item cannot be associated with anything, start thinking whether it needs to stay on the roadmap. It’s either a business feature, or it is not worth doing.
Here are the categories that I usually use:
Security: framework & package upgrade, PII handling, legal compliance, etc.
Maintainability: code refactoring, breaking down a monolith app, etc.
Performance/Scalability: API latency, page loading speed, etc.
Stability/Availability: Service downtime, disaster recovery, etc.
Cost reduction: infra, DB usage, logging storage etc.
Add Other Details
Each item should include the following:
Impact: What benefits does it bring to the team, or what if we don’t do it.
Goal: What does the finished state look like.
Priority: Translate the impact and urgency level to priority.
Effort required: Using T-shirt size like L, M, S to represent how complex the solution is.
Note: If you are experienced with this process, you can complete it along with step 1 where you talk to the PM or the team.
#Step 3: Use It
Once you have a roadmap, it becomes your decision-making tool.
Use it in your day-to-day discussions like the following.
Push Back on Requests
Once you have a roadmap, not everything looks “important” and “urgent” anymore.
Next time someone asks your team to do something, you know whether the request is important compared with items already on the roadmap. (even if it’s always “urgent”).
Align Directions
You might find people optimize or refactor small things that they think are important, but they are not.
Run a meeting to go through the roadmap with the team. Use it to decide what they should work on first. Those small things can wait until we finish all the main projects.
Fill Windows
When you have a free week, you don’t wonder what to work on. You check the roadmap and pick the next important item.
Without a roadmap, teams usually don’t know what to do during planning sessions when they discover they need to wait for the next business project.
Common Roadmap Mistakes
Making It Too Detailed
A roadmap is not a backlog. It’s a direction. If you have a big team, don’t squeeze all items onto the roadmap.
Only leave the important items. Most small items can stay on your task backlog like on Jira or Asana.
Only One or Two People Contribute
A technical roadmap is built by the entire team. Either one PM defines everything or the EM writes it alone. Neither works.
The step 1 of the GPU framework should not be skipped.
No Regular Review
Business priorities change. Tasks get done. It’s impossible to use the same roadmap forever.
I recommend reviewing it every three months. Adjust priorities, remove finished items, and ask people again about their pain points.
Start Building One Today!
You can build a simple roadmap today and use it in your meetings.
Even if your team already has one, use the GPU system to evaluate whether it misses important information.
If you want a shortcut, I’ve created a ready-to-use Technical Roadmap Template that follows the same structure from this post.
You can grab it here!
What I’ve Read This Week
Your Code Doesn’t Need to Be Perfect. It Needs to Ship by
Freedom by Design: How He Lived in 5 Countries and Built the Free Visa Tool He Wished Existed by
andThe Future of API Design: Migration Strategies by
Big Tech leaders are turning leadership into a fad by
Thank you for reading the post!
❤️ Click the like button if you like this article.
🔁 Share this post to help others find it.
As always, I’ll see you in the next post. Have a nice day!
Adler from Tokyo Tech Lead