Planning for January to March 2024

James Higgott
4 min readOct 17, 2023

Teams working on the NHS App get together every 3 months and share their plans for the next quarter. This is an opportunity to identify dependencies, duplication and areas for collaboration. It’s also a chance for product, engineering and design leads to share some high-level messages with the people who decide what our teams focus on.

Here are the messages I shared:

Top-level goals

There are 2 main top-level goals for the NHS App as a product:

Reduce the burden on frontline staff

Reduce the number of tasks required of all staff at GP surgeries and NHS call centres, and clerical staff at hospitals, by supporting users to self-serve and self-care.

Reduce barriers to care

Ensure that the NHS App can be used by all, and that features and integrations are available to the largest possible share of our user base.

We also have 1 goal for ourselves as a team:

Improve the user experience of the NHS App

Make it as easy, quick and reliable as possible for users to complete tasks, so that the NHS App is their preferred way of doing these.

Priorities for January to March 2024 (Q4)

The theme for Q4 is ‘consolidation’ — laying foundations for future delivery. This means doing things like:

  • rolling out the new design and information architecture
  • improving analytics and performance measurement
  • improving supplier onboarding
  • implementing A/B testing
  • moving off Xamarin to Kotlin and Swift
  • exploring native device functionality
  • upgrading the architecture used for notifications and messaging.

We also have some big commitments (some big messy projects to deliver) but the emphasis should be on fixing the roof while the sun is shining.

New teams joining us

3 new teams joined us in September/October 2023. They will all have an impact on our plans for Q4 and beyond.

  • Team Omelette is moving us off Xamarin, understanding which native app features might benefit our users and then delivering some of those features.
  • Team Apollo is defining our approach to digital therapeutics in the NHS App.
  • ‘Team Name TBC’ is defining our approach to care plans in the NHS App.

Principles to bear in mind

  • It is better to under-promise and over-deliver than the other way around.
  • Map your dependencies. For example, we don’t currently have sufficient capacity in our data and analytics function. We’re doing work to address this but if you have a requirement for data and analytics (and all teams should) you need to map this dependency so that we can plan for it.
  • Raise your hand if you have doubts about something on the roadmap or the approach we are taking. Speak to your Product Manager or to me. We all know that things can change between agreeing to do a thing and actually doing it — don’t feel you have to plough on just because a decision was made several months ago.
  • Plans can change — they are not set in stone. We will formally review our plans for Q4 at the end of Q3, but we should be reviewing them constantly between now and then, and even as we get into January, February, March…

Having a balanced roadmap

This image is adapted from an original by John Cutler. I’ve re-named the categories of work to use the language more familiar to NHS England product teams.

Diagram advising product teams to balance their roadmaps with a mix of work (exploratory research and unstructured experimentation, new features, continuous improvement, product debt and unplanned work or interruptions) instead of concentrating on new features.

Exploratory research and unstructured experimentation

If a team doesn’t do enough of this, they may fail to understand emerging user needs or struggle to innovate. They risk becoming a team that only keeps the lights on and/or takes new requirements from stakeholders.

New features

If a team doesn’t do enough of this their product could miss opportunities to deliver new value to users. Note that teams should not develop new features for the sake of it — some mature products only rarely (or never!) require new features.

Continuous improvement

If a team doesn’t do enough of this their product could struggle to stay relevant as user needs and business goals change. They might also miss opportunities to optimise user journeys and increase the value their product delivers.

Product debt

Product debt (tech debt, design debt, etc) accrues over time in the form of increased complexity due to things left undone or unoptimised during work on new features and continuous improvement. If a team doesn’t spend time paying down that debt, delivery will become harder and slower over time.

Unplanned work / interruptions

These are a fact of life. However, teams can minimise these by finding the right balance in the other 4 areas of work.

Product vision and strategy

We are currently drafting a new vision and strategy for the NHS App. This work is not yet finished but we already know that we want to see an increase the types of transactions that can be done through the NHS App.

This is part of the reason why it’s so important to lay foundations in Q4. It’s why we have new teams helping to define our approach in specific problem areas.

We’ll share more on the vision and strategy soon, but when you are thinking about plans for Q4 be aware that there are big ambitions for the future being defined right now.

--

--

James Higgott

Head of Product for the NHS App. South London resident.