Guide for product teams

Principles for how product teams build services (draft)

Audience: Product team members

Purpose: Set cross business unit philosophy for how product teams work together. Serve as a resource for setting disagreements about the way forward.

At the beginning:

1. Understand people’s needs. Try to understand the key groups involved in a service, including the public and involved government workers.
2. Elevate underserved voices. Always understand the needs and experiences of the people underserved by your service and government. Services can perpetuate or reduce systemic inequities; do the work to understand how your service can make things better.
3. Depict the service journey. Sketch the journey people take to meet their needs now, and how that journey might change with your service.
4. Understand the critical context. Identify stakeholders that support a service owner in implementing or adopting a product, particularly in the areas of security, privacy, accessibility, and bilingualism. Understand their needs and goals to identify and mitigate critical blockers.

As you shape a service:

1. Prototype early and often. Use prototypes early to elicit more specific feedback on needs, and make our ideas clear. Don’t get attached to prototypes, use them as learning tools.
2. Start with a particular slice or layer of the service journey. Pick a narrow slice or layer of the journey to focus on. Focusing on improving that slice/layer should better meet some key user needs, without harming anyone else.
3. Create a roadmap and backlog driven by people’s needs. Every element of the backlog should:
   1. map to a point in the user journey
   2. A need (from the end user or other stakeholders)
   3. a related organizational goal

As you build a product:

1. Use just enough design, research, engineering and product management to meet people’s needs.
   1. Do just robust enough research that we know what people’s needs are.
   2. Do just enough design and engineering that we’re confident our product meets those needs safely and sustainably.
   3. Have just enough product management processes that we meet our objectives and follow these principles.
2. Usability test, change and repeat. We test our services with the people who use them over and over again. We resolve both major and minor issues as we identify them.

Along the way:

1. Focus on making the bureaucratic, process and technical changes we most need to meet people’s needs. We can’t make every change we might want to. Understanding the spirit of a rule or process and to try and meet it.
2. Each discipline should know (roughly) what each other are doing and how their work relates. That doesn’t mean we don’t sometimes work independently, but it does mean we each know how the pieces fit back together.
3. Work in the open. Share as much of your work in progress with your fellow team members and partners as you possibly can.
4. Measure and celebrate incremental progress. Select, track and report on key metrics using our evaluation framework. Celebrate small success as much as major impacts.

Note to reader: We are not setting a principle on how much “capacity building” we do as part of a given delivery. That remains the business unit’s prerogative.