Tag Archives: stakeholders

The trap of ‘the 18 month roadmap’

Yes, I know what some of you product purists will be thinking. But this isn’t a snarky post about how stakeholders want Gantt charts really. It’s more about how easy it is to become accidentally stupid and switch into ‘feature team’ mode, even if you’ve been doing this for a really long time.

As mentioned two posts ago, I’ve largely handed over my Head of Product role to my Civil Servant successor. They’re doing a great job, and I need to give them the space to do it without feeling overlooked – and to do it the way they need to. I didn’t get everything right, because I was setting up a profession at scale for the first time, and in some places it’s a good opportunity to fix some lumpy corners. Meanwhile, I’m being kept on until the end of December doing what was referred to in the 90s as “special projects” – keeping me busy and around until the end of my contract in case something crops up that needs my memory.

The thing that’s keeping me busy is setting up a new multidisciplinary leadership team that sits across several of our products which were previously a bit siloed.

We’ve got a companies/contacts/interactions/events database platform thing; we’ve got a data analysis/visualisation platform; we’ve got some quite specific workflows around particular types of triage; we’ve got ticketing systems; we’ve got a public-facing platform (great.gov.uk) that does data capture; we’ve got bulk email tools; we’ve got a SaaS event management platform; there’s a suite of marketing tools etc etc. All of these things are part of what you might call “CRM”, but they’re not necessarily seamlessly integrated for our users – and we probably send staff around the houses between teams a bit more than we should when they’re asking us how to get something done. And so sometimes stakeholder say “perhaps we should just go and buy [insert any major CRM vendor here]”.

So we’re creating (for a while) a CRM Leadership function, that’s taking a holistic look at all these journeys – through the lenses of data, design, business, product, architecture etc. We’ve also got a CRM subject matter expert on the team, who’s worked with all the big off-the-shelf tools, to make sure we’re not doubling down on our in-house builds unnecessarily.

The team was formed about six weeks ago, and I spent the first while trying to define and refine and priorities our OKRs.

  • We’re having to define what CRM means at DIT.
  • We’re having to build a roadmap that sits across all those products
  • We need to help shape each team’s missions for Q4
  • We might get into defining what we most need to learn from trialling any COTS solution
  • We also hope we can do a bit of “showing what good looks like” when working on complicated cross-portfolio and cross-product work.

We need to do the roadmapping work in consultation with the individual teams of course. We want them to truly own their problems, and feel empowered to solve them in the best way possible. They’ve also got people on their teams who know what’s possible these days – whereas I still really only think in old-skool relational databases. So that means trying to follow the Netflix model of “leading by context”. Not defining the solution, but making sure teams know enough about what matters that they can’t do something completely leftfield.

The teams also truly know their users and working patterns, fragmented as they are across the UK and the globe, so are best placed to know whether any new process ideas are likely to land…as well as being able to quickly and cheaply test the ideas behind them.

And, of course, they already have their own roadmaps – for the next quarter or two. Some of which was based on really good user insight.

But the catch in the second of my key results was something quite specific. It wasn’t just “a roadmap”. It was “an eighteen month roadmap”. As I mentioned in the title of this post.

So why do they want that? Isn’t that just a Gantt chart?

Well, yes and no.

You see, there are some understandable worries about the way I’d normally be doing this – which is how I regularly advocate for people to do it when training. I love the “now, next, later” roadmap format. I love Roman Pichler’s goal-oriented roadmap. But I can also understand the concerns of people who’ve previously been burned by MoSCoW prioritisation when working with traditional IT suppliers – that you might as well assume anything that isn’t in your Must list just isn’t going to happen, so you put everything in Must. Similarly, I can see how a roadmap like this can be read as “now, probably next, never”. Particularly when priorities change and there are a lot of stakeholders you had to tell about it – some people might miss the memo and that erodes trust.

So the challenge is to create a roadmap that’s more of an 18-month-long worked example – given that things will undoubtedly change, and teams will be making decisions about this long after I’m gone. They’ll also be finding out some of my assumptions were wrong or based on sketchy inputs, long after I’m gone, and that has to be an integral part of the process. But that also needs to be part of the playback to our stakeholders as well – this is not a commitment, this is the first iteration of a joint process.

But a roadmap like this involves hard choices. There are some vocal user groups who have problems – but fixing those isn’t necessarily the most urgently valuable thing to be doing now. There are software changes we could make that *we* think would be hugely impactful, but there’s nobody in the wider organisation that can do the process change needed. There are also things we could do which would be hugely valuable (and which both our users and stakeholders ask for), but because a set of suppliers all did things differently before they were inhoused, and key decisions about a converged process haven’t been made yet, sow were are blocked. And of course, there are features we’ve built that sit underused/misunderstood, or where we find out during research that people are using the same word to mean different things – or represent completely different mental concepts.

So the roadmap we create today is a symptom of that context.

I’ve spent a lot of the last week looking at the things we could be working on, and documenting two things:

  • what I think the value/priority is, and the questions I think we need to be asking next to be more sure
  • writing down the underlying principles that led me to those decisions, so that we can update the roadmap if they change.

I’m due to present this roadmap to our SMT in a few days time, and the introduction is going to be quite a few slides of “the context as I see it, and therefore the underlying principles that emerge”. I’ll be talking about the readiness of various transformation programmes, the levels of business ownership around known pain points, capacity constraints around must-do technical tasks like migrations etc. This is also going to lead into some prioritisation principles like:

  • Build things for people who can make change happen
  • Developers are expensive, so if users are complaining about a missing feature that already exists, then comms about intended use should be tried first
  • Backoffice staff having to retype things *is* annoying and wasteful, but given development constraints and the bigger goal of economic prosperity we should concentrate on making sure our staff working face-to-face have everything they need to to focus their work…unless the backoffice processes are blocking that.

As I seek feedback, I’ll find out that some of the landscape is wrong and I’ll have to replan. As I talk through the principles I’ll realise that they need to change.

But late last night, as I was thinking about all these artefacts I’ve created to support my first draft of an eighteen month roadmap (slightly against my will), the penny dropped.

I’ve written a product strategy.

How long have I been doing this job? How did I not spot this?

But someone asked me for an 18 month roadmap, and I blindly got on with it, and didn’t spot that actually we needed a product strategy, with a candidate roadmap to come out of it.

Be careful about the words your stakeholders use. They can lead you into all sorts of traps, and approaching problems from completely the wrong end.

(Of course it may be that I’d still have had to do all this work anyway, and I would have been Totally Making Up my product principles if I hadn’t been staring at those really specific prioritisation tradeoffs, but anyway.)

Update:

I realised that some of the choices the teams and I were trying to make were hard because we weren’t aligned around the overall context. I could see the value in solving the problems they saw their users dealing with. There was a lot of junior people doing quite a lot of retyping. But, given some of the big strategy documents I’d been reading, that didn’t feel urgent. That fixing this user problem, but delaying a bigger goal, might not be seen as the right tradeoff.

To fix this, I created a set of ‘even over’ statements to discuss with the team. Things like:

  • We will support our workforce to make the most of their face-to-face contact with companies because that is what will have the most economic impact, even over reducing the back-office admin that we know feels unnecessary for a few more months.

The team might tell me I’m wrong about some of these. The wider stakeholders might say “no, actually, efficiency savings are key”. But at least we’ll get clarity.

I’m also trying to make sure we live by Janna Bastow’s maxim that “your roadmap is a prototype of your product strategy”. We’ll find out how right the strategy is by looking at the roadmap, and vice versa. And we’ll user test the product strategy with everyone from end users to senior stakeholders. Whenever something doesn’t look right, either in a goal or feature people were/weren’t expecting, or in one of our principles – we’ll then work out as a team which thing we need to go back and change. It’s a great way to make the thinking explicit – and fallible.