Roadmap elements

This is a write-up of a discussion the UK government’s community of product managers held to agree which elements are important to include in our product or service roadmaps.

We think it’s worth agreeing these elements so that roadmaps are consistent and can be understood across our organisations, regardless of who’s looking and where they are viewed.

The elements are being posted here to invite comments and suggestions before being published as guidance on the Service Manual.

***

A. Products should be judged on their delivery of value to users. Roadmaps are a tool to express what the value of a product will be and how that value will be understood and released in stages.

B. Each product has its own roadmap, or is represented on a roadmap providing a collective view of products related to a service. If user needs call for more than one instance (eg. simultaneously on a wall and one online), every version of the roadmap must be kept in sync.

C. Roadmaps are developed iteratively and regularly. Creation and iteration of a roadmap is a collaborative effort led by the product manager with the delivery team, stakeholders and the product’s users.

D. The roadmap is open and available in the public domain (unless there is a very good security reason not to).

E Roadmaps use simple illustration and plain English to provide information. This makes it easy for anyone to pick up and quickly understand how and why the product is being developed. They tell people where else to go if they need additional in-depth information (such as a product backlog or blog).

F. Roadmaps are framed by a vision explaining the ultimate outcome a product is trying to deliver. The roadmap is broken down into objective-based missions, each of which gets us closer toward achieving the long term vision.

G. Missions are outcome-based objectives with an explanation of what the goal is (often a problem to be solved) and how progress will be measured. Agreeing these missions involves conversations with users, the organisation’s leadership and the team doing the delivery.

H. Missions are mapped over time (eg. quarters). The segments of time on a roadmap are consistent. When the roadmap contains phases (such as discovery or beta) these should be timeboxed.

I. Roadmaps show what’s been done and what is coming next in order of priority. The method of prioritisation is transparent and consistent.

J. Roadmaps enable us to plan for change. They capture intent, not solutions. The further in the future a mission is, the more uncertain it is. The closer the mission gets, the more is learned and the more confident we become that it is the right thing to work on. Things can be dropped from roadmaps.

K. Each roadmap provides an explanation of who it’s for, how to read it, who maintains it, how often it is updated, and how to contribute to its development.

L. When roadmap software is used, the content should be exportable (preferably via API) to enable reuse.

Advertisements

Product Manager or Product Owner?

In government, in practice, they’re synonymous. Because we care more about the responsibilities than titles, right?

But sometimes it’s a thing for some people. They raise it as if to suggest it’s an unresolvable ‘chicken or egg’ type of question. This is how I explain it.

In GDS we use Product Manager.

We don’t think Product Owner is wrong. Product Manager is just more us.

Product Owner is a Scrum thing. Like Scrum Master is a Scrum thing. We like Scrum but it’s not the only method we use. We want the people managing our products to be able to use a range of delivery methods. So using Product Manager is a signal of intent.

Product Owner is a term that’s used less frequently than Product Manager. It makes sense for us to use a title that people relate to when we are trying to attract the highest number of quality candidates to product management jobs in government.

Search trends for ‘Product Manager’ vs ‘Product Owner’
Worldwide results for ‘Product Manager’ jobs on LinkedIn
Worldwide results for ‘Product Owner’ jobs on LinkedIn

Product Manager is used by the majority of government organisations. And when digital, data and technology people from across government got together en masse recently to agree the roles and responsibilities we need to deliver better services, we settled on Product Manager. By saying ‘the majority’, that’s acknowledgement that the agreement is new and taking some time to percolate through.

Where it gets a bit confusing is in a few departments they have Product Owners and Product Managers. In these cases the Product Owners come ‘from the business’ and don’t have product management responsibilities. What they are is subject matter experts, who are very welcome helping delivery teams to understand the policy and operational realities. But we could be doing with calling them something else. Maybe just referring to them by their actual policy or operations role titles. That would make things clearer.

Fundamentally role titles evolve. We should hold onto them loosely to protect against hubris.

What we must spend more time and effort on is making sure that when we configure teams we give people a combination of responsibilities that are compelling and commensal. Google it.