Why defining your product is an essential question in government digital services

One of the most important questions in government digital services is “what is our product?”

The question’s simplicity hides an iceberg of assumptions and further questions beneath. That deception might be why so little attention is paid to its foundational importance.

The answer to this question seems easy. For teams building government technology, the product represents their mandate, their focus. It’s what they work on and improve every day.

The problem is we can misidentify where people derive value. The result is we become stuck in a cycle where we feel like we’re doing a lot of work by creating new features or prioritizing new projects while not moving the needle on our most important metrics. This matters to government technology for two reasons — resources are limited and the costs of not getting it right are too high.

To prevent these problems and remain focused on what it is that we want to to improve, we must be able to identify our products and their core components.

Trees, meet forest

So what is a product? A product is a means to an end, where the end is a service delivered to a person.

That service could be an appointment scheduled at a local Department of Veterans Affairs (VA) medical center or a renewed driver’s license. I’m a fan of the “good services are verbs” paradigm from Lou Downe, the former UK Government Digital Services Design Director. They advocate for an action-oriented mindset when building digital services and ridding government services of made-up, unintuitive names. I’d like to pay my taxes, not fill out a 1040.

A product is the thing people interact with to obtain the service. It’s typically software, but can extend “offline,” which to me is a different way of saying “in person.” For example, that driver’s license renewal probably started with a visit to the local DMV website — a product — and may continue at the local DMV center — also a product. Or take a Veteran’s medical appointment. It may start with a visit to online scheduling on VA.gov and extend to an interaction with a kiosk at the office — both products.

Products can be “hidden” too. For example, the API that provides a list of all VA facilities around the world. That API — a product itself — helps power other products downstream.

And don’t forget products that enable staff to do their jobs delivering services to people. These staff-facing products help them answer questions, track analytics, or process applications. While not visible to the public, they have critical roles in service delivery.

Product (noun)

So how do we know if what we’re calling a product is actually a product? There are key attributes a product exhibits that we should look for:

A product delivers — or enables delivery of — a service.

We discussed this first one. A product is a means to an end where the end is, for example, the timely education benefit a Veteran receives or the meaningful conversation a patient has with their provider over their mobile device.

A product has steady-state, or “evergreen,” outcome metrics.

These metrics measure the value created for people or the organization. They can track, for example, the number of successfully completed API transactions in the past seven days, the number of successful direct deposit payments made last month, or the number of newly onboarded team members. These outcome metrics are complemented by health metrics — clicks on a link or views on a page that can help a team better understand their product. These metrics are the heartbeat of a product. And while they don’t indicate value obtained, they are helpful signals of a user’s intent.

A product iterates over time.

Unlike a project, a product doesn’t have a defined beginning or end. Instead, it continues to improve over time. And teams use outcome metrics and qualitative data to understand the impact of their decisions and those iterations. The product lives in perpetuity until the organization deems it no longer worth further investment and is sunset.

There are many ways to improve a product.

It’s unlikely that a team only has one way to improve a given product. Instead, teams develop many hypotheses for how to make the service they deliver better. They use a product’s outcome metrics as a fulcrum around which they make multiple bets they think will make progress against those metrics. They rely on different discovery techniques to test their assumptions and use that information to shape the product. In some cases, it’s not enough to improve the existing product, and investment in new product development is necessary.

Products don’t exist in a vacuum.

In some instances, we find a hierarchy of products or products that exist in an ecosystem alongside other products. An example of this is VA.gov, which is made up of individual products such as the application for health care and the claims/appeals status tool. In this case, both the “macro” product, VA.gov, and the “micro” products exhibit all the qualities of a product. This attribute is a reminder to teams that there are external factors such as the sign up/log in experience that may or may not be at their disposal but will impact their product.

Compare and contrast

Now that we’re clear on what a product looks like, let’s compare it to things we often confuse with products: features and initiatives.

A feature is a critical component of a product. It cannot deliver the end service on its own but is considered a necessary part of the product’s overall success. An example of a feature is the sign-in process of a banking app or the ability to react to a Slack message using an emoji.

The other term we often confuse with a product is “initiative,” or project, which we’ve previously written about. An initiative is a team’s attempt to iterate and improve an existing service. A team prioritizes an initiative with a problem that aligns to an overall strategy, a hypothesis for how to solve that problem, and the expected impact of solving that problem.

One reason we might confuse these terms is that action is incentivized in product development. If a team isn’t developing, they’re not providing value. And that looks like new features and new initiatives to work on. But that team is supposed to do product development, not feature development or initiative development, and we end up in a place where all our work is on equal footing.

What’s the point

It’s not a trivial task to define an organization’s product. I often rely on the lowercase-p, uppercase-p framework from Shreyas Doshi. This framework includes a test to figure out what “makes or breaks the user value [proposition].” It’s a powerful reminder to stay focused on the uppercase-p – what people and the organization ultimately value.

We are deliberate about identifying our products so we can understand how well they enable the service. Confusing a product with a feature or initiative is a common pitfall. When this happens, teams optimize individual components or pursue temporary projects without an understanding of the overall impact on the product.

Teams that can identify their products are more likely to prioritize improvements in the best interest of the underlying service. And as a result of their work, Veterans, their family members, seniors, Medicare patients, and others have more successful and efficient interactions with the critical government services they need.