Product management in government: Why it’s essential when the stakes are high

By Ivana Ng

The three key areas of product-thinking that we need to see more of in government are product vision, architectural leadership, and holistic service design. In this post, I’ll talk about how we shipped the largest modern change to Medicare using these practices.

Product management is critical to designing user-friendly government services. It’s the (not-so) secret sauce that enables Nava PBC and its government partners to modernize large, complex programs like HealthCare.gov, Medicare’s Quality Payment Program, and the appeals process at the Department of Veteran Affairs in a way that not only implements policy, but most importantly, serves people first.

The three aspects of product thinking that are particularly vital to a successful, high-impact government product team are product vision, architectural leadership, and holistic service design.

Product vision: set direction for the product and the team

The product vision acts as the project’s true north. It is the overarching goal everyone involved must share, including the product manager/product owner, delivery/project manager, team, management, users and other stakeholders. It serves as an anchor when it comes to making tough prioritization decisions. In government projects, it’s the working agreement that the institution makes with the people it serves. We have to consider user needs, business needs, technical needs, design needs, constraints, risks, open questions, assumptions, etc, all to align iterate on a product vision that does right by its users. Then, it is continuously validated through experiments, user research and metrics.

Product vision is the working agreement that the institution makes with the people it serves.

Without a product vision, we run the risk of building the wrong things at the wrong time, over-engineering the product, and building features that don’t deliver the most value to our users. In the world of delivering government services, this manifests as features that don’t serve vulnerable populations, going over-budget and taxpayers footing the bill, and slow websites with frequent downtime. We saw this when HealthCare.gov initially launched without a mobile-friendly version, which made buying healthcare virtually impossible for more than one-third of users. A strong product vision would have connected the policy requirements to user needs.

Here’s an example of a product vision statement: Medicare’s Quality Payment Program (QPP) aims to deliver real-time, actionable feedback to doctors so that they can deliver high quality, cost-effective care to patients. There are over 300 people working on QPP (shoutout to the Centers of Medicare & Medicaid Services (CMS), the United States Digital Service (USDS), Ad Hoc, Semantic Bits, and many others!) — and what unites us is this goal. It guides every decision we make and keeps us focused on delivering the best service for our users — doctors and the 33.8 million Medicare patients they serve.

Architectural leadership: build resiliency in the face of policy changes and complex problems

Bringing the product vision to fruition requires strong architectural leadership. The product team must collaborate closely with technical architects at every step of the product lifecycle. This enables us to design services that are resilient enough to handle shifts in legislative policies, while also keeping a large team laser-focused on serving users first and moving toward the product vision.

This collaboration started soon after MACRA, which created QPP, was passed in 2015. USDS embedded with CMS to lay the groundwork for a truly integrated project team that combines policy and operations. They established a tight iterative feedback loop between the policymakers and technologists implementing MACRA. We don’t shy away from sharing how nuances of policy and operational complexities impact our technical implementation — and vice versa. As a result, we deliver more human-centered policy and services.

Though we do still run into issues where the policy doesn’t always match up with what we’re hearing and seeing from users, prescient architectural decisions can make policy-to-user mismatches minor course adjustments in the roadmap, as opposed to major detours.

Strong architectural leadership means having a holistic view of the entire system when making product decisions. QPP replaces three legacy Medicare payment programs, so it involves building up new infrastructure and integrating with the old. It is also designed to be iterative, so as more data comes in and QPP learns from its users, it will get better at measuring quality of care.

In that vein, we built a common set of APIs that powers internal systems and enables external software vendors to build the TurboTaxes of healthcare quality reporting. This API-first approach adds a layer of abstraction between the backend and consumers of the APIs, so that if we make changes to the underlying backend services, the impact is minimal.

It is equally important to determine upfront what data you need to store now for analysis later. We work closely with QPP’s policy team to understand the metrics needed to assess the program’s effectiveness at incentivizing cost-efficient patient care. We design our databases and APIs to ensure that we can trace a user’s journey through the QPP ecosystem and make it easier for them to answer questions like, “Is QPP improving quality of care over time?”

Holistic service design: think about your users, their users, ALL OF THE USERS

Most product managers are familiar with user experience design. I myself have built my fair share of personas and journey maps, but that’s just one piece of the puzzle. We need to take a service design approach and look at the end-to-end experience, including all the stuff that happens backstage to make that experience happen, e.g. physical interactions, digital interactions, call centers, support systems and infrastructure.

Service design compels us to apply human-centered design to more than just end users. Behind every backend system is an architect, and in front of every system are end-users. At QPP, product teams are the architects, and the end-users are doctors, practice managers, hospital administrators, and engineering and product teams at health IT software companies. We must understand the needs of all sides, as well as their interactions with various touchpoints (such as their office software), in order to design systems that optimize the quality and interaction between QPP and its myriad customers.

QPP has a tight-knit developer community, which creates a direct feedback loop between the product team and its users.

We think of the end-to-end experience and its complete ecosystem in terms of front-of-stage, what’s on stage, and what’s happening behind the scenes, or backstage. For QPP, here’s how the play is set up: front-of-stage and onstage, we do demos of the API with potential consumers, and conduct usability testing and user research with our various stakeholders and users. We also have a Google Group for 3rd party developers, and maintain a sandbox for health IT vendors. Backstage, we talk to the vendors who build out other services in the QPP ecosystem, and discuss how our various components should interact to meet their needs and support what’s going on front-of-stage and onstage. Keeping a pulse on everyone involved allows us to design a more holistic and empathetic service.

A lot of work goes into delivering government services that truly meet the needs of millions of people. Product management and service design can be especially transformative to how we work and ultimately, radically improve how people interact with government.