Public Sector Product Manager's Cookbook


  1. Introduction
  2. Role of the Product Manager
  3. Product Manager core behaviours
  4. Roles (product managers, product owners, service owners, SMEs)
  5. Working with Delivery Managers
  6. Servant leadership
  7. Products, services, and assignments
  8. Agile working
  9. Prioritisation
  10. Problem statements, visions, strategies, roadmaps and delivery plans
  11. Standards, assurance and service assessments
  12. Accessibility
  13. Phases in product and service development
  14. Training and further reading
  15. Appendix: roadmap, thanks, feedback, license


The Public Sector Product Manager’s Cookbook is a practical guide for product managers working in the public sector (particularly central government and the NHS) in England. This handbook contextualises and builds upon the GDS Service Manual, the NHS Service Manual and the NHS Service Standard.

The cookbook started life as an internal handbook for the PMs working in the Data Services directorate in NHS Digital but there was such interest in it that I decided to write a tweaked version for wider use; removing some of the content only relevant to NHS Digital and making sure all links and resources could be accessed by anybody.

Why a 'cookbook'?

What do you do when you get a new cookbook? Do you read it cover to cover and make every single recipe? Well … maybe some of you do but most people don’t! You browse through it, pick whatever looks interesting and have a go.

The information, advice, links and templates here are inspirations and starting points – you should customise your approach based upon what your product or service needs to succeed. After all, there are as many ways to do product management as there are product managers.

The cookbook is a beta MVP and content will continue to be added and refined. See the Roadmap section for more info. This version was updated in February 2023.

Please email me thoughts, feedback, suggestions and salutations to or message me on Twitter @hubbs.


This work is licensed under the Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0) license .

Anyone is free to copy and redistribute the material in any medium or format and to remix, transform, and build upon the material under these terms :

Back to top

* * *

Role of the product manager

The role of product manager is different in every organisation and will even differ from directorate to directorate and team to team. This handbook outlines the main expectations and behaviours for PMs as well as guidance for most PM activities.

When delivering a product or service there will be a number of competing voices for what should be built and how you should go about building it. These voices will typically come from:

It is the product manager’s job to facilitate decision making and prioritisation through conversation and, ideally, consensus. The PM should acknowledge, understand and weigh these different perspectives with the goal of building a quality solution that:

‘Product managers help delivery teams understand and maximise the value that they and their products or services deliver.

They do this by creating an environment where teams and their partners can have timely, relevant and informed conversations about the things that matter most.’

Against entropy — Why product managers really manage conversations

Another way to look at it: the organisation provides the problem space and the principles of product-led development, agile ways of working and user centred design guide us on how to build solutions within that space. Working together, the multi-disciplinary team’s goal is to build the best possible solution within the constraints (including what users need, what the organisation wants to do, budget, timelines etc).

The PM is also responsible for leading discussions on when a team should stop building something. It is a perfectly acceptable outcome of a discovery or alpha to say that no further work should be done. Similarly, products and services have a finite life and it is important to know when to decommission something.

Back to top

* * *

Product Manager core behaviours

1. Make space for the team to succeed

Work at the stakeholder / influencing / political layer to build consensus around, and support for, the product your team is building. Be able to explain that what you are building is informed by the research and work your team has done. Advocate for the product team’s autonomy while respecting and integrating the goals of senior stakeholders into your delivery.

Work with your delivery manager to clear a path through political, people and assurance blockers so that the multi-disciplinary team (MDT) can concentrate on delivery.

2. Be responsible for quality

Ensure that you have identified what standards you need to be delivering to (for example: Technology Code of Practice, the NHS Service Standard, accessibility standards, technology development standards etc). Make sure that the team and your stakeholders buy in to meeting these standards and understand the opportunities and constraints that they bring.

Also be responsible for understanding and ensuring compliance with relevant legislation and regulations.

3. Be the storyteller

Own the narrative for your product. What problem is it trying to solve and for who? Why are you doing this? What is in and out of scope? How does your current delivery phase impact on how certain you are? How does it relate to departmental and organisation priorities?

Be able to describe and answer questions about your product. Tailor your answers to your audience and understand how to adapt your storytelling to your stakeholders’ differing goals. Be able to take complex information you receive from your MDT and interpret and simplify it for your audience.

4. Strive for clarity over comfort

Ask the difficult questions. Is your team really aligned or do people not want to speak up and feel as if things have already been decided? Are your key stakeholders really bought in to your delivery plan? Did design and tech really agree on how a feature should be built or did they just agree what should be built?

Create an environment where useful, timely and correct information can flow between team members, stakeholders and users. Keep the team protected from ‘noise’ and make sure they’re always clear on their priorities.

5. Drive prioritisation, compromise and negotiation

Prioritise what will be done in each sprint and each phase. Choose an appropriate prioritisation technique and bring together the views of your team and stakeholders to find a way forwards. Broker compromise and negotiate when there are opposing views.

6. Advocate for agile delivery

Work towards MVPs and make the case against big bang deliveries. Educate your stakeholders about declining confidence over time, pivoting due to new information, and how agile de-risks delivery. Be in the business of estimates rather than promises and embrace uncertainty. Be clear that any projections you give on dates, costs, shape of final solution etc are based on what is currently known and that the team and stakeholders should expect that these estimates can and will change.

Encourage your team and stakeholders to see failure as an opportunity to learn and that not knowing things is an opportunity rather than something to be embarrassed about or to cover up. Be prepared to say ‘I don’t know, and here’s how we might find out’. Put your unknowns through the cycle of: hypothesis (based on research), testing and iterating.

Back to top

* * *

Roles (product managers, product owners, service owners, SMEs)

We use the language and roles laid out in the DDaT framework .

Don’t use the term Product Owner to describe you, your role, or the role of colleagues representing the business. This term causes confusion between the roles of Product Manager and Service Owner.

The roles of Product Manager and Service Owner are closely related but different. In general:

There is more information on this in the ‘Products, services, and assignments’ section.

It is not desirable or expected for product managers to be subject matter experts (SMEs). PMs need to know enough about the area their product is in so they can make meaningful decisions. However, PMs should rely on SMEs from the business for insights and information rather than trying to know everything about the problem space. The reasons for this are:

More info in this great blog written by Zoe G who helped to design the DDaT framework.

Back to top

* * *

Working with Delivery Managers

The delivery and product roles are closely intertwined with a great deal of crossover and they should work very closely throughout a delivery. Rather than trying to draw clear lines of responsibility between the two roles it is easier to accept that there is crossover and instead concentrate on sharing duties in the interests of driving forward a successful delivery.

A delivery manager will, in general, be more responsible than the product manager for:

Back to top

* * *

Servant leadership

Our approach to product management is that of the ‘servant leader’ rather than ‘CEO of the product’. The product manager doesn’t manage the delivery team, is not in charge of them and cannot order them to do something.

Telling the team what to do and how to do it leads to an unempowered team who do not feel accountability for what they are delivering. This approach also lowers morale and breeds limitations of creativity due to not having a safety net to explore alternative ideas.

Instead, product managers should act as facilitators and create a supportive environment where the whole team contribute to the decision making process. Drawing out the positive and negative consequences of each choice as a team will help you come to a decision as a whole.

When you make a decision as a team, often some members of the team will have advocated for an option that you did not choose to pursue. When a decision is made, it is important that everyone understands why it was made, even if they do not agree with that choice in the moment.

It is important that you and the team recognises that the agile delivery method allows you to change course if you made the wrong decision. Any commitment to following through on a decision only lasts for as long as it is aiding the delivery of the solution.

When you can’t reach consensus, try the following with the team:

  1. Clearly define options
  2. Prioritise options list with a strong weighting towards what your user research is telling you
  3. Can the sprint goal help you choose?
  4. Can the phase goal help you choose?
  5. Can the product vision help you choose?
  6. Escalate to the service owner / SRO (with a recommendation from the team based on highest priorities)

Further reading: ‘Are Product Manager’s really the CEOs their product?’

Back to top

* * *

Products, services, and assignments

A product is a tangible thing that we make. Products are delivered into a service context. They work together to deliver the service. One product can be part of multiple services. In our directorate, some products are used by external users, some products are used only by internal teams and colleagues, and other products are used by both.

A service is the distinct journey that links together a combination of products in a way that makes sense to our users and equips them to do what they need to do (e.g. ‘Check the MOT history of a vehicle, ‘Find an energy certificate’, ‘Apply online for a UK passport’). The journey starts with a user’s problem and ends in the user reaching their intended outcome, which usually solves the problem. Services are named using verbs to describe what users need to do. Separate services are defined by the scope of what allows a user to complete their goal, and what would/could be used independently of another service.

Another common way to conceptualise this difference is that services enable outcomes and products enable outputs. However, the important point to remember in this distinction is that product outputs need to exist in the context of the service outcome/s that consume them.

Product Managers are assigned to single or multiple products or services depending on their size and complexity. In general, PMs are not assigned to programmes of work.

Back to top

* * *

Agile working

Agile is the prescribed way to deliver digital products and services in the public sector. But, if you apply the agile methodology poorly, all you will achieve is doing the wrong thing faster.

The five point summary below is taken from . See for more detailed information.

You must build and run your service using agile methods.

There are different agile methods you can use, but you should always follow these core principles:

1. Focus on user needs

Agile is about constantly putting your users first. You must prioritise their needs over everyone else’s, including those of your senior stakeholders.

If you start building your service before you understand who your users are and what they need the service to do, you risk:

You need to ask for your users’ feedback early and often, and listen to them - even when they tell you things you disagree with or don’t want to hear.

You should always use data from real people who are using your service and let it influence the direction of your project.

2. Keep improving your service

To work in an agile way, you must continuously improve your service and its features - this is sometimes called ‘iterating’.

Every service is different, and building a service is a process which involves a lot of decisions made over time but, in general, follow these steps:

Agile is about making the complex process of building a digital service as simple as possible. It’s based on improving what you do day by day and week by week.

The process of producing incremental, production-ready features allows you to:

3. Keep improving how your team works

As well as improving your service gradually by talking to your users, talk to your team to keep improving the way they work, so that:

Talk to your team to find out what’s working and what needs to be improved, for example in your team’s daily standup or regular retro.

You should try to discover:

Once you’ve found problems, you should agree on a way to fix them. Use standups and retros to see if what you did fixed problems the team talked about at previous meetings.

4. Fail fast, learn quickly

Agile techniques don’t guarantee success, but you don’t have to be afraid to fail or experiment, as agile allows you to spot problems early and resolve them quickly. You should learn to fail and create a culture that learns from failure.

You can prevent major issues or failures from happening by:

Regularly releasing and testing small features with your users:

5. Keep planning

In an agile project, you should continuously plan based on data and usage patterns from the service you’re trying to replace.

Your team should plan together and review these plans regularly based on:

Team shapes in different phases

Agile ceremonies

Show and tells

Of particular importance is the ‘show and tell’ or ‘demo’ ceremony. All PMs should host a show and tell at the end of every sprint that is open to anyone working in your department who wants to come. Key stakeholders should be explicitly invited and asked to attend.

A good show and tell is:

Back to top

* * *


Prioritisation is one of the PM's's most important skills. There are many methods and different situations will call for different techniques. Below are two common scenarios and suggested methods.

Whatever method you use, keep in mind that the outputs are just good suggestions for how to proceed and a framing device for further discussions with stakeholders and the product team.

IDEO 3 lenses method (desirability, viability, feasibility)

This method is good for:

Score your items as follows. Scoring should be done collaboratively with the product team and service owner / SRO to get a good cross-section of views and make it easier for everyone to buy in to the output.




RICE method (reach, impact, confidence, effort)

This method is good for:

Score your items as follows. Scoring should be done collaboratively with the product team and service owner.





Calculating your RICE score

Back to top

* * *

Problem statements, visions, strategies, roadmaps and delivery plans

Problem statements

Before you come up with a vision for your product or service you need to be able to articulate what problem you want to solve with it. Problem statements are a great way to playback your initial summary of the problem area to stakeholders and the team so you can build a shared understanding. Collaborating with stakeholders to produce the statement is also a great way to introduce them to agile; showing that you’re starting with a problem and not a solution.

A problem statement should:

I often use a 3-part structure in a problem statement:

Background and context: What was meant to happen? What was the existing service or product meant to do? What is the context? (for example, where is it happening? Is it online or offline?) Who are the users?

What is the problem? What is happening now? How do you know a problem exists? What can you observe that is happening now? What can you see in the data? This is where you should include facts from research or data analysis

What is the effect of that? What is happening because of the problem you’ve described above? What does the data tell you? This section will tell you what metrics you can use to see if your solution works


All products and services should have a vision – a clearly articulated description of why the product exists. Products and services should also have a high level strategy that defines how it will be delivered.

You can come up with the most beautiful vision for your product. But it’s useless if the people involved in making the product a success don’t buy into it. To leverage the vision as the product’s true north, to create alignment, and to facilitate effective collaboration, the product vision must be shared – everyone must have the same vision. Without a shared vision, people follow their own goals making it much harder to achieve product success.

A great way to create a shared product vision is to employ a collaborative visioning workshop. Rather than formulating a product vision and then selling it to the key people you create it together. Use the product idea as an input and ask the workshop attendees to capture their motivation for working on the product. Then compare the different visions, look for common ground, and combine the different goals into a new one everybody agrees with.


Strategies should be iterated as priorities shift for a product or service. For example, your strategy during alpha will be very different to your strategy in public beta. Use the more constant nature of the vision to make sure your strategies are still driving you in the right direction.


Roadmaps are often regarded as one of the main product outputs but they need to be used and framed carefully to support agile, product-led delivery.

Fundamentally, a roadmap is not a plan. It is a live snapshot of what the product team is currently focusing on and what you think the team will focus on in the future. It is not a promise or a guarantee. It is the team’s view of how work is currently prioritised. However, this prioritisation should and will change as the product team responds to new information and changing priorities.

A great product roadmap communicates the ‘why’ and the ‘what’, whereas a product backlog communicates the ‘how.’ In order to deliver a great product roadmap, it must be: easy to understand, clear, abstracted from detail, and flexible.

No matter what type of roadmap you create, it should be centred around the big picture and problems to solve, not solutions to those problems. It’s very easy to fall into a trap of creating a roadmap that’s solely focused on new features and when they’ll be delivered because that’s usually what makes stakeholders most comfortable. However, it removes autonomy from the team to find solutions to the problems that are outside of previously defined solutions.

Resist the temptation (and pressure!) to put dates on your roadmap. The best format for demonstrating that this is a snapshot of current prioritisation rather than a plan is to use a ‘now, next, later’ format. If stakeholders really insist on timeframes then go with quarters or months (but remember, months are practically only two sprints).

The ‘now, next, later’ format also emphasises that you are most certain about what you are doing right now, and least certain about what will happen in the future. It is also beneficial to explicitly tie your ‘now, next, later’ to your OKRs.


Delivery plans

Unlike roadmaps, delivery plans are a plan! (sort of) Primarily for the use of the product team themselves, delivery plans are a way to plan work at a high level over a number of sprints.

The simplest way to do this is to create a Mural board with sprints or weeks remaining in your phase and lay out the work you need to do. Get high-level estimates from the MDT to see whether all the work can be completed. If not, prioritise and cut items or seek an extension so you have more time. This is a good way to supplement sprint planning to make sure you have both a short and medium-term planning view.

Delivery plans become more useful, and are more likely to be accurate, towards the end of delivery phases when the MDT has a good level of knowledge of the work remaining and how long it will take.

Back to top

* * *

Standards, assurance and service assessments


The standards cover established best practice for the design and delivery of all digital and technology products and services. The standards are mandated by the Cabinet Office and all government departments and partner organisations must meet them.

There are 3 core mandatory standards:

All of the core mandatory standards apply to any digital service delivered to users on the internet.

For technology projects only the spend control standards and the Technology Code of Practice apply. Technology projects include things such as devices, HR systems, hosting and infrastructure.

Key information about the applicable standards in the NHS


All service and technology projects require spend approval before starting any agile phase as part of the Spend Control process.

Information on the central government Spend Control process

Information on the NHS Spend Control information (and how to move through the process).

Service assessments

Generally, all external-facing services will require a service assessment. These happen at the end of each agile phase and are a retrospective appraisal of what you have done in that phase (contrasted with the Spend Control process which is forward looking at work that you plan to do in the future).

You will be assessed by a panel comprised of other people working in digital delivery in government or the NHS. Your product or service will be assessed against the Service Standard or the NHS Service Standard for healthcare services. Following the assessment you will receive a ‘met’ or ‘not met’ outcome. Generally, a ‘met’ outcome is required for you to gain spend approval to proceed to the next delivery phase.

How service assessments work

Back to top

* * *


Accessibility must be considered throughout the product lifecycle as per service standard 5 .

What is assisted digital and how is it different from accessibility?

Accessibility audits

Additional info

Back to top

* * *

Phases in product and service development

The development of a product or service is usually split into five phases: discovery, alpha, private (closed) beta, public (open) beta, live

In this section are listed some common activities and outputs for the different agile phases. This list is not exhaustive and should be considered a menu of typical outputs and activities a team can choose from.

Discovery guide

Alpha guide

Private (closed) beta guide

Public (open) beta and Live

Back to top

* * *

Training and further reading

PM skills scoring matrix

Sources of insight and inspiration used by GOV.UK Product Managers (Martin Lugton)

Tools for better thinking

NHS design principles

Product management development (requires Trello account)

Other public sector product management guides

Back to top

* * *

Appendix: roadmap, thanks, feedback, license

Product management communities

UK Gov slack – product management group


Assumptions, beliefs and bets prompt questions

Handbook roadmap

In the spirit of agile working and delivering value as soon as possible, I’ve started with what I think is the most essential information and guidance for public sector PMs. Subjects to be included in the cookbook in the future include:





Many thanks to Cate Care, Jane Higgins, Steve Messer and Trilly Chatterjee for kindly agreeing to be beta readers and for all their feedback and suggestions.


Please email me thoughts, feedback, suggestions and salutations to or message me on Twitter @hubbs.


This work is licensed under the Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0) license . Anyone is free to copy and redistribute the material in any medium or format and to remix, transform, and build upon the material under these terms :

Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.

NonCommercial — You may not use the material for commercial purposes.

ShareAlike — If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original.

No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.


Back to top

* * *