Using product management to meet user needs and business goals on Search.gov

What we did

This is where Ad Hoc, Fearless, and the Search.gov team came in. Maturing the product management processes within Search.gov helped us navigate the constant uncertainty and infrastructure upkeep that define the site. We began by identifying three key aspects to guide our work:

• Setting a north star
• Segmenting users
• Establishing a decision-making framework

This first critical step determines where Search.gov is headed and what success looks like. Agreeing on this metric provides a common sense of direction and purpose. When we want to upgrade, build, or fix something, we ask: how does this align with our north star?

Search.gov’s north star is similar to many private-sector products: increase market share. As a taxpayer-funded product, efficient resource use is a key underlying principle for Search.gov. We can help agencies avoid tens of thousands of dollars in costs by transitioning them from paid services to Search.gov’s free indexing technology.

Search.gov has two user types:

• Site administrators (who customize their agencies’ search experience)
• Searchers (who actually use the search boxes)

User focus and segmentation are crucial because every feature should impact as many users as possible.

The team grouped our users into four broad categories along with attributes of technical fluency and engagement. In segmenting these characteristics, we see that each quadrant accounts for a different level of traffic:

Building this chart has allowed us to recognize and seek new voices in the user feedback process. Before, we tallied customer requests for features. We now weigh customer requests by the amount of traffic they carry so that we can frame our thinking around improving as many customers’ experiences as possible.

Another key to Search.gov’s product thinking is the decision-making approach. Search.gov prioritizes its problem spaces through a gap-bet scoring process. Gaps (the problems) are matched with bets (potential solutions) and then ranked in order of importance through a series of steps. In some cases, the bet is obvious. If the gap is “a version needs upgrading,” then the bet is “upgrade the version.” But in other cases — rebuilding our entire search results page — the path is less clear. Bets are ranked on:

1. The tech value
2. The level of effort
3. The certainty to their estimates

It’s human nature to prioritize items we hear about more often or issues we see more frequently in our peripheral vision. For example, because our developers came across old pieces of our code base so often, the team’s instinct was that legacy code was the number one issue to address. But when we scored the gap, it actually ranked much lower than expected — and forced us into reflecting on what was actually our most urgent work.