Building a Product Roadmap

What is a Product Roadmap?

A product roadmap is a shared, visual summary of where a product is headed and why. It connects the product strategy (the big goals) to the day-to-day work of engineering and design, and it gives leadership, sales, and support a way to see what is coming without reading every ticket.

A roadmap is not a project plan. A project plan lists exact tasks and deadlines. A roadmap communicates direction, priority, and rough timing -- and it should change as the team learns more. If your roadmap never changes, it usually means nobody is actually using the data coming in from users.

---

Types of Roadmaps

1. Timeline (Gantt-style) Roadmap

Shows features against specific dates or quarters. Easy for leadership to read, but dangerous: it implies certainty that rarely exists in product work. Best used for hard external deadlines, such as a regulatory change (e.g. a new CBN directive on transaction limits that Access Bank must comply with by a fixed date).

2. Now-Next-Later Roadmap

Groups work into three horizons instead of fixed dates:

• Now -- actively being built this sprint/cycle
• Next -- planned for the near future, scoped but not started
• Later -- directionally likely, not yet detailed

This format, popularised by companies like Basecamp and widely used by teams at Spotify, protects the team from over-promising exact dates while still communicating priority.

3. Theme-Based Roadmap

Organised around strategic themes or outcomes (e.g. "Reduce checkout drop-off," "Expand into francophone West Africa") rather than a list of features. Forces the roadmap to stay tied to goals instead of becoming a wish list, and gives engineers room to find the best solution to the theme rather than being handed a pre-decided feature.

4. Release-Based Roadmap

Organised around version numbers or release trains (v2.4, v2.5). Common for enterprise software and regulated products where releases go through formal QA and compliance sign-off, such as core banking software used by GTBank or Access Bank.

---

What Belongs on a Roadmap

A roadmap that lists 40 individual features with exact ship dates is not a strategy document -- it is a to-do list wearing a strategy costume, and it will be wrong within a month.

---

Roadmapping Tools

Many African startups -- including early-stage fintechs before they scale to enterprise tooling -- start with a simple Notion board or even a shared spreadsheet, and graduate to Productboard or Aha! as the team and stakeholder count grow. The tool matters far less than the discipline of keeping the roadmap tied to strategy and revisiting it regularly.

---

Communicating the Roadmap to Different Audiences

The same roadmap often needs to be presented differently:

• Engineering wants to know sequencing, dependencies, and technical constraints.
• Sales wants to know what they can promise (carefully!) to prospects and by roughly when.
• Leadership/board wants to see how the roadmap ties to company goals and revenue.
• Customers (if shared externally) want reassurance that their pain points are being addressed, without granular internal detail.

A common mistake is showing sales and customers the same detailed, date-heavy roadmap used internally with engineering -- this creates promises the team cannot keep. Konga and Jumia, for example, keep public-facing "what's new" pages separate from their internal engineering roadmaps for exactly this reason.

---

Keeping the Roadmap Alive

A roadmap is a living document, not a one-time deliverable:

1. Revisit quarterly (at minimum) as new data, competitor moves, and customer feedback arrive.
2. Re-prioritise openly -- explain why something moved, rather than silently reshuffling.
3. Track confidence, not just content -- mark "Now" items as high confidence and "Later" items as directional.
4. Tie every item back to strategy -- if an item cannot be justified against a strategic goal, question why it is on the roadmap at all.