Migrate Product Playbook

The product playbook has been migrated from this commit: LBHackney-IT/Product-Playbook-microsite@b14581f.

The Product Playbook _probably_ shouldn't live as part of the engineering site, but as the
only contributors are engineers this migration reduces the overall maintenance burden.

If this one is contentious we can revert this commit and discuss it separately

Author: spikeheap

docs/frontend-development/boilerplate.md

@@ -1,8 +1,4 @@
----
-id: boilerplate
-title: BoilerPlate
-slug: /boilerplate
----
+# BoilerPlate
 
 ## Base configuration repo
 A refresher on the benefits of microfrontends in the context of Hackney Council:
@@ -21,7 +17,7 @@ The microfrontend's that are built will still be applications that developers ar
 Setting up a MFE using single span is very easy, you can begin scaffolding an application with the CLI with the command below:
 
 ```
-npx create-single-spa 
+npx create-single-spa
 ```
 
 The CLI neatly allows you to scaffold the root config or the MFE applications.

docs/product-playbook/How we work/README.md

@@ -0,0 +1,36 @@
+# How we work
+## Introduction
+
+At Hackney, we design and deliver products in a consistent but adaptable way. Structure will help us scale up, but we don’t produce documents for documents’ sake.
+
+We work to [GDS service standards](https://www.gov.uk/service-manual/service-standard) and put resident’s needs at the heart of what we deliver. We strive to use industry best practice for product management and take pride in our profession.
+
+## Product inception
+
+- Each product should start with a clear problem to solve for a defined user group, within those who live and work in Hackney.
+- High-level user needs should be identified through data, insight and research and these should inform the product direction.
+- We will be solution-agnostic and focus on solving residents’ problems in the most effective way.
+- We should only start a project when the conditions are right (defined in [Hackney Council Product Strategy 22-23](hackney-council-product-strategy.md)).
+
+## Product artefacts
+
+- Researched user needs and data should inform all our product artefacts.
+- Our products should bring value to Hackney Council and our residents. We will show this through a strategic thread of goals that link back to the [Hackney Council Manifesto](https://www.hackney-labour.org.uk/hackney-labour-2022-26-manifesto/), the Strategic Plan and our user needs.
+- We believe that a meaningful product vision, strategy, roadmap and backlog (which we call product artefacts) will help us focus on building the right thing for our users.
+- If we don’t have the information we need or the processes to produce these artefacts it's better to not have them rather than invent something not grounded in research.
+
+The consistent goals and artefacts we would like available for each product can be seen below:
+
+![goals and artifacts](../images/where-to-start/1.png)
+
+We intend to create a strategic thread of goals that join our day-to-day tasks back to our user needs and Hackney’s manifesto aims:
+
+![strategic thread of goals](../images/where-to-start/2.png)
+
+For support and resources to create these elements, please see the individual guidance in this chapter of the playbook.
+
+## Where to start
+- Start with gathering your [user needs](user-needs.md) of your residents, this can be using existing or new research, data and insight
+- Clearly identify the problem to be solved
+- Create a [product vision](product-vision.md)
+

docs/product-playbook/How we work/product-backlog.md

@@ -0,0 +1,60 @@
+# Product Backlog
+## Introduction
+
+The product backlog is a prioritised list of what needs to be done to build or improve the product.
+
+![backlog diagram](../images/product-backlog/1.png)
+
+## Creating the backlog
+
+- The product backlog needs to be derived from the product roadmap.
+- The backlog should comprise the tasks needed to be done to achieve the product goals in the ‘now’ section of the roadmap.
+- It can be helpful to focus on one product goal at a time from your roadmap. This keeps the backlog concise and focused.
+- The product backlog is a tactical tool that can contain user stories, designs, sketches, mock ups, user journeys etc.
+- It should be concise and focused, rather than becoming a ‘wish list’ of lots of items.
+
+## Backlog Example
+
+To better understand how we would build a backlog from our roadmap here is an example.  This is an example of a roadmap for an organisation with the vision ‘A workplace where no employee goes thirsty’.
+
+![backlog example](../images/product-backlog/2.png)
+
+The team would then use the goals in the ‘Now column’ and create the backlog from these goals.
+
+Here is an example of their initial backlog from the first item in their roadmap ‘Select the two main drink providers’:
+
+![expanded backlog diagram](../images/product-backlog/3.png)
+
+Breaking down the backlog tasks specific to the first product goal of the roadmap ensures that their work is focused on what is most important. It also enables small achievable tasks to still map back to the bigger aim of achieving their product strategy and vision.
+
+## Prioritising the backlog
+
+- Prioritise the items that you have more certainty about, to achieve the product goal with the least amount of effort.
+- Data and research should be used to identify items that would most likely achieve the product goal. The product team can then identify and inform the level of effort.
+- It is important for product managers to say ‘no’ to backlog items that do not contribute to the product goal and therefore wouldn’t help meet the product strategy and vision.
+- It can also be important to identify higher risk items that might need to be worked on sooner.
+
+## Refining the backlog
+
+- High priority items should be at the top of the backlog, and be in a detailed ‘ready’ state.
+‘Ready’ items are clear and understood by the team, testable with acceptance criteria and be small/not too complicated so that they can be completed in the sprint.
+- Items lower down the backlog are lower priority and should be in a bigger ‘sketchy’ state.
+- The product team should contribute to refining and prioritising the backlog and using their specialist knowledge to inform on activities, dependencies and risks to inform backlog items.
+- The product backlog should change over time, especially as data, insight and user research is reviewed. This should influence the creation of new items and the removal of less relevant tasks.
+
+## Sprint Goals
+
+We intend to create a strategic thread of goals that join our day-to-day tasks back to our user needs and Hackney’s manifesto aims:
+
+![goals](../images/product-backlog/4.png)
+
+- The sprint goal is the purpose for the team for the sprint (or next agreed period of time) and communicates the ‘why’ behind the work.
+- It is what the team intends to achieve when the backlog tasks are completed.
+- A sprint goal might be to deliver a feature, address a risk or test an assumption and will link back to a product goal in the roadmap.
+- It should identify what needs to be achieved and how we know it is done.
+- The sprint goal should be agreed between the product manager and the product team and communicate what is achievable for the team.
+- Daily stand ups should feedback on how work is contributing to achieving the sprint goal and help the team stay focused.
+
+## Further Information
+- [Scrum.org - 11 Advantages of Using a Sprint Goal](https://www.scrum.org/resources/blog/11-advantages-using-sprint-goal)
+- [Scrum Alliance - Sprint Goals Provide Purpose](https://resources.scrumalliance.org/Article/sprint-goals-provide-purpose)

docs/product-playbook/How we work/product-roadmap.md

@@ -0,0 +1,66 @@
+# Product Roadmap
+
+## Introduction
+
+- ‘A roadmap is a plan that shows how a product or service is likely to develop over time’ (GDS Service manual).
+- Our roadmaps will use a Now, Next, Later format - with the time periods for each defined by the product team.
+- The roadmap is intended to be flexible and change to suit changing circumstances or be reprioritised as product teams learn more from data, research and feedback.
+
+![product roadmap](../images/product-roadmap/1.png)
+
+<u>Product Goals</u>
+
+- The roadmap will be formed of the goals that we would like our product to achieve.
+- Product goals describe the desired future state of the product, and the benefit the product should bring to our users.
+- These will map to the Council, User and Operational goals in our product strategy.
+- Product goals will be larger in size than an epic or task in the backlog, but smaller than our strategic goals.
+- Each product goal can contain high level features/deliverables to meet the goal and relevant metrics to identify if the features built do achieve the overall product aims.
+
+We intend to create a strategic thread of goals that join our day-to-day tasks back to our user needs and Hackney’s manifesto aims:
+
+![goals](../images/product-roadmap/2.png)
+
+<u>Creating the roadmap</u>
+
+![roadmap diagram](../images/product-roadmap/3.png)
+
+- Creating and prioritising a roadmap should be led by the product manager.
+- It should be a collaborative process involving the product team and key stakeholders.
+- Roadmaps need to be informed by data, performance analytics and user research.
+- Initially a product roadmap may consist of the goals that would need to be achieved to create the minimum viable product.
+- It can also be helpful to consider the following areas when creating a roadmap: new ideas, product iterations, user issues/feedback, features to scale and ways to improve the quality of your product.
+- Product goals should be able to map back to the Council, User or Operational goals in your strategy, and one product goal can often be mapped back to multiple strategic goals.
+
+## Roadmap Example
+
+To better understand how we would build a roadmap from our product strategy here is an example.  This is an example of a roadmap for an organisation with the vision ‘A workplace where no employee goes thirsty’:
+
+![roadmap example](../images/product-roadmap/4.png)
+
+Each product goal in this example roadmap can map back to multiple strategic goals.The product goals in the roadmap are smaller and easier to achieve in size than the strategic goals. For example the item in the roadmap “Buy the drinks and cups’ is an achievable step towards the bigger goal of “Users are easily able to access and consume a drink at work’.
+
+## Roadmap Ideas
+
+- Use the ‘new idea canvas’ to start considering the validity of your ideas for the roadmap, ensuring that they are backed by research and data.
+- If a number of the fields in the canvas are blank or do not support creating value for your users, you could consider generating further ideas or carrying out additional research.
+- It is important to review the selected product ideas to see if they can be made less complex or more achievable. Often a goal can be refined to be more focused but still achieve the vision and bring benefits to users.
+- Use the idea refinement canvas to see if goals can be made smaller or more focused.
+
+## Prioritising the roadmap
+
+- Prioritise your roadmap into now, next and later. The product team can decide the rough time period these relate to.
+- Once ideas have been validated and refined, mapping the effort vs impact of each idea with the product team is a good exercise to start identifying priorities.
+- Effort should be quantified by specialists in the product team, particularly those who have experience with quantifying the time and energy required for delivering technology.
+- Impact should be quantified using evidence from research, data and insight. This should help avoid assumptions or pre-existing ideas for solutions.
+- It is important to flag any dependencies within your team and from other teams or services and sequence your roadmap accordingly, collaborating with a Delivery Manager on sequencing is important.
+
+![effort vs impact diagram](../images/product-roadmap/5.png)
+
+## Further Information
+- [New idea canvas](https://miro.com/app/board/uXjVPpbQeSQ=/?share_link_id=600539960503)
+- [Idea refinement canvas](https://miro.com/app/board/uXjVPpbQeSQ=/?share_link_id=600539960503)
+- [GDS Service Manual - Developing a Roadmap](https://www.gov.uk/service-manual/agile-delivery/developing-a-roadmap)
+- [Roman Pichler - Product Goals in Scrum](https://www.romanpichler.com/blog/product-goals-in-scrum/)
+- [Intercom - Where do product roadmaps come from?](https://www.intercom.com/blog/where-do-product-roadmaps-come-from/)
+- [Working with Agile Product Roadmaps](https://www.romanpichler.com/blog/agile-product-roadmap/)
+- [A suitably detailed roadmap](https://cutlefish.substack.com/p/tbm-41b52-suitably-detailed-roadmap?s=w)