Public Sector Product Manager's Cookbook
- Role of the Product Manager
- Product Manager core behaviours
- Roles (product managers, product owners, service owners, SMEs)
- Working with Delivery Managers
- Servant leadership
- Products, services, and assignments
- Agile working
- Problem statements, visions, strategies, roadmaps and delivery plans
- Standards, assurance and service assessments
- Phases in product and service development
- Training and further reading
- 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.
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.
* * *
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:
- the customer or commissioner (internal or external) who is funding the activity or where the problem to be solved originates from
- the end users and the internal users of the system
- the multidisciplinary product team (user research, service design, tech etc), each with their own view on how to solve the problem
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:
- users can and want to use to solve their problem or complete their task
- the business / customer will accept
- can be delivered within the various constraints including time, budget, political possibilities, technical capabilities etc
‘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:
- The service owner is usually a senior person from the ‘business’ / policy side and represents the part of the organisation affected by the product or service
- The service owner will be responsible for the product or service after the MDT has delivered it and provides continuity when members of the team change
- A service is often made up of a combination of underlying products, platforms and nested services and the service owner is responsible for that combination
- The service owner is responsible for how their service makes use of nested services and products, even if they don’t ‘own’ them directly
- A service owner is ultimately responsible (working closely with the PM of course) for the successful delivery of a product or service.
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:
- the PM needs to focus on the skill of product management, which is a much wider task than understanding the subject area
- SMEs tend to focus on how things are, rather than how things could be
- knowing too much about the subject matter can make it harder to check for breadth and clarity of user research findings
- PMs are redeployable as required by the priorities of the organisation and becoming an SME means the business will become reliant on a PM as a source of knowledge that should live on the business side instead (this is one of the main differences between organisations of our size and scale, with more products and services than PMs and ever-changing priorities, vs start ups and small scale orgs with only a handful of products and more constant priorities)
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:
- coaching the team to work in an agile way
- delivering a solution in an agile, MVP-led way
- unblocking issues that are stopping the team from delivering
- ensuring the MDT has the right makeup of roles at the right points in the delivery lifecycle
- managing hiring and retention of contractors
- managing the budget and other commercial management
- progressing the delivery through the appropriate gateways (assurance, technical, board sign offs etc)
- leading agile ceremonies like daily standups and retrospectives
- engineering good team dynamics where feedback is expected, welcomed and acted upon
* * *
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:
- Clearly define options
- Prioritise options list with a strong weighting towards what your user research is telling you
- Can the sprint goal help you choose?
- Can the phase goal help you choose?
- Can the product vision help you choose?
- 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 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 https://www.gov.uk/service-manual/agile-delivery/core-principles-agile . See https://www.gov.uk/service-manual/agile-delivery 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:
- focus on user needs
- deliver iteratively
- keep improving how your team works
- fail fast and learn quickly
- keep planning
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:
- building something that nobody needs or wants
- trying to solve problems that aren’t important to users
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:
- Build something that meets the need that’s most important to your users.
- Show it to your users, listen to their feedback and improve it.
- Repeat this process to meet the next most important user need.
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:
- give value to your users and stakeholders regularly
- shorten feedback loops that could be longer if using a waterfall methodology (where you only seek feedback when the final product is complete)
- decide the features you want to add next
- spend time creating features that your users care about
- make sure everything you build is accessible and secure
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:
- the team learns and improves throughout the life of your service
- the quality of your service improves, saving you time, effort and money
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:
- any problems the team is having with absolutely any part of the work
- anything that’s stopping the team getting work done or delaying work
- any problems individual people have
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:
- demonstrating value to your senior stakeholders (eg the senior responsible officer, director or deputy director) with regular releases
- releasing regularly to prevent creating a ‘too-big-to-fail’ service that shouldn’t be released, but must be released anyway
- using processes like test-driven development and automated testing (writing tests before you develop the features to be tested) to highlight issues with quality early on
- identifying important metrics, establishing a baseline and monitoring for changes throughout the project
Regularly releasing and testing small features with your users:
- improves quality
- improves visibility
- reduces cost
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:
- your progress
- any new facts and requirements
Team shapes in different phases
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:
- a summary of both the teams’ work-in-progress and finished work from the sprint
- an explanation of how that work fits into the wider context of the product or service
- an explanation of how the work you’ve done enables your next steps in the delivery phase
- a way to update and get feedback from your stakeholders
- a way to update and get feedback from a wider pool of people outside of your core stakeholder group
- a way to demonstrate and normalise agile ways of working
* * *
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:
- prioritising large possibilities or features with some unknowns
- choosing what to progress with at the end of discovery and alpha
- breaking a deadlock when business priorities are not aligned with user desires
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.
- 0 = no user need, 5 = MVP must have - users cannot use service without it
- Do users need this? Does it help to solve their problem?
- Only score based on evidence from direct user research; not what SMEs or senior stakeholders think users want.
- 0 = orthogonal to product vision / organisation does not want to do this, 5 = clear enabler for product vision / organisation really wants to do this and fits with organisation's priorities and objectives
- Does this meet with the department's / directorate's / organisation's goals / the product's vision?
- Score based on research with your organisation's SMEs and your senior stakeholders. Don't allow 'all 5s'! Make sure your items are relatively ranked according to how well they match department / directorate / organisational priorities.
- 0 = extremely complex requiring lots of development in an unknown area and/or very blocked by something else that must happen or be known first, 5 = easily achievable with no development or additional knowledge gathering work and not blocked at all
- How difficult would it be to build this? Not just dev time but also validating what it is you would need to build (UCD work)
RICE method (reach, impact, confidence, effort)
This method is good for:
- prioritising small, well understood backlog items, opportunities and features
- choosing what to work on for a mature product that is in public beta or live phase
- prioritising when items include bug fixes / tech debt and new features or ideas
- prioritising items that are difficult to compare
Score your items as follows. Scoring should be done collaboratively with the product team and service owner.
- Estimate the number of users or events affected by the item in a fixed time period (for example, transactions or customers per month).
- Use as accurate a number as possible as this will be your base number for calculating the final score.
- Estimate the impact based on your products goal/s (for example, how much will this idea increase successful transactions or how much quicker will users complete their task).
- Choose from these multipliers: 3x for a huge impact, 2x for high, 1x for medium and 0.25x for minimal.
- Estimate how confident that your knowledge of this item (and therefore the other scores for this item) is accurate.
- Score a percentage: 100% for high confidence, 80% for medium and 50% for low.
- Score on 'team months - how much time will this item require from your whole team including product, delivery, UCD and tech.
- For example, an item that will take 2 weeks of design and 1 week of development and 1 week of testing is 1 'team month'.
Calculating your RICE score
- The scoring formula is: (reach X impact multiplier X confidence) / effort
- For example, if reach is 100 users, impact is 2x, confidence is 80% and effort is 2 'team months' then the calculation would be (100 X 2 X 80%) / 2 = 80.
* * *
Problem statements, visions, strategies, roadmaps and delivery plans
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:
- only describe one problem at a time
- not describe any solutions
- be based on facts
- not assign blame
- be concise
- be written in plain language
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.
- Problem statement is the why
- Why are we doing this and what might the benefit be
- Vision is the what
- What are we proposing to build that might meet the need/s outlined in the problem statement
- Strategy is the how
- How will we deliver this solution (e.g. at first we will focus an MVP on area X because our discovery and alpha showed it was the area of greatest opportunity where we could have an impact. Later we expect we will broaden the MVP to include Y because …)
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.
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.
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).
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.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?
- In private beta, products and services should have an accessibility audit conducted by a third party covering both the front and backend.
Additional infoBack 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.
- Prioritise your riskiest assumptions in big problem spaces
- Different types of risky assumptions
- Problem to possibilities impact mapping
- Possible activities
- Investigate the brief from the business, feeding back and redefining if necessary to focus on problems and not solutions
- Stakeholder mapping
- Identify user groups
- Find existing data and information about any existing comparable products and services
- Decide on ways of working (agile ceremonies, where to capture info etc)
- Identify service owner
- Identify constraints (policy, legal, tech etc)
- Stakeholder interviews
- Ideation and goal-setting workshop
- Possible outputs
- Problem statement and context
- Research plan for alpha
- As-is journey / service map
- As-is technical map / dependencies
- Pain points from as-is journey map
- Initial user research findings: user experiences, organisational culture, verbatim quotes
- Assumptions list
- Possible activities
- Decide alpha scope
- Prioritise risky assumptions (see links in discovery guide section)
- Research plan incl. discussion guides
- User research with existing and potential new users
- Design, test and iterate low fidelity prototypes
- Possible outputs
- Prioritised user needs
- User research report (synthesis board, affinity maps)
- Design prototypes (low fidelity)
- Service journey maps and flows
- Agreed shape of beta MVP
- Plan for beta phase
- Expected benefits from beta
Private (closed) beta guide
- Private beta typically consists of two halves: in the first half you are building what you prototyped and proposed in alpha. In the second half you are testing your MVP with a small, invited group of users and using their feedback to iterate your service.
- You should end private beta with an MVP product or service that will meet user expectations in public beta.
- Possible activities
- Build MVP, test and iterate
- Design ‘feature toggles’ for ease of testing
- Accessibility audit (front and backend)
- Test and validate scope of MVP service
- Work with internal users - discuss key designs and insights from research and use workshops to co-design key parts of the service.
- Possible outputs
- MVP product ready for public beta
- Confirmed invite list of private beta
- Fully tested ‘offline’ journey for users who cannot access the service online
- Fully tested support route that users can use if they have a problem with the service
- Plan for what will happen if the service goes down
- Iterated, detailed persona profiles including motivations, specific needs, likes and hopes, likely place on digital inclusion scale etc
- Full understanding of likely assisted digital and accessibility needs and how to meet them
- Detailed service blueprint showing front and backend actions and processes
- Evidence of iterating design of the service and individual pages within it, based on user testing
- Capability to monitor performance of front and backend of service and established KPIs / alert thresholds
- Plan to collect both GDS mandatory KPIs and service-specific KPIs
- All code that can be has been open-sourced and stored in a publicly available repo on Github
- Plan for public beta and a prioritised backlog
Public (open) beta and Live
- In public beta you will evolve your product or service past its MVP state, continuing to be guided by user insight.
- Most public sector digital products and services stay in public beta and often do not officially progress to ‘live’. For all intents and purposes, public beta should be treated as live.
* * *
Training and further reading
Other public sector product management guidesBack to top
* * *
Appendix: roadmap, thanks, feedback, license
Product management communities
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:
- Pre-discovery guide
- Prioritisation techniques / ‘the PM is responsible for delivering value’
- Working with stakeholders
- Normalising agile, service assessments etc
- Common reasons for MDT and stakeholder misalignment
- What to do with a BAU product (incl. using the Technology Code of Practice)
- Keystone questions (how does this deliver value to the organisation and user etc)
- When to stop building something or decommission a service
- What does good look like for the PM
- PM skills framework
- Product maturity framework
- Documentation standard
- Techniques for making decisions
- Product planning and roadmaps – agile planning with fixed budgets and timelines
- More templates – roadmaps, planning, demos, assessments decks etc
- Standard ways of working / day-to-day flowchart
- Agile working continued
- Working with UCD (gaining ‘literacy over expertise’ in UCD)
- Working with tech
- Playbacks (internal) and show and tells (external)
- Ceremonies and their uses
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.
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.
- You do not have to comply with the license for elements of the material in the public domain or where your use is permitted by an applicable exception or limitation.
- No warranties are given. The license may not give you all of the permissions necessary for your intended use. For example, other rights such as publicity, privacy, or moral rights may limit how you use the material.
* * *