Toolkit

When designed with beneficiaries in mind, government services can be simple, effective, and accessible to all. To achieve this, it’s important for government agencies and vendors to balance beneficiary needs, program goals, the agency’s mission, and budget when designing public services. These services include both technology-enabled online and offline experiences which we’ll broadly refer to as products in this article. 

This is where product leadership comes in. When designing and building government products, there are typically two product roles—product owners (PO) and product managers (PM). While different organizations may use different terms to describe these roles, in this toolkit, we will use PO to describe a government PO and PM to describe a vendor PM. 

In our experience, POs and PMs complement each other and work together to ensure success. A great PO–PM partnership fosters a positive team dynamic and implementation of products. 

If you’re a government PO, this toolkit will demonstrate how to optimize working with vendor PMs. 

Some important definitions: 

• A government Product Owner (PO) has deep knowledge and expertise of agency programs, policies, and goals. Broadly, the PO owns the vision and strategy behind the product; they may or may not have experience with software development. Because POs have multiple responsibilities, they may be less involved in planning and executing work. 

• A vendor Product Manager (PM) manages the day-to-day operations of building products and has more time to focus on the minutiae of a product. In collaboration with a team of software engineers, designer/researchers, and project managers, PMs translate the product strategy from the PO into actionable tasks. 

• A product is a group of features, or capabilities, that together help enable the agency to provide a service to their users. Examples of products include case management systems or claim submission portals. 

• A feature is part of a product and often enables users to carry out an action. Examples of features include the ability to manually and automatically assign cases to case workers or the ability for a claim application to be auto-saved.

Factors like team size, team makeup, project goals, and project needs can affect the relationship between a PO and PM. These variables can also dictate the day-to-day work of POs and PMs. To offer a comprehensive look into how POs and PMs collaborate, we’re sharing perspectives from our own experience working with government agencies.

This is the second toolkit in a series of two. To read about collaboration before you head into product launch, see the first toolkit.

Interface with other teams and vendors

Successfully building government services requires a significant amount of coordination, often involving numerous teams within the government agency and from outside vendors. POs are integral to ensuring that all of the work streams from different teams align in an efficient and effective way and tie back to the agency's desired business outcomes.

Identify cross-team dependency needs early

When collaborating with several teams and vendors, POs can help identify cross-team dependencies and collaboration needs early. This helps ensure that both teams can properly plan and meet existing timelines. When the PO identifies dependencies with other teams, they can connect the PMs from each team to one another. The PMs can then leverage these connections to streamline future work.

For example, the product development team on one of our projects had the opportunity to work closely with another government team to devise a solution for a problem the agency was facing. Our product development team had not previously worked with this government team, so the vendor PM leaned on the PO’s relationship with the other government team to align internally. Once they aligned, the PM and product development team planned a few brainstorming workshops. These workshops helped build a shared understanding of the problem and ideate solutions. The work resulted in three viable recommendations that the team presented to stakeholders.

During the planning process, the PO reviewed and made suggestions on the workshop format based on their knowledge of the other team’s interests, capacity, and work style. When tough questions arose, the PO acted as a context-setter and facilitator. 

The PO was instrumental in this situation. They helped make the initial introductions between the two teams, set the shared goals of what the client wanted to achieve, and empowered the PM to build their own relationships with the other team. These new relationships led to more sharing of information and awareness of what each team was working on. 

Collaborate for the product launch

Preparing for a product or feature launch is a critical step in the development process. It’s a highly collaborative phase that involves team members from multiple disciplines and provides a final check for a product’s readiness. Though the level of direct involvement from the government PO and vendor PM can vary at this stage, it’s important that they both remain up to speed on activities. This ensures that the final result meets all of the goals outlined at the start of development. 

Keep stakeholders informed before and after the launch

Vendor PMs are crucial during product launches. With their product development team, they focus on performing the necessary work to release a feature to end users. This launch preparation work includes developing test scenarios or refining metrics to track that align with any goals the PO has identified. While the PM focuses on these duties, the PO can ensure that all stakeholders remain in alignment on the status and direction of the product. The PO can also keep stakeholders up-to-speed throughout pre-launch activities and can report back on progress. 

For one of our projects, the team created a runbook, or a checklist of activities they needed to complete within the 6-8 months prior to launch. This included items like end-to-end testing and training. The PO provided their perspective on which steps would be necessary for the launch and connected the PM with other stakeholders to help confirm the necessary steps for a successful launch.

Meanwhile, the PM demoed the work to the PO and other stakeholders identified by the PO. This allowed all of the agency stakeholders to see the end result and provide any final feedback or suggested changes before launch. The PO’s communication about progress and updates related to the feature ensured that all of the stakeholders remained aligned on the direction of the feature throughout the development process.

Wrap up 

Vendor PMs can collaborate with government POs in different ways based on where the product is in the development cycle. Overall, POs bring the organizational context and holistic expertise. Specifically, they can identify interdependencies between teams, build alignment with stakeholders during a product launch, and celebrate the team’s success.

Meanwhile, PMs bring technical and product development expertise. They provide insight into technical feasibility, gather and pull together context from a number of different sources, and manage the day-to-day processes of the development cycle. This can include interfacing with other teams, keeping the PO involved in a product launch, or doing the work to release a new feature. 

To learn about how POs and PMs can work together to identify new opportunities, plan a roadmap, and make decisions, read this toolkit.