We work in a quarterly mission structure at GOV.UK. That means that every three months, we take stock of what we’ve been doing and where we’ve got to, taking the opportunity to set new objectives too. But given that it’s hard to make product work fit neatly inside 12-week windows, it’s important to plot your position on your roadmap accurately.

Here’s how I frame what we’ve achieved so far, what’s left to do and what’s next with product teams I manage at GOV.UK, the UK government’s website.

Going over the last quarter

It’s good to summarise everything the team has already achieved; people feel better about their work when they realise it’s working towards something. An easy way to recap recent achievements is to play back the objectives and key results from last quarter and the team’s progress against those.

Remind the team of your previous objective and the pieces of work that contributed to achieving that. Then list out what’s remaining to be done. What’s left to do to reach this milestone we were set? For example, you may need to collect some data, run a test, build a thing or achieve an outcome.

An objective isn’t complete until either the key results have been achieved or you’ve modified them based on what you’ve learned. (And it’s OK to adapt key results to be more realistic throughout the quarter, that’s what lean and agile product development is geared towards!)

Quarterly cycles provide useful checkpoints to remind yourselves where you’ve got to, how it’s contributing to achieving your product strategy, and what’s left to be done before starting the next milestone. Here’s a slide deck I use to frame the work we’ve done and what’s left.

A brief overview of the next objective

Setting the next objective – what you’re going to do – is simple enough, but laying out why you’re going to do it is harder. And that’s a good thing. This is where your skill as a product manager in setting the vision and upholding users’ needs comes into play. It’s also an opportunity for the team to see how everything they’ve discovered and learned about users will be played back to the organisation and other teams, giving them the opportunity to help shape the narrative.

For the last couple of quarters we’ve been using a mission brief template to frame what we’re going to be doing and why. It’s something our Head of Product, Leanne, put together and I’ve tweaked based on John’s one-pagers. The mission brief describes

  • what we’ll be doing, in overview
  • the problem we’re solving and who it’s a problem for
  • the assumptions we have and unknowns we probably need to uncover
  • the biggest challenges we expect to face
  • how our work contributes to the goals of the organisation (in this case, the platform GOV.UK)
  • the broad phases to our work and associated success criteria
  • teams, people and organisations that can help or have input
  • how we’re testing hypotheses and measuring outcomes
  • any deadlines we’re working to
  • how we’ll know when we’re done, and
  • what we’d focus on if we only have four weeks

As product manager, I fill in the template and then workshop it with the team – as all the answers are based on work they’ve been doing. Originally the template was very project-oriented but the tweaks have made it feel more lean, like we’re considering the factors that a good product team should hold close. For example, the headings help us focus more on outcomes, testing hypotheses and learning rather than delivering outputs, building solutions and not taking risks.

Try it out. This should give your team shared direction or will at least create the space to develop it.

Thanks for reading! Don’t hesitate to reach out with any questions on Twitter or LinkedIn, and let me know if there’s anything else which would be helpful.