Shared purpose and a clear direction — building our first roadmap
We’re a few weeks in to being the new digital service design team at the National Lottery Heritage Fund, and we’re all beginning to settle into our new roles and find our rhythm as a team spread across several locations.
We’ve spent a bit of time in the past couple of weeks together as a team getting to know each other, and working out things like what we all need to do our best work and be ourselves at work, and how we should organise ourselves as a team to make sure we’re doing all the things we need to and collaborating as we go.
This week, we pushed things forward by making a first version of our roadmap. The Government Digital Service describes a roadmap as ‘a plan that shows how a product or service is likely to develop over time. Roadmaps need to be easy to understand, and simple to adjust when priorities change — as often happens with agile ways of working. A roadmap makes it clear what you’re trying to achieve and the steps you’ll take towards that end goal.’
Our roadmap sets out the milestones we expect to focus on over the next 3, 6 and 12 months, and even makes some guesses about things we’ll have achieved in 2 years’ time. This roadmap doesn’t represent commitments made yet, because we have yet to present the suggestions to our senior colleagues, and we’ve not got their challenge or their sign off yet. However it was important to take all the learning we’ve got from interviewing customers, analysing data and working with our funding colleagues and put it into some kind of structure to help inform some of the decisions we need to make in the near future.
We discussed things we expect to be working on, and also acknowledged things that we didn’t expect would ever be within the scope of our service, in case those cropped up in discussion. We developed the roadmap over a few hours using a format based around 7 questions to help make sure the whole team could have input into our focus and direction, and to help keep our discussions open and accessible.
We’re using this roadmap to give our work some shape and direction, so that we can set ourselves smaller weekly goals. We call the bigger bits of work ‘milestones’, and they’re all worded as outcomes, rather than inputs — so ‘more diverse range of users for small grants’, for example. Each big bit of work will be made up from many smaller deliverables, which you can see at any time in our shared team ticket backlog.
We’ve written our milestones in a way that supports continued iteration and lets us evaluate our progress as we go. So we chose wording like ‘fewer issues at the initial check stage related to ineligibility’ rather than ‘37% fewer issues’ to allow us to get started on making progress towards improving customer experience without relying on a target that we can’t really justify at this early stage.
We expect things on our roadmap to change, as we learn more about the problems to solve, who the users are and what they need from the service. Even though changes to priorities are inevitable, it’s useful to spend the time talking about this now. It helps us consolidate the things we already know and be open about the things we still need to learn or test. It helps us get to a sense of common purpose as a team, which helps us build momentum as we work on our immediate priorities. It also helps us have more difficult conversations about the things we can’t tackle right away, or that we can’t prioritise.
All of this makes our roadmap a really important tool for us as a team, but also for communicating with our colleagues and our users about what they can expect from us and how they (and you!) can get involved in our work and help contribute to our thinking.
Setting out some clear goals and priorities has also helped us to articulate our focus in a way that puts our users at the centre of our thinking. How we describe the work we’re doing is something else that we expect to change as we learn more, particularly about the language that users find most familiar and recognisable, because that’s one of the ways we can ensure that people can find and use our service easily and confidently. In a future post we’ll talk a little more about the process of naming and describing our service, and share our working version.
