The Ad Hoc
Product Field Guide

When the government technology industry talks about digital transformation, it’s often centered around technology delivery. What are government agencies doing to build and invest in new technologies? How are government agencies taking advantage of technological advancements? When will the government use blockchain as the basis for delivering services?

It’s true, advancements in technologies can offer new ways for government agencies to effectively deliver quality services. But technology implementation alone can’t achieve this goal in a way that improves the lives of those dependent on these services.

As 18F’s research points out in defining “digital transformation”— modern transformation is beyond the scope of technology delivery. Instead, transformed agencies:

• Connect staff to an agency’s mission
• Apply technology toward that mission
• Commit to continued improvement

These characteristics uniquely fit with the application of product thinking and the discipline of product management to government digital services.

A deep understanding of user and customer needs is critical to digital services. Agencies will need to unearth these needs and align them to the vision and goals of the organization or use them to alter the goals of the organization to better deliver on their vision. Doing this requires ongoing engagement and feedback from users to validate what’s working, what’s not, and to pivot or continue working to provide something impactful.

That's where product thinking comes in.

In its simplest definition, product thinking helps organizations answer the question:

Is this effort (product, service, process) useful and valuable?

Product thinking is a mindset, competency, and a disciplined habit applicable to many settings. The benefit of product thinking is that it focuses work and teams on solving for the right problems given the needs of a customer while also driving outcomes for an organization.

Applying a product thinking mindset to government means intentionally focusing on the core users your agency serves. Product thinking requires identifying users’ unmet and underserved needs, systematically designing solutions to meet those needs, and validating the usefulness and value of those solutions with users along the way.

The success rate of government technology projects is estimated to be only 13%. Product thinking is one of the antidotes to these high technology failure rates. Here are the principles that underpin product thinking:

Product thinking is distinct from project thinking. Product thinking is about continuously prioritizing which problems need to be solved, and ensuring whatever is built actually solves those problems and achieves the desired outcomes for the organization and users. Project thinking is about prioritizing tasks to deliver a fixed solution within a set timeframe and budget and is common in government IT departments. In project thinking, success is measured by work completed, regardless of whether it solves the intended end user problem.

Moving from project thinking to product thinking can help agencies avoid serious risks to their mission while moving them towards becoming a mature digital organization centered on value creation and outcomes.

Power of product thinking in government

We don’t often talk about government technology in terms of value — but we should. Government agencies interact with the public through the services they offer, but government digital experiences are not always inherently valuable. It’s what these digital services do for users that creates individual and public value.

That value can be seen and measured in direct ways like how many people are able to access benefits or receive a passport. There’s also public value in improving how public institutions operate, such as improved transparency, effectiveness, efficiency, and employee engagement in federal agencies. At an even broader level, government technology can deliver value in the form of public trust in institutions and a strengthening of our social infrastructure.

To achieve all of this potential value, government technology must be focused on the outcomes it enables. The question for agencies must become “How does the design of a system, the work of a development team, or the priorities of a program office impact specific, measurable outcomes for people?” To accomplish that change and move away from a culture based around measuring the outputs and feature releases of technology teams, agencies will need to adopt product thinking.

Product thinking helps agencies think about technology in terms of value delivery and service enablement. It centers digital service and technology development on impact to people and outcomes for agencies. When someone uses a government digital service, this interaction has a direct impact on public attitude, trust, and perception of the government. The better an agency is able to quickly, effectively, securely, and correctly fulfill a user's needs, the happier, more whole, and more fulfilled the recipient is.

To have product thinking, you need a product

A product is a solution that creates value for a group of people — users (external and internal), stakeholders, organizations — by solving a problem or need. Digital products are software-enabled products or services that go through a series of evolutionary phases and are developed through iterative, incremental processes.

Digital products and digital experiences are increasingly becoming how government agencies interact with people to deliver services. Digital products have the following characteristics:

• Are specific offerings intended to meet a set of user (internal or external) needs
• Create unique value — directly or indirectly — for a group of people
• Are enabled by technology as a key role in meeting those needs and delivering that value
• Manifest as experiences where users (internal or external) and agencies exchange digital interactions
• Move through a product lifecycle of evolving, expanding, and maturing over time

Government agencies' digital products can manifest in a variety of ways:

Digital products are fluid, and their scope adapts based on feedback, outcomes, and analytics about what’s working throughout a product’s lifecycle.

Some of the world’s most successful software and digital services are built using a product-based approach. It helps increase the probability of success by validating and incorporating learnings throughout development. These learnings would be impossible to predict at the start of a product. This reduces failure risk and increases the likelihood of an efficient, easy-to-use experience.

Enter product management

Building valuable, equitable, and accessible digital experiences and products is hard. There are a lot of factors to consider when building or evolving complex, mission-critical services in a meaningful way.

Digital product development efforts in government often fail when they are:

• Treated as single, monolithic attempts where no user research or user testing is incorporated throughout the delivery
• Built primarily from the specifications gathered prior to the start of a project by internal agency stakeholders seeking to minimize risk
• Managed with traditional methods meant to enforce oversight instead of outcome delivery

To build stronger product thinking into technology teams and organizations, agencies will need to embrace a new function as part of their digitization efforts — product management.

What is product management?

Product management is a discipline for helping organizations build the right digital products in the right way.

Product management enables the continuous delivery of value and outcomes for both end users and the organization by focusing on user needs, performing contextual research, and then working with product teams to deliver solutions that meet those needs and achieve intended goals. It’s the role that puts product thinking into practice.

With digital products, it’s very hard to predict in advance what solution will work for end users. Given this, product managers are key to ensuring value delivery through digital products.

Product managers bridge strategy and delivery by leading stakeholders and teams in defining a shared vision and strategy for a product and prioritizing the work necessary to achieve those strategic goals.

Project manager	Product manager
Tactical-based role focused on outputs and resource management	Strategy-based role with focus on product outcomes and value delivery
Break down large projects into project steps and tasks	Research and discovery on problems and organizational goals
Balance agreed-upon constraints of scope, timeline, and budget	Set and manage product direction and strategy
Monitor and track tasks, risks, and requirements completion	Gather and prioritize requirements, feedback, and needs against organizational goals/initiatives
Report status and progress of project to stakeholders	Experimentation and measurement of product success
Monitor resources against set plans	Lead cross-functional teams

Product managers help lead teams in problem discovery and research, experimentation, and insights gathering activities for products. They also guide teams through iterative delivery throughout the lifecycle of a product while responding and adapting to customer needs, organizational goals, and market or policy changes along the way.

Product managers are responsible for ensuring the desirability, viability, and feasibility of a product — all of which create value for users and organizations. Success of a product and product manager is in achieving outcomes for users and organizations that result in added value or benefits.

Not only do good product managers understand deeply the needs and problems of a user, they also understand how a product or digital service advances the mission and goals of an organization. They do this by creating understanding and alignment for their team so that technical decisions are made with the right context.

Adopting a product-based approach to government technology development is an operating shift as much as it is a role, discipline, or process shift. As agencies continue their transformation efforts and technology continues to change, it will be increasingly important for agencies to advance their capabilities through product-based development. Product thinking pushes agencies to look at the purpose of legacy systems and digital products and determine if those technologies are delivering on that purpose in iterative, incremental ways using evidence-based research and validation testing.

This evolution will require a shift from the current project-based methods that most government IT organizations use. A project is a specific, temporary, and timebound endeavor that is usually broken down into a series of distinct, sequential phases based on predefined requirements. Projects, by their nature, are inherently fixed: fixed schedule, fixed budget, fixed scope. Applying sequential project management practices to digital products is often referred to as "waterfall" software development. Projects are predicated on the need to meticulously define system requirements prior to moving into product design and development.

In approaching digital products with gated, linear project steps, organizations often achieve the opposite of what they hope to get from a strict project management approach — risk management. Detailed upfront plans are baked with assumptions, and technology project requirements are passed from group to group until complete. It leaves little to no room for new discoveries or ongoing feedback of the digital product because the cost of change over time increases as the project timeline increases.

These are the risks project management fails to account for in government technology delivery outside of typical project risks like budget, scope, and schedule, adapted from the four risks Marty Cagan outlines for products:

Usability risk: The product doesn’t solve a real user problem

Viability risk: Building things that the agency does not need or do not work, resulting in wasted investment

Feasibility risk: The requirements inaccurately represented system and integration dependencies; can we build and evolve what we build over time with the skills, technology, and time we have

Public value risk: The poor digital experience could increase loss of trust in government and hinder policy outcomes by failing to meet users expectations

Instead, IT offices and digital services groups will need to adopt a product-based approach that allows them to serve as strategic enablers of the agency's digitalization and service goals. The success of an agency’s digitalization effort should evolve to be defined in terms of outcomes enabled, not outputs delivered. This requires driving technology investment from a place of vision, strategic objectives, and clear measures of success.

When government agencies adopt a product-based approach, they often see these benefits:

• Improved strategic alignment and communication between different teams, work streams, and levels across an organization
• Better risk and trade-off management
• Improved outcomes due to closer alignment to user needs
• Ability to pivot and iterate quickly on new, emergent needs or opportunities
• Decreased hand offs between product teams and operations
• Reduction in cognitive load and context switching, which leads to increased contribution efficiency and increased domain knowledge
• Improved ownership at the product team level and increased accountability for product/system performance, user experience, and product outcomes
• Increased team engagement, morale, motivation, and empowerment, which results in improved communication of dependencies, risks, and opportunities

The successful adoption of a product-based approach in government depends on more than the role of a product manager. It will require agencies to become more comfortable with faster and continuous delivery, experimentation, and responding to change. To do this effectively, the perspective of your teams and team topology will need to evolve from pure engineering to cross-functional, empowered product teams that have disciplines like product management, research, design, data, accessibility, security, and engineering.

These teams will work as autonomous units who have the context, clear mission, and defined decision space to make ongoing, informed product decisions. Over time, that will mean evolving and operationalizing product management at scale within your organization.

To help exemplify the difference between a project management approach and a product-based approach, we’ll use a hypothetical case study about a web application for a government agency. In reality, technology efforts are much more complex than what’s outlined below. This is for demonstration purposes only and does not cover every facet of a technology project.

Using a traditional project management approach, this retirement application project would pass through the hands of different teams based on predefined app specifications requested by internal stakeholders. The project would look similar to this:

• Analysts research requirements for the app, evaluate project requests, define costs, and receive approval for a prescribed solution by stakeholders in offices that oversee TSP and federal employee retirement. This analysis is based on desk research and stakeholder input and doesn’t include input from federal employees nearing retirement or TSP account holders.
• A project manager is assigned the app development project and allocated engineers. The project manager develops a project management plan against defined feature specs including a work breakdown structure.
• Engineers are handed requirements and deliver the requested app features against a set plan of activities the project manager controls.
  • Group one: Engineering-only front-end implementation team that develops the user interface and is heavily dependent on the work of group two.
  • Group two: An engineering-only team focused on backend services that implements the supporting API and data structures using the same general feature specifications plan.
  Without great coordination, there is a high likelihood that the user interface (designed without a designer) and architectures between frontend and backend quickly get out of alignment.
• Then the final application is handed off to one or two testers to perform manual functional testing. Use of the application with actual users would only happen once the application is fully released for public use.
• Most engineers working on the app are also working on other IT projects at the same time due to emphasis on high resource utilization.

The project manager reports out to business stakeholders on the progress of the app by showing where approved phases and specs have been completed and on what date. Since project managers are incentivized to manage specific scopes, the feature set is never decreased and the timeline balloons. This results in:

• Delays and corner cutting due to optimistic, inaccurate feature estimates leading to security vulnerabilities and costly future app rework
• Overengineering unnecessary features complicating the end user experience and increasing maintenance support and tech debt
• Poor app performance and quality assurance due to rushed manual testing as the final stage of development must be completed in a compressed timeline
• Frustrated users unable to complete vital retirement tasks resulting in public brand issues due to lack of user research or user testing prior to launch
• Decreased user adoption and user retention resulting in increased manual operational support costs and decrease return on investment
• Costly budget modification requests required to address user issues and performance concerns identified after launch to the public

With a product-based approach, definition of the retirement app’s purpose is driven from clear agency goals and outcomes based on user needs and behaviors. This is done by using a structured continuous discovery and delivery process centered on iteration and learning.

To be successful within this product process, the retirement app project is assigned a dedicated, fully cross-functional team — product manager, designer, researcher, frontend and backend engineers — who can take the retirement app from idea to launch to next iterations within the existing budget cycle.

• Align and prioritize
  This product team — led by a dedicated product manager — would start by working with TSP and retirement office stakeholders to align on agency goals and objectives relating to this retirement application and define anticipated outcomes the agency aims to accomplish by launching the app. For example, the team would define clear objectives and measures for the app:
  • Objective - Increase number of users engaging with online retirement tasks.
  • Metric - Submission of digital deposits increases by 20%.
• Discovery
  From there, the team would perform “problem discovery” to learn how target users are managing their federal retirement accounts and what problems they’re encountering. For example, performing user research sessions with potential users of the application to understand their current pain points and then map out both current and future state user journeys. This forms the basis for any assumptions or hypotheses the team should test as part of validating their proposed solution.
• Define
  Using what they’ve learned about both retirement users and the agency’s goals, the product manager and their team would define and prioritize key initiatives — usually on a monthly and quarterly basis with stakeholders — for the team to work on. As part of these initiatives, the team would clearly frame user goals and problems being addressed, define success metrics, and perform initial technical discovery including documenting open questions and dependencies. These initiatives, represented on a product roadmap, would then be broken down into units of work that the product manager prioritizes for the team in the product backlog.
• Deliver
  At the build phase, the team would take a hypothesis-based approach to solutioning so that they can base decisions on data, rather than intuition, and so they can iteratively test whether what is developed for a retirement fund management experience meets and exceeds the expectations of users and stakeholders. Based on the prioritized product backlog, teams would define experiments — via prototypes or a minimum viable product (MVP) — to validate solutions with actual intended users of the app. Based on what they learn, teams would build the initial version of the app with a focus on the fund management workflow for example. They would then test the prototype or release a MVP through a (canary) release to a small, but statistically significant group of end users to test and validate the solution in production. This helps minimize failure risk by delivering iterations of the app over time instead of infrequent large-scale deployments.
• General public release
  Once the team has validated that the initial app workflow for fund management is solving the right problems and showing promise toward the target outcomes, the product manager would work with agency staff to prepare a phased launch strategy for introducing the new retirement application in its initial state. This first launch could be in as little as a few weeks or months depending on the scope of the MVP.
• Measure impact
  Once fully launched, the product manager and team measure the impact of the application against the metrics and indicators set during alignment and prioritization. The goal here is use data and feedback to show teams and the agency what’s working, what’s not, and where to focus next.
• Start cycle again
  While the release of the recent iteration is live and creating data, the team essentially starts the cycle again by kicking off their next initiative and leaving room to come back to feedback captured in the recent release.

Since the product manager was incentivized to continuously iterate towards the most desirable and successful solution, the app’s features were always prioritized for critical capabilities based on user feedback and agency goals. This resulted in the following:

• Decreased development cost due to increased confidence in the solution direction
• Improved risk and tradeoff management through frequent release cycles with targeted user testing and performance evaluation throughout development
• Reduced complexity and future maintenance cost by minimizing the development of unnecessary features through continuous prioritization
• Increased probability of product success based on frequent feedback loops from users and stakeholders
• Direct traceability of product releases to user impact and organizational outcomes

When an agency adopts product thinking and a product management approach to technology development, they move away from overly prescribing the actions a team should take to orienting teams around common and prioritized outcomes for a solution to achieve. Below, we’ll illustrate how this shift in thinking and approach looks at the highest level of technology work — defining and measuring success — down to the day-to-day impact on the skills required for effective product teams.

Measuring success

At the highest level, moving to a product thinking approach changes how teams and organizations define and measure success. When using product thinking, success is based on the “outcomes” an organization is trying to create with that digital product. Outcomes are measurable changes — such as a change in user behavior or improved results — towards solving a problem or meeting a goal. Outcome metrics are what you use to evaluate whether that change occurred.

An example of a product outcome is building an application that helps a user reduce the time it takes to apply for benefits from 30 days and multiple paper documentation forms to a 10 minute online submission and 2 days of processing, which saves a government agency 3 times what it typically costs to process a paper application.

In project management, success is dependent on outputs, such as how well the project was delivered on time, in budget, and against the initial scope set at the beginning of the project. Often in government, a product may meet output-based criteria while failing to meet outcome-based metrics. For example, a government service that uses the required technology, has all the designated user flows, and meets Section 508 compliance, but where users can’t complete the process because the website keeps crashing.

Using this example, if you were to focus on output metrics alone, you wouldn’t get a clear sense as to whether what you created had any real value for either users or the organization. You would really only know that, given the specs for the app, it was completed and launched.

Outputs are still an important part of the product development process, but they are not the main indicator of success. Everything in the product development lifecycle should stem from a clear understanding of what problems are being solved and what outcomes are being enabled, and output metrics should be evaluated in service to getting to an outcome. This is a substantial shift in reporting, goals, and metrics for project-based organizations and should influence a number of other changes as teams adopt a product thinking approach.

Product roadmaps vs. Gantt charts

Agencies that adopt a product approach will need to move towards using product roadmaps as a critical tool to represent the overall direction of the team’s work. Product roadmaps help ensure teams and stakeholders are aligned and working towards the same goals. A roadmap is not a project plan. Whereas a project plan focuses on specific deliverables and the status of each one in relation to time, a product roadmap is most useful when it’s focused on strategic themes and outcomes rather than strictly features or deliverables.

In contrast, project-based organizations often use Gantt charts to visualize the typical steps — like planning, design, and implementation — and the tasks to be completed for a given project given a specific time schedule. They’re linear and try to capture dependencies between tasks. The goal is to show the work that’s been completed and the work that remains before the team can start the next step of the project. Much like project management, Gantt charts are about the “who”, “how”, and “deadline.”

Product roadmaps represent the high-level direction and strategic objectives and initiatives being undertaken by the product over time. They represent product strategy in the form of initiatives and opportunities and help communicate the "why" and projected “when” behind product efforts.

The difference between what Gantt charts and roadmaps intend to communicate is a great example of the change in how teams organize their work when agencies move to a product-based model. Roadmaps assume that change will be constant when building digital products and offer a way for teams to accept change without losing sight of overall objectives and priorities.

Setting priorities and defining the work

In a product-based approach, all things stem from the goals and outcomes agencies want to enable. That includes how actual development work gets prioritized and defined. This is one of the biggest differences between a project and product management process: how information is collected and then distilled down to drive the creation of digital products. In project-based organizations, work is often defined by a list of requirements. As organizations move towards a product thinking approach, they’ll need product managers to facilitate a new way for teams to set priorities and define their work.

The work of a product manager is to close the gap between what is needed for the user and what is viable for the organization.

Product managers are focused on defining why the work is needed: understanding the problem to be solved and setting direction for the team based on changing goals, needs, and constraints.

They do this by following an iterative, continuous process of prioritization, research, building, and evolution. Instead of working with analysts to create requirement traceability documentation to prove how requirements have been fulfilled, a product manager will lead stakeholders and teams through a refinement process.

They will learn and gather context about needs — including policy mandates, data, and ideas — and work with stakeholders to refine those into workable objectives and supporting initiatives. These initiatives are problem-focused and outcome-driven. Product managers will often deploy a prioritization framework to help identify what initiatives are the priority using frameworks such as: impact vs. effort, value vs. urgency, or an adaption of the RICE (Return, Impact, Confidence, and Effort) scoring framework.

With some prioritization set, the product team will work with the product manager to ideate possible solutions and then form experiments or "bets" to test if the solution idea helps solve the problem or need. These “bets” and initiatives are broken down into bodies of work in which the product team would tackle as part of their validation and delivery.

Requirements still come into play in product management, especially as it relates to data, security, policy and business rules. But requirements are a part of both problem and solution definition by the team after priorities have been set by the product manager. Shifting away from a predefined set of requirements can be a major shift for leadership, but it is critical to achieving the product approach goals of reducing risk and delivering value to users.

Using validation and iteration to inform product decisions

As mentioned in the book Inspired by Marty Cagan, when it comes to product development there are two inconvenient truths:

1. Half of product ideas will not work.
2. For the ideas that do work, it often takes multiple cycles of iterations to get the product to a place where it’s delivering consistent value.

Given this, it’s easy to see why and how government technology projects can fail. Projects are often framed on the premise of high-level assumptions about what’s needed, how it will be used, and what it will take to build — oftentimes without input from the experts who will do the work and users who will use the product.

To complicate matters, in an effort to minimize risk that is inevitable to a product development project, projects rely on over documentation of requirements to minimize schedule and cost overrun. This incentivizes project managers and stakeholders to micromanage productivity of teams against these requirements.

By moving to a product-based approach, agencies can more honestly accept these truths of uncertainty and iteration and build processes to manage them. A product-based approach focuses on validating ideas and features early and often through discovery and iteration. When working on an initiative or epic, teams use an “experimentation”’ lens to articulate and test their hypotheses.

In the early stages of a product, teams use validation techniques to test problem-solution fit. This helps teams answer whether this is the right problem to be solving, and what solutions are most appropriate for solving it, like Ad Hoc did with the VA to ensure a mobile app was the right solution to help Veterans.

You can use techniques such as customer research interviews, low or high fidelity design prototypes, and even simple sign-up forms. The output of this discovery is a refined problem statement, clearer specifications on a solution people seem willing to use, and evidence to support the team’s confidence that those specifications are right.

Even as teams begin building an early product, they’re still validating and learning. Product teams will perform direct user testing with a set of users, set up and run A/B tests, or perform phased rollouts to assess user adoption funnels. They’ll use analytics and data to highlight insights and combine those insights with direct user feedback. What the team learns will inform plans for the next iteration of the product or feature in a way that maximizes what is needed for those using the product instead of what they think would be good for a user.

Each validation cycle is building evidence and insights to inform what teams do next with the product. This is something that cannot be captured in upfront planning of digital technologies. Enabling a continuous loop of learn, build, and measure for an idea through iterative product development increases the probability of success that what you’re delivering will create the intended impact.

It works the other way as well. If you learn quickly that your solution is not worth investing in, you can deprioritize those efforts in lieu of working on what creates the right outcomes. This results not only in improved user experience and adoption, but it also minimizes costs related to over developing a product or feature and decreases technical debt and future refactoring complexity.

Skills required to manage a team’s work

At the individual team member level, moving your organization to a product-based approach will require new skills and roles that don’t exist in a project-based team. While people with project management skills will be required for certain tasks, agencies will need to hire or train for new product management skills to effectively adopt a product-based approach.

It’s common for teams to confuse the roles of project and product manager. Both require attention to detail, strong time management skills, and the ability to break work down into manageable chunks. Project and product managers must be able to solve problems given constraints and proactively manage risk. They also both require ongoing coordination and frequent communication with other stakeholders beyond the immediate product or project team.

But the difference is in where they focus their attention, how they approach their work, how they manage success, how they respond to new information or change, and the type of information they communicate to stakeholders.

Product managers are responsible for the overall success of a product - making sure its solving the right customer problems in ways that enable agency goals. They’re accountable for helping develop a vision, strategy, and plan for iterating on and releasing a product with a cross-functional team. Product managers also play a key role in helping take products and new features “to market” for use by intended customers and users by working on a community management strategy and a multi-channel marketing strategy with communication teams.

With the context of both project and product management, it’s important to recognize that product thinking isn’t better than project thinking. For software and product teams to be successful both types of thinking will be required, but it’s where agencies apply their emphasis that matters most.

Product thinking focuses on the why, what, and probability of success using customers and users as the focal point. Project thinking focuses on the when, who, and how of a technology solution. Product thinking enables long-term product capability development, and product managers will use components of project thinking to accomplish iterations and feature development that are in service to this long-term vision.

Products and their features go through rounds of improvement called iterations. Releases of these improvements are often managed as temporary endeavors – or projects. Additionally, releases vary in impact and often require coordinated efforts with other team members beyond the product team. All of these activities fall within the traditional bucket of a project and project management, but they’re part of the product development process and take direction from the product vision, strategy, and roadmap – all of which are owned and managed by a product manager.

A project and the project lifecycle are a subset of the product development cycle.

Project management activities also show up in other roles on cross-functional product teams:

• Scrum master responsibilities
• Designers working through iterations
• Engineers tasking and planning sprint work

Those roles are empowered to assume those tasks as part of owning the product work together.

There are also situations where a project-based approach to software development is necessary. For example:

• When agencies are working to implement commercial, off-the-shelf software
• When sunsetting technology and migrating content to a new platform
• When changes are required to a product due to integration with other 3rd party products or services

Even then, these situations should have requirements that are stable and fully known, and these efforts should still be in service of larger outcomes and product strategy that keep user and organizational needs at the center.

In these cases, it’s important to understand the intent and role of a project manager who is working with a product team. Clear role responsibility and definition is important and sometimes accomplished by establishing working agreements within the cross-functional team or via tools like a RACI matrix.

The role of government project management still exists – especially as it relates to contract management or program management. Project or program managers collaborate with product managers as needed to ensure that initiatives within a product development process are within the scope of a government contract including resources, timeframe, and reporting requirements, both for stakeholders and for governance and contract compliance.

Additionally, a project or program manager can team up with product managers on intra-agency coordination of strategic projects that have definitive budgets and timelines, such as a product launch marketing and communication plans. With large technical endeavors, product managers and project or program managers can work as a powerful duo when they have clear responsibilities and clear decision spaces.

There are practical steps government technology teams can take today that help start the journey from a project- to product-based approach. In fact, we encourage you to start small, build momentum, and iterate to test what works, find what you need to account for when evolving to a full product-led organization, and start practicing the product thinking behaviors of your agency or department today.

When starting this transition, consider the 5 Ps to product-led organization strategy:

The transition will be gradual, and we recommend the following as a potential blueprint to get started:

1. Approach moving to a product-based model as an experiment

   This can help you align internal leadership support around the effort. Define goals, outcomes, and hypotheses the organization has about adopting a product model. This doesn’t need to be overly complex, but it should focus on testing hypotheses you have about how moving to a product-based approach could bring value to your end users, stakeholders, software teams, and office or department culture. Ensure there is leadership buy-in on moving toward a product approach.

   Identify a leader outside of your IT organization who is bought in to support a product approach to technology development and can serve as an organizational champion outside your team.

2. Pick a product

   Identify one to two products or work streams within a subset of your department that are of strategic importance to the agency and are actively being worked on now or in the next 6-8 months. Don’t get overly caught up in the definition of “product.” Remember a product is a solution made to satisfy an end-user problem or need that also creates unique value for an organization. That means the product could be a specific experience flow on your current agency website used by people seeking government assistance, an internal staff application, or digital services as part of a platform or infrastructure as a service model.

   A framework tool you can use for identifying your product(s) is by focusing on the following matrix:

   

3. Build your team

   Based on your product or work streams, determine the skills and abilities you need to create this product, and then assign a dedicated, empowered, cross-functional team led by a dedicated product manager. This team should be made up of at least the following capabilities: product management, design, engineering, and research. Additionally, data and analytics should either be represented on the team by the product manager or a dedicated person over time to measure and maximize the use of data within your product.

   For a product team to be “empowered,” they need to be:

   • Autonomous in that they can own the full lifecycle of a product as a team
   • Stable in that people are dedicated full time to the product vs. being shared across different projects
   • Focused on solving problems and accountable for the outcomes they deliver
   • Organized around shared mission, goals, and ways of working

   Most agencies making this transition to product don’t have product people in house. We recommend that you tap into your contracting partners and request specific product management support and pair those folks with your designated internal product lead. We’ve seen this pairing be an effective way to develop the internal product capacity needed to scale product thinking across an agency.

4. Define the problems and needs of the product in relation to goals, constraints, and policy requirements

   The product manager should begin by setting the stage for your stakeholders and team. This includes working with their cross-functional team and counterparts on:

   • Establishing a clear vision, mission, and north star for the product that includes key design principles that all team members and stakeholders will operate from.
   • Building context around the problem, such as comparative analysis, organizational constraints, and interdependencies to get a systems understanding of how this problem manifests in the larger service and specifically within the context of your product.

5. Prioritization and iteration

   Product managers should use tools such as Value vs. Urgency/Cost of Delay or scoring frameworks like PRICE (Policy, Reach, Impact Confidence, Effort) model to help determine the highest priority problem to solve. This should manifest itself in two ways: product roadmaps and product backlogs.

6. Outcome and value delivery

   Product managers should define the target hypotheses of product initiatives, define objectives, set metrics, and use data to evaluate success of product efforts. These should all be focused on the outcomes the product enables for users, rather than the output the team delivers.

   They should monitor and measure the impact of the product against the goals and objectives set by the product. This measurement should be based on metrics set to evaluate the success of the product after delivery instead of focusing on outputs and activities of the delivery process.

7. Use a continuous learning and iterative product delivery process

   Using human-centered design principles and agile methods, focus the delivery work around outcomes and use agile decomposition techniques to break these outcomes down into achievable software delivery increments. This often looks like: Outcomes (Themes), Initiative, Epics, User Stories, Tasks.

   Use that decomposition to build out iterations or releases that are organized into sprints. The team can use agile methods like Scrum or Kanban to deliver on the goals and work tasks for each sprint.

8. Make the team’s work visible

   This should be a natural byproduct of having a dedicated cross-functional team using iterative, agile processes. However, it’s important to keep the work visible via accessible backlogs, Kanban or sprint boards, and an ongoing cadence with stakeholders — often monthly — to review the product roadmap, product analytics and insights, and progress on specific initiatives. Working in the open is a principle that helps shed light on the team’s work while encouraging more transparency between teams.

   As part of the team’s operating cadence, there should be ongoing demos or reviews — often held every 2 weeks — that showcase working prototypes or software as part of the product. This helps show the progress of the work while also opening up the opportunity for testing and feedback as the work is progressing.

9. Trust the process and give the experiment at least 6-8 months

   It’s almost a sure thing that you will encounter some barriers along your journey to product-based development. Using this small experiment, you can test out the product model without making sweeping organizational changes. Over time, this will lead to value and understanding in the product approach and influence more products and teams.

   Remember, this is a mindset and cultural shift as much as it is an organizational shift. In doing this experiment, you’ll see these behaviors in action, learn what will work best for your operating context, and show what’s possible to your organizational peers who are dependent on you and your team's skill sets.

   Lastly, don’t forget to celebrate the wins of the team and the product process along the way no matter how small!

Digital products are becoming the primary way government agencies interact with the public. When done well, digital products can allow the government to quickly adapt to a changing world while providing services people need in a way that builds trust in government.

For this to happen, agencies will need to shift from project management methods to a product-based approach. They’ll need to apply this approach to everything from evaluating problems to hiring digital services team members.

If agencies adopt all the latest technologies and replace every last legacy IT system, they still won’t be able to become modern digital service organizations without adopting an outcome-focused, product-based approach.

Product thinking is the core method to allow agencies to develop sustainable, useful, and equitable government technologies. Without it, agencies are destined to repeat the risks and failures that have become common in government technology.

Ad Hoc has helped many government partners make this transition as part of their digitization efforts. We know firsthand how applying product thinking and product management practices can enable agencies to transform how they use technology to bring value to people and achieve their mission. Product thinking is baked into the approach of Ad Hoc’s cross-functional teams, and we’re ready to coach, train, and work alongside government leaders on product best practices as part of our work together.

Moving to a product-based approach is a major change for government agencies, but it’s the key to digital solutions that drive sustainable impact, and Ad Hoc is ready to help agencies make that change.