Why Government Digital Transformation Requires Product Thinking, Not IT Thinking
Lessons from leading technology for an organization serving 2.5 million citizens
When I became CTO for a state Department of Social and Human Services, I thought I understood transformation. I had spent six years at Amazon, scaled a $13B delivery business, doubled SaaS revenue at JLL Technologies.
I was unprepared for what I found.
The department served 2.5 million citizens across 72 different benefit programs. Each program had its own application process, its own eligibility rules, its own technology system. A family in crisis might need to apply separately for food assistance, healthcare, childcare subsidies, and housing support—filling out essentially the same information four different times, on four different systems, interacting with four different case workers.
The technology wasn’t the problem. Each system, individually, worked. The problem was that nobody had ever asked: What should this experience feel like for a citizen?
That question—the product question—changed everything.
The IT Mindset That Holds Government Back
Government technology organizations are, typically, IT organizations. This distinction matters more than it might seem.
IT organizations implement systems. They translate requirements into technology. They maintain infrastructure, ensure uptime, manage security. These are essential functions.
But IT organizations don’t own outcomes. They own inputs: systems delivered, tickets closed, uptime maintained. The outcomes—whether citizens actually receive the help they need, whether services are accessible and dignified—belong to someone else.
This creates a fundamental misalignment. When you’re measured on system delivery, you optimize for system delivery. You build what was specified, on schedule, within budget. Whether the specification was right in the first place is someone else’s problem.
The result is government technology that works perfectly—and serves citizens terribly.
I saw this pattern everywhere. Systems that met every technical requirement but required citizens to enter the same information seven times. Portals that passed every accessibility audit but were abandoned by 60% of users before completion. Applications that functioned exactly as designed but took 45 minutes to fill out.
The systems weren’t broken. The thinking was broken.
What Product Thinking Means in Government
Product thinking starts with a different question. Not “what system should we build?” but “what outcome are we trying to create?”
For government services, the outcome isn’t a system. It’s a citizen’s life getting better. A family receiving food assistance. A child getting healthcare. A senior accessing housing support.
When you start with outcomes, everything changes.
Instead of asking “how do we build an eligibility determination system?”, you ask “how do we help a family in crisis get all the help they qualify for, as quickly as possible, with as little friction as possible?”
The first question leads to a system. The second question leads to a service.
This might sound like semantics. It’s not. Watch what happens to decision-making when you shift from systems to services.
System question: Should we add a field for spouse income? Service question: Is there a way to get this information without making the citizen enter it?
System question: How do we ensure data accuracy? Service question: How do we reduce errors while respecting citizens’ time?
System question: How do we meet the requirement by the deadline? Service question: How do we measure whether citizens are actually being helped?
The system mindset optimizes for the organization. The service mindset optimizes for the citizen.
Case Study: Integrating 72 Benefit Systems
When I arrived, the state’s Health & Human Services Agencies operated 72 distinct benefit programs. Each had evolved independently over decades. Each had its own application, its own technology, its own rules.
A citizen applying for multiple benefits might interact with a dozen different systems. The experience was fragmented, frustrating, and often resulted in eligible citizens giving up before receiving help.
The IT approach would be: Modernize each system. Build APIs between them. Create a portal that accesses all 72.
We took a product approach instead: Design the experience a citizen should have, then figure out how to create it.
We started with citizen research. We shadowed families through the application process. We documented every form field, every handoff, every wait time. We mapped the emotional journey alongside the process journey.
The insight that emerged: Citizens didn’t care about programs. They cared about problems. They didn’t want “SNAP benefits”—they wanted to feed their children. They didn’t want “Medicaid”—they wanted their kids to see a doctor.
So we built a unified intake experience. One application. One set of questions. One case worker who could navigate across programs.
Behind the scenes, the 72 systems still existed. But the citizen-facing experience was unified. The system complexity was hidden. The product experience was simple.
The results: Processing time decreased 60% in pilots. Citizen satisfaction scores increased.
We didn’t modernize 72 systems. We built one product.
AI in Government: The Opportunity and the Risk
We were one of the first government organizations to deploy GenAI tools for case workers. The decision was controversial. Government AI deployments have been criticized for bias, opacity, and harm. Why take the risk?
The answer came from understanding what case workers actually do.
A case worker might handle 150 active cases. Each case involves reviewing documents, understanding complex eligibility rules, communicating with citizens, and documenting decisions. The cognitive load is enormous. The consequence of errors—families losing benefits they need—is severe.
When we observed case workers, we found that they spent 60% of their time on documentation and information retrieval, and only 40% on actual case work—understanding situations, making judgments, helping families.
GenAI could shift that ratio.
We deployed AI tools that could: summarize case histories, identify relevant eligibility rules, draft communication templates, and flag potential issues for review. The AI never made decisions. It made case workers more effective at making decisions.
The results: Case worker productivity increased. Average call wait times decreased. Case workers reported higher job satisfaction because they spent more time on meaningful work.
But we were vigilant about risks. Every AI output was reviewed by humans before action. We monitored for disparate impacts across demographic groups. We maintained explainability—case workers could see why the AI made every suggestion.
AI in government can be transformative. It can also be harmful. The difference is whether you’re using AI to replace human judgment or to enhance it.
A Framework for Government Product Leaders
If you’re leading technology in government, here are five shifts that enable product thinking:
1. From requirements to outcomes
Stop asking stakeholders what system they want. Start asking what outcomes they’re trying to achieve. Then work backwards to what technology might help.
Requirements capture what people think they need. Outcomes capture what actually matters.
2. From projects to products
Government technology is typically managed as projects: defined scope, defined timeline, defined completion. But citizen needs don’t end when a project ends.
Build permanent product teams that own citizen experiences over time. Give them authority to iterate, improve, and evolve based on feedback and data.
3. From procurement to partnership
Government procurement is designed to prevent corruption. It also prevents innovation. The rigidity that ensures fairness also ensures that what you buy is exactly what you specified—even when what you specified was wrong.
Where possible, build internal product capability. Where external vendors are necessary, structure relationships as partnerships with shared outcomes, not contracts with fixed deliverables.
4. From uptime to outcomes
IT is measured on system metrics: uptime, response time, tickets resolved. Product should be measured on outcome metrics: citizens served, time to resolution, satisfaction scores.
What you measure shapes what you build. Measure what matters to citizens.
5. From government-centric to citizen-centric design
Every government process was designed around government needs: what information do we need to make a decision? How do we ensure compliance? How do we audit?
Product thinking flips this: what experience should a citizen have? How do we make the process respectful of their time and dignity? How do we meet government needs without burdening citizens?
The Opportunity and the Obligation
Here’s what keeps me up at night: Government services are the last interaction with technology that hasn’t been transformed by product thinking.
Banking has been transformed. Retail has been transformed. Healthcare is being transformed. But applying for government benefits still feels like 1995.
This isn’t just an inconvenience. For citizens in crisis—families facing food insecurity, individuals dealing with health emergencies, children in need of care—government services are a lifeline. Every friction point, every abandoned application, every week of delay has real consequences for real people.
We have an obligation to bring the same product thinking that transformed every other industry to the services that matter most.
At WA state, we integrated 72 systems into one experience. We deployed AI that enhanced human judgment. We proved that government can deliver services that are not just functional, but genuinely good.
This is possible everywhere. The barrier isn’t technology. It isn’t budget. It isn’t even politics.
The barrier is how we think about the problem. Move from IT to product thinking, and everything changes.