The Key Role of Product Owners in Federated Data Projects

During a recent 10x program engagement, we experienced just how difficult it can be for agencies to create technology resources that stretch across government. Every agency has its own set of processes and methods and tends to develop solutions that work for their own particular use cases. This means agency-specific solutions can’t easily scale for use across government. The current state is a disparate technology resources development process, which often fails to yield government-wide reusable tools and repeatable processes. We believe the main solution to this issue is an emphasis on the role of product ownership in a cross-agency development process. Dedicated product owners — meaning those that are empowered, well-resourced, and committed to developing cross-agency projects on a permanent basis — can bridge disparate resources and help federated data projects succeed.

The formula: cross-agency work plus dedicated resources

Over the course of 10 weeks, we investigated if cross-agency data-sharing could improve with a tool that automatically generates data user agreements between government agencies. The “data user agreement generator” (DUAG) was a proposed tool that would standardize the language of data agreements between agencies, automate the data agreements writing process, and ultimately streamline the data sharing process. This tool could help data requestors at agencies assemble agreements via vetted data clauses tailored to each data request situation. 

Through this research, we found that many agencies and working groups were using different methods to solve the same problem — creating a new standard for data sharing agreements that would streamline the lengthy legal review process and avoid disputes over language and clauses. We also found that most of the work was done on a voluntary basis on top of other job duties. There were few dedicated human resources to solving the problem, so progress on data agreement language was slow and efforts were duplicated across agencies. 

Agencies often approach this problem from their unique perspectives, eliminating a broad use case. Different agencies have different regulations and laws that apply to their data, as well as different interpretations of those laws by their respective Offices of General Counsel and Privacy Policy teams. A universal template for data agreements would need approval from these agencies’ offices as well as from regulatory offices like OMB. An agency might develop language that serves data sharing within their own sub-agencies, but this language may not be appropriate for other agencies’ use. In addition to regulation differences, agencies deal with different volumes of data requests with different processes. A tool developed in one agency won’t necessarily fit the process of another, which is why a tool should be developed that can scale across agencies and be adaptable to many different use cases. 

Working across government agencies can mean slow progress and few dedicated resources. In the DUAG case, we found a working group within the Data Exchange  Community of Practice (DXCOP) was developing a universal data user agreement to solve data agreements language issues. Although the members of this group span agencies and are developing a standard for data user agreements, their work is voluntary and is often sidelined by the duties of their main roles. Thus, progress on the universal data agreement is limited by the lack of dedicated resources.

For the DUAG, the two pieces of the puzzle for a federated solution were in place, but separated — there was a volunteer cross-agency group that could work with groups based in individual agencies with time and resources. A dedicated product owner could work here to bring these disparate efforts together, set a roadmap for the product, and build these group efforts to a unified outcome. 

While both 10x and 18F can be proxy (or temporary) product owners, the efforts to build consensus across parties and get buy-in from regulatory stakeholders on data agreements would likely take years — far beyond the capacity of a 10x engagement. Other similar federated projects might take significant time and dedicated funding to complete as well, and will similarly fail without sustained product ownership.

Product ownership creates federated resources

The U.S. Data Federation, another project funded by the 10x program, is an example of product ownership in a cross-agency space that successfully launched and passed on to a dedicated product owner. In a blog post post introducing the project, Julia Lindpaintner writes “the U.S. Data Federation Project seeks to address the need for knowledge sharing, repeatable processes, and reusable tools for federated data efforts. Its goal is to make it easier to collect, combine, and exchange data from disparate sources.”

The Data Federation took up improving resources.data.gov, a website initially created as a repository of tools and practices that may be useful to others. The Evidence Act and the Federal Data Strategy initially established resources.data.gov as a home for Federal Enterprise Data Resources, data standards, and data tools. 

In July 2020, the 10x U.S. Data Federation Project revamped and relaunched resources.data.gov and added a new data tool — ReVal, a data validation tool that helped state agencies in the National School Lunch and Breakfast program standardize data submissions to the USDA Food & Nutrition Service (FNS). This product relaunch marked progress toward two main goals in this effort — 1) creating a home and platform for standardized tools, practices, and processes that agencies can use or adapt to their specific needs, and 2) remedying the current situation, in which multiple agencies develop their own solutions from scratch. The FNS and U.S. Data Federation project teams owned the project’s development as a team and ensured its cross-agency relevance with the help of 10x seed funding.

The Data Federation and 10x team served as proxy product owners to stakeholders who had limited bandwidth to develop resources.data.gov and ReVal. After the temporary team got through the relaunch, the stakeholders were able to take over full ownership of the project and became its dedicated product owner for future efforts. The Data Federation project shows that product owners play a critical role in shepherding reusable, adaptable tools like resources.data.gov and ReVal to use across government agencies. 

Steps toward product ownership

Technology projects with wide-ranging applicability in government often have temporary funding or lack dedicated resources to build and maintain sustainably. Both 10x and 18F can kickstart federated engagements, but 10x projects are staffed on a temporary basis — they are meant to pass on to partners to own, maintain, and evolve the product as user needs change. In the case of federated efforts, a dedicated product owner can ensure that these efforts progress and endure beyond initial investigation.

There are some heartening steps in this direction. Data.gov is hiring an Open Data Specialist to work with federal agencies to build data standards, develop resources.data.gov, engage stakeholders and the federal open data community, and lead Federal Data Strategy projects. Since data.gov focuses on open data, the role seems to be a product owner and steward for building best practices around open data in government, which could include the development of federated data tools. 

As for a federated tool like the data user agreement generator, a similarly dedicated product owner role could help to determine the widespread demand for a tool, set the scope and a roadmap, and lead the development of the tool, ensuring its applicability across agencies. In addition, a dedicated product owner would do the work of building support for the legal changes, standards, and best practices for data agreements that will stand behind the parameters of a data agreements software tool. This role could be located in TTS, GSA, or even OMB, but the role should sit in an agency that has authority to influence and set government-wide standards and practices. As the 18F De-risking Guide states, “A product owner is empowered by their agency to represent stakeholders in making rapid product decisions without the need for many layers of approval.”

The opportunity to build tools and practices that benefit and reduce duplicative efforts among government agencies is clear. Funding an empowered, dedicated product owner and supportive team could truly move federated technology efforts forward and bring government technology efforts a step closer to goals like efficient cross-agency data sharing.

Thank you to Elisa Chen, Peter Rowland, Hyon Kim, Mike Gintz, Will Cahoe, Nico Papafil, Daniel Raudonis, and Jeff Durland for providing suggestions and feedback on early versions of this post.