Product Thinking in Government Software

Building software for local governments is a different discipline than most product work. The users are real public servants managing real public money. The stakes are low-drama but high-consequence. And the definition of a "good product" gets complicated fast.

I've been at it long enough to have opinions about what makes this space interesting, and what makes it hard.

The stakeholder layer is legitimately complex

In consumer software, you have users and you have the business. In enterprise SaaS, you add a procurement layer. In government software, you have something else entirely: a web of elected officials, department heads, finance directors, IT administrators, and sometimes the general public — all with different and sometimes contradictory definitions of what "good" looks like.

The finance director wants GASB compliance and audit trails. The department head wants to understand their budget without a training session. The mayor wants something they can explain at a council meeting. These are not the same product.

Learning to hold all of that at once — without defaulting to just satisfying the loudest voice in the room — is the real skill.

Transparency as a product value

There's something I find genuinely meaningful about financial transparency software. When a local government publishes a clear, navigable view of how public money gets spent, that's a small piece of civic infrastructure.

Most people will never use it. But some will. A journalist covering a budget story. A resident trying to understand why the park renovation got cut. A new council member trying to get up to speed.

Building tools that make that possible — even if only a few hundred people ever open them — feels like work that matters in a specific, concrete way.

On the pace of change

Government software moves slowly. Procurement cycles are long. Change management is harder when your users are underfunded and under-resourced. You learn to ship things that are genuinely stable, to write documentation that doesn't assume prior knowledge, and to design for handoffs — because the person who rolled out your product may not be there in two years.

This slowness is frustrating sometimes. It's also a forcing function for quality.

I don't think government software is the most exciting corner of the industry. But it's the corner where I've learned the most about what "useful" actually means.