211225

Walked on the beach in the wind and the rain.

Wrote a blog post about public roadmaps.

Did some thinking about plans for next year.

Added my dissertation to my website.

Made a Twitter bot that sends you a little piece of wisdom if you tweet the hashtag ‘MakeMeWise’.

Why you should have a public roadmap

Public roadmaps are used by organisations to show users and customers what they are working on now and in the future. They are a great way to show openness and transparency to build trust with an audience that is interested in their work, and to demonstrate commitment to listening to customers and improving products and services now and in the future.

If a product is a promise of value then a roadmap is a promise of a product increasing in value over time, but customers only gain that value if the roadmap is public.

Why have a public roadmap

A public roadmap is a sign of internet-era thinking and ways of working. Almost more important than what is on it, its existence is an indicator of a modern digital organisation. It shows customers, potential and actual, suppliers and others in the same industry or sector, or in fact anyone interested, that the traditional boundaries between a company and everything outside of it are becoming more porous and that it is a positive thing.

As yet, I haven’t found any example of an organisation making the actual roadmap that they use to prioritise and manage product work public. They all seem to have created separate versions of roadmaps in order to make those public whilst using other internal tools, but its still a step in the right direction.

Some product leaders caution against public roadmaps as revealing to competitors what the organisation is working on, or making commitments to customers that they might not be able to keep. These seem to suggest other issues that organisations need to resolve rather than reasons to not have a public roadmap, but it is important to understand the positives and negatives of a public roadmap before going ahead but then do it anyway.

Benefits of public roadmaps

Clarity

Encourages you to make your roadmap clear enough for a wider audience to understand. Anyone looking at your roadmap should be able to make assumptions about your organisational priorities by the work you have in progress and coming up. This forces you to establish those priorities clearly enough internally in order to express them clearly enough externally.

Commitment

Shows your audience and customers that you are committed to continuing to meet their needs over the long term. Customers wanting a long-term, ongoing relationship with your products can look at a public roadmap showing them how they can get increased value over time to help them decide whether to invest time and money in it.

Community

Builds a community around your products. Only those people who are really interested in the product and its development will be interested in its roadmap. These are your thousand true fans. Nurturing them, understanding what problems they have and how your product solves them better than anything else, will help to keep your product direction true.

Examples of public roadmaps

Github

Organised by what is expected to ship in each quarter, Github uses a Github Project Board (unsurprisingly) for their roadmap. The items are described in technical language but given that Github’s users are technically-minded they are likely to understand what ‘Audit log API on GHAE and GHES’ means, this seems appropriate. Each item on the board can be opened to see more details, including ‘Intended outcome’, which is a nice way of bridging between the timeline view of the board and the outcome-focused drivers of the work. Each item also has labels which are clickable to show all items tagged with, for example, ‘Security and compliance’. A user that has a particular interest in all the features that are related to security and compliance can get a view of all the work Github is doing about that.

Microsoft

Microsoft uses an in-house tool for their public roadmap. Not surprising given the complexity of a single roadmap for displaying information about more than forty products across ten platforms and twelve release phases. The roadmap tool allows users to filter the whole view to see items about specific products and what status that item has; ‘In development’, ‘Rolling out’, or ‘Launched’. The roadmap seems aimed at admin business users of Microsoft products who are responsible to understanding when a new feature is released so their organisation can adopt it, which makes the information in the roadmap more logistical than serving to express the vision and direction of the products.

Buffer

Buffer’s public roadmap uses Trello and includes four columns of ‘Exploring’, ‘In progress’, ‘Done’ and ‘Leaving it for now’. People are allowed to comment and vote on the feature, perhaps as a means of validating the need and prioritising the work. The labels suggest some strategic themes to link work together with users being able to use them to filter the board. Buffer’s use of Trello, a simple tool that most digital knowledge workers will be familiar with, shows that they want to be more transparent with their customers and inform them about the product development work.

RNID

RNID’s public roadmap is organised by quarters and with sections ‘We’re discovering’ and ‘We’re delivering’ in each quarter. The work described is phased as outcomes for people using their products and services, for example ‘People can check their hearing online and find next steps to get support.’ but doesn’t connect that work to strategy, most likely because that isn’t the purpose of the roadmap which seems to be more about showing progress.

GOV.UK

The UK Government’s public roadmap, underpinned by it’s tenth design principle, Make things open: it makes things better, shows work across six programmes and in three columns, ‘Recently shipped’, ‘Working on now’ and ‘Exploring’. The items on the roadmap describe work at a level that would be given to a cross-functional team that would be able to, ‘Design and test a new design for the GOV.UK homepage’, rather than breaking the work down functionally or describing a feature.

Roadmap

Roadmap builds roadmap software, which they also use for their public roadmap. The roadmap section is divided into ‘In progress’, ‘Soon’, and ‘Future’, but also has sections for Launched and Ideas. The tool has functionality to allow customers to vote on features but doesn’t seem to include any detailed information or connect to outcomes or strategy.

Trends in public roadmaps

There are two clear trends in the above examples; tools and text. Four of the examples use a tool for managing and displaying their roadmap which allows viewers some functionality such as filtering. All four of these examples are providing software products so perhaps their audience is more technical and more interested in which features are shipping when. The two text based roadmaps are arguably easier for viewers to read and understand, which fits with the expected (non-technical) audience for a charity or a government.

All of the roadmaps attempt to present a picture of the product work in a ‘past’, ‘present’, ‘future’ way, but don’t seem to tackle the problem of representing the current state of the product. Perhaps that’s just the nature of how we approach roadmaps or perhaps the expectation is that the live product does that itself.

Should you have an open roadmap?

For your organisation? For your projects? For yourself? Yes. Yes. Yes. Public roadmaps are a good thing. They make us consider what we put out into the world, and how others will understand it. They help us think big about what we want to achieve, and act specifically in order to achieve it. They clarify our thinking and show our commitment to making things better.

211224

Wrote up my thinking on all that I’ve learned in my new role this week.

Went for a walk on the beach.

Wrote my weeknotes.

Finished a blog post from November.

Thought about what I want my focus to be in 2022.

Weeknotes #282

This week’s photo:

This week I did:

Starting

It was my first week at RNID. The team is great, the ways of working are great, and the work we’re doing to make life more inclusive for deaf people, those with hearing loss and tinnitus is great. I’m already starting to see where I can add value and am really excited about the work we’ll be doing next year.

Sending

Sent the eighth Irregular Ideas email and got a new subscriber. This edition included my strongly held belief that Dirty Dancing is the greatest movie of all time. No disagreements.

Signing

Completed module 3 of the British Sign Language course. It’s starting to include grammar and sentences which are a bit more challenging than single words, and I need more practice to remember the signs, but I’m enjoying this kind of ‘either you know it or you don’t’ kind of learning.

UDTL

I finished the ultimatedigital.tools landing page and added a few more tools. I’ve got lots waiting to be added so I’m going to make a concerted effort to get through them next week. Still doing a rubbish job of marketing it though.

This week I read:

Charity Digital 2021

Dan Papworth-Smyth shares a few of his favourite charity digital things for 2021. These campaigns

How to Productize Yourself as a Writer

Sahil Lavingia, CEO of Gumroad and writer of the No Meetings, No Deadlines post talks about writing, building, and productizing yourself on the The Digital Writing Podcast.

Never less of an expert

Sam Higham’s thread about the 12 product management lessons he’s learnt so far.

And lots of other stuff on my reading list.

This week I thought about:

Big things vs small things

It’s much easier to do small things that feel like they don’t have many consequences if you didn’t do them than it is to do big things that feel uncertain. I get excited about doing big things but then I focus my time on doing little things, and I’m trying to figure out why. For example, I wanted to explore the idea of the charity of the future as a DAO. It’s a big idea, almost impossible to create anything so its really more of a thought experiment, and no one else is interested in it, but to me it’s exciting and leading edge. And yet I spend much more time writing the Irregular Ideas newsletter which just includes a few quirky little ideas. Why aren’t I focusing one the big uncertain stuff? Is it because its far less tangible, far harder to make it look like there is progress, almost impossible to imagine an end game? I think I need a drastic rethink.

The pace of alignment

For a while I’ve been tweeting about how difficult it is to maintain alignment when the things that are supposed to be aligned move at different speeds, and using videos to illustrate it. This week I learned that there is science behind it. Yeah science! It’s called ‘shearing layers’ and it’s based on the work of ecologists and systems theorists. The idea is that there are processes in nature, which operate in different timescales and as a result there is little or no exchange of information between them. Architects have applied this thinking to buildings and Gartner applied it to software applications in business and trademarked it. I think it can be applied to knowledge work, and product management work specifically as it often has alignment as one of its goals.

True opposites

Another interesting concept I learned about this week is ‘integrative complexity’, which is the technical term for being able to hold multiple perspectives and possibilities at the same time. Typically, when we’re trying to make a group decision we try to get everyone to have the same perspective on the assumption that it’s necessary for agreement. Integrative complexity suggests that not only can a group have different perspectives but individuals can too, and still make good decisions. Opposing perspectives don’t have to be a barrier to decision-making. Good decision-making (another essential aspect of product management) is usually assumed to rely on consensus and shared perspectives (hence all the stakeholder management), but integrative complexity offers a way of approaching decisions that embrace different perspectives.