It’s been five years since I first scrubbed in and started working on government problems. One of my early impactful experiences after moving to DC for a year in 2017 was taking a walk next to the White House with my friend Natalie and talking about the 21st Century Cures Act. In that huge piece of legislation, the words “Application Programming Interfaces (APIs)” are referenced a handful of times, a very important signal for government agencies and the healthcare industry to progress into a more interoperable existence. At that time, I didn’t have a clue about policy-making, the legislative process or regulation but soon came to understand the intersection of policy and product management is a fascinating place to work for a product manager and a core product muscle to develop.
In this space where policy and product meet, a product manager can find themselves helping write policy, implement policy or being subject to policy.
Examples:
- Writing policy – helping advise policymakers at a Federal agency, Congress or State Legislature on specific technical things or approaches. Ex: CMS Interoperability and Patient Access Rule
- Implementing policy – building software, websites and new teams to help a government agency implement some new legislation or regulation. Ex: Medicaid member experience, Paid Family and Medical Leave, Unemployment Insurance, the Bipartisan Infrastructure Bill, etc.
- Subject to policy – designing new product features for your business based on opportunities or requirements policy creates. Health data interoperability, privacy, crypto regulation, grant funding opportunities, etc.
For this post, let’s focus on Implementing policy.
How a Product Manager should think about Implementing Policy
Today, big pieces are legislation are treated as requirements documents in which different requirements are usually delegated out to various government agencies to implement. For example, in the recently enacted Infrastructure Investment and Jobs Act (IIJA), there are approximately 14 agencies responsible for 375 programs that will carry out provisions of the bill.
But…before going into implementing legislation as a product manager, a quick primer on the structure of legislation like the Infrastructure Investment and Jobs Act (IIJA).
The Structure of Legislation
The legislation is called an “Act”. Within the Act, there are divisions, titles and subtitles that have many sections.
Each of these sections can have highly prescriptive or super vague direction. For example, on page 1182 of the Infrastructure Investment and Jobs Act (IIJA) you’ll find a specific definition of “reliable broadband service”.
Often times, legislation is prescriptive as to how it should be implemented once passed. For example, the Colorado Paid Family and Medical Leave Insurance Act defines a new division be created within the Colorado Department of Labor and Employment to run the new program.
For the Infrastructure Investment and Jobs Act (IIJA), an Executive Order immediately followed the passage of the bill which established a Task Force.
The process sometimes feels more like art than science and can vary widely across levels of government and the type of policy being created. For example, in both Federal and state governments, the legislature (Congress) makes laws but federal and state agencies can create regulation. To further codify how a piece of legislation should be implemented, the Office of Management and Budget (OMB) may issue guidance to agencies that have “statutory responsibilities”. As you can see from this IIJA guidance from OMB, it further defines how everyone should coordinate with each other across government.
Products created by Legislation
Ok, now that you have a sense of the structure of a big piece of legislation, let’s talk about the products the signing of a new bill or publishing of a new regulation may hatch.
Imagine you are a product manager in the government tapped to work on implementing a new policy. Not unlike most products you’ve likely worked on, there is some type of vision or high-level goals (probably spelled out in the legislative text) and will likely need a website, community building, customer success and internal dashboards.
Website(s)
A piece of legislation and accompanying guidance will likely have a lifespan of a decade or longer. During these many years, state and local governments, territories, Tribal nations, non-profits, businesses, media and others will be learning about the bill. It is important to establish a source of truth for ongoing communication about the bill as the legislative text, once passed, is static on congress.gov.
For example, for Infrastructure Investment and Jobs Act (IIJA), the website Build.gov was created to provide a home for information about the programs that span infrastructure themes such as broadband, water and transportation. A PDF guidebook was also created that summarizes each of the programs. This website is just one web property in an ecosystem that includes:
- Build.gov – summarizes the Infrastructure Investment and Jobs Act (IIJA), PDF guidebook, searchable program inventory.
- Grants.gov – the application process for many of the grant programs funded by IIJA.
- Agency Program webpages – program specific information including application eligibility, notice of funding opportunities (NOFOs) and technical assistance. Ex: Bus and Bus Facilities Program from the Federal Transit Administration (FTA).
- Sam.gov – detailed information about each program (call an “assistance listing” in grant-speak).
Along with websites, as a PM you’ll be engaging with secondary sources of information, typically local and national media coverage as well as webinars, infographics and white papers put out by hundreds of associations and consulting or lobbying firms.
OKRs and Dashboards
A variety of data products such as dashboards, shared datasets and more are required to coordinate across agencies and manage a large piece of legislation effectively.
Usually, in artifacts that support the legislation or in the bill text itself, you’ll find some type of guidance or direction about how outcomes and impact should be measured. For example, in the IIJA Executive Order, priorities were defined. This means there also needs to be a way to measure and report on these priorities…which means data and dashboards.
Beyond using data to inform decision-making of the policy implementation, oversight needs to be considered from day one. Reports to Congress and readouts with stakeholders are important for PMs to consider.
Web apps
For legislation that directs funding, usually to state, local, territorial and Tribal governments or non-profits, some type of reporting from those entities back to the Federal government is required, which means you’re likely building a web app. As conditions change, these reporting and compliance requirements also evolve. As a PM, you need to be thinking about a reporting and compliance user experience that is easy for funding recipients. As I’ve talked with folks in all levels of government about grant funding specifically, reporting and compliance burden is always a complaint, especially for small governments without big teams to handle this.
Web apps to support legislation are tricky because many of them have been built in the past to support a variety of different types of legislation and the user experiences have been less than great. So, as a PM, you need to embrace the learnings from these teams and try and avoid building the next web app that most users don’t really like.
Another category of web apps you may find yourself building as a PM helping to launch new legislation are web apps that support some type of functionality required by the policy. In this example, the Quality Payments Program from the Centers for Medicare and Medicaid Services (CMS) supports regulation that requires healthcare providers to upload information via a website or integrate with an API.
Delivery Teams
New policy usually means new delivery teams are needed to build the websites, dashboards and web apps to support the policy. Depending on which government agency or agencies are tasked with implementing legislation, they may not have an operating budget to procure a software delivery team, purchase cloud infrastructure, run sophisticated digital marketing campaigns, and so on. For example, the White House and State Governor’s Offices are examples of structures that don’t have a ton of capacity to ship software versus Federal or state agencies who have a huge portfolio of software products, existing devops processes and cloud infrastructure, cyber security policies, etc etc. In most cases, having the delivery live within an agency of a shared services group like the Office of Information Technology is the preferred path.
As you get started as a PM on a new policy, regulation or legislation, work hard to get clarity on how the delivery teams will be structured. This will be hard as there’s a lot at stake and a ton of pressure to move fast.
Conclusion
Over these five years in government, one of the things that caused me to fall in love with this work is the sheer reach of it all. New legislation, policy or regulation has the potential to change an industry or impact millions of people.
This is also a space where I’ve seen firsthand the impact of “software is eating government” (a remix of the phrase coined by Marc Andreessen, the founder of Netscape). Software has begun to permeate every aspect of our lives and is fundamentally changing business models. We cannot afford to ignore technology as we deliver government services, this includes upstream in the policy-making process.
It’s a really good sign if you, the product manager, are part of the team tasked with implementing a new policy. When done right, your expertise in user experience, software development and product design combined with the brilliance and experience of the policy wonks and government experts has the potential to delivery something truly special.
Kelly Taylor's Blog 