Using a Product Radar vs. a Product Roadmap

Inspired by ThoughtWorks Tech Radar, I find the Product Radar is a great way to visualise and communicate your product strategy and roadmap priorities at a high level, without tying it to a linear roadmap or timeline.

What is a Product Radar?

Like on a ship, "blips" nearest the centre of the radar are the "hottest" and most important. These are the core, critical features that are either already being worked on or are next on your roadmap. If you're building a Minimum Viable Product (MVP), these will be in it.

The next circle contains ideas that are under serious consideration and will be up next, unless there are significant changes in the market or competitive landscape.

What's great about the product radar though, is that it doesn't specify the exact order in which initiatives will be tackled, leaving that open for further discussion with the relevant stakeholders and engineers when the last responsible moment comes to make that decision. See my post on just-in-time analysis to find out more about when that might be.

You can have 2 or 3 inner circles but the outer circle is reserved for items not currently under consideration e.g. because they are too new and unproven or of insufficient value right now.

The ThoughtWorks Tech Radar uses quadrants to categorise items under 'Tools', 'Platforms', 'Techniques' and 'Languages', which might be useful if you're applying it to your whole product or tech team, but I find it adds too much complexity for this purpose, since not all quadrants are likely to contain an equal number of items, making some "squashed" and others too sparse. I do however like to colour-code items e.g. to indicate to which persona they relate and tend to locate items of a similar theme in general proximity to each other.

In the fictitious example below, I use blue for business / admin facing features, green for end-user items and purple for internal initiatives. Red indicates that the item is not up for consideration right now and is currently in the "cold" grey zone.

Fictitious example of a Product Radar

What are the benefits of a Product Radar vs. a Product Roadmap?

It may sound like a "cop out" to avoid committing to estimates or deadlines but most Agile practitioners agree a product roadmap should only be defined in detail up to a maximum of 3 months. The radar however offers a snapshot of your current priorities, perhaps for the next 3-6 months, or even up to 2 years, with the caveat that it is always subject to change.

In the same way the "blips" on a ship's radar constantly shift, according to the location of other vessels, items on the product radar will also move according to market need, user feedback, competitor activity, etc. What it does do, though, is illustrate a clear direction of travel, in the absence of any internal or external forces, based on what you know right now.

This has a number of benefits in that it:

1. Makes a great starting point for high-level prioritisation discussions with senior stakeholders; allowing items to be considered purely in terms of business value, without getting bogged down in the precise order of play, or how long they will take to build. That can come later, once the value to the business has been established.

2. Gives a transparent view of where initiatives sit in terms of relative priority to others. This can act as a catalyst for an important conversation if a stakeholder feels strongly that an item has been placed in the wrong circle, or hasn't been included at all.

3. Demonstrates to any cynics in your organisation that you have a plan beyond the next 3 months and are not hiding behind Agile as an excuse to not think long-term.

4. Shows an awareness of new trends and technologies, even if you don't want to adopt them right now. Just be prepared to justify your decision!

When should I use a Product Radar?

A Product Radar can be used throughout your product lifecycle.

1. During discovery, as it gives participants freedom to propose ideas even if they don't necessarily think they're high priority or actionable right now.

2. To discuss and validate your own strategy and prioritisation calls with stakeholders.

3. To communicate your product strategy to the wider business and invite feedback.

4. As an interactive tool, where others can add items and comments as they see fit.

The most important thing is that it is kept "alive" by being highly visible and updated regularly.

When shouldn't I use a Product Radar?

The Product Radar is a helicopter view of your current priorities, not a substitute for a Product Backlog.

See my post below on Just-in-Time Analysis, where I explain how and when I believe Product Radar items should be added to the Product Backlog and watch this space for an upcoming post on prioritisation techniques, where I will describe how to prioritise items within each of those concentric circles.

Thanks for reading!