From Project to Product: A Mindset Shift for Government IT
If you work in government IT, these scenarios probably feel familiar:
- Endless request queues with no clear way to prioritize what actually makes a difference
- Timeline extensions that erode trust with your partners
- "Successful" failures where you deliver on time and budget, but the core problem isn't solved
- The IT "black box" where partners see you as order-takers, not strategic thinkers
These aren't failures of individuals. They're symptoms of a system designed around the wrong model.
The Assembly Line Illusion
We think we work like an assembly line—orderly, predictable, efficient. Requirements come in, solutions go out.
The reality is more like a game of telephone. By the time a request moves through multiple handoffs, the original intent gets lost. The person who receives the final output wonders how it got so far from what they needed.
What we actually need is a team sport—coordinated players moving toward a shared goal, adapting in real-time to what's happening on the field.
Pulled in Every Direction
When success is defined by appeasing competing stakeholders rather than delivering impact, teams spend their energy balancing internal priorities instead of maximizing public value. There's no single, clear direction of "forward."
Government IT often exists between two competing systems:
Projects: Temporary efforts with their own processes, roles, and responsibilities. Managed by one group of people.
Operations: Ongoing work managed by different people with different processes and responsibilities.
Staff get caught between these two systems with no way to reconcile them. The result? Friction, handoffs, and finger-pointing.
The Core Problem: Temporary Efforts vs. Enduring Value
Here's the fundamental mismatch:
A project is a temporary effort to deliver a specific output—a system upgrade, new feature, or installation. It has a defined start and end.
A product (or service) is an ongoing capability that delivers value to people. It evolves continuously.
The problem: We treat enduring services like healthcare systems, data analytics platforms, or HR tools as temporary projects. We fund them, build them, and "operationalize" them. But the user's need is continuous, evolving, and always increasing.
When the project ends, the learning stops. The team disbands. Knowledge walks out the door. And the service slowly deteriorates until someone funds another project to fix it.
The Shift That Changes Everything
Moving from project to product thinking changes everything:
| Project | Product | |
|---|---|---|
| Mindset | Outputs | Outcomes |
| Goal | Deliver a thing | Create a change |
| Metric | On time, on budget, built to spec | Measurable improvement in user metrics |
| Statement | "We built what you asked for." | "We achieved the outcome you need." |
This isn't just semantics. It's a fundamentally different way of defining success.
Process Reflects Mindset
How you work reveals what you believe:
Traditional Process (Waterfall): Big upfront requirements, big risk. You only find out if you were right at the very end.
Iterative Delivery (Fake Agile): You're just building a predefined plan faster. It's a faster assembly line, but you're still building the wrong car if the plan was wrong.
Product Focus (Lean, HCD, Agile): A continuous flow where you discover, deliver, and learn. This allows you to adapt and ensures you're always working on the most valuable thing.
This Is Already Happening
This isn't a radical experiment. It's a proven model already in use:
- Federal level: USDS and 18F pioneered this approach for government
- International: The UK's Government Digital Service and Canada's Digital Service
- State level: Colorado and Pennsylvania have established digital services teams
- Local level: Franklin County, Ohio reorganized around product managers leading development teams. Philadelphia is building internal teams focused on improving services before applying technology.
Organizing Around Value Streams
Right now, most IT organizations are structured around projects and departments. This creates silos and handoffs.
A better model: organize around value streams—the end-to-end activities that deliver value to a customer (whether a community member or internal user).
This means shifting from temporary project teams to persistent, long-lived teams that own an outcome.
Three Types of Value Streams
Community Value Streams: Delivering services directly to the public. Example: A resident's journey to apply for health services. Goal: Improve public access and community outcomes.
Staff Value Streams: Empowering employees to do their jobs effectively. Example: The internal HR system used for payroll. Goal: Improve internal efficiency.
Enabling Value Streams: Providing foundational platforms for all other streams. Example: Secure network, cloud infrastructure, developer tools. Goal: Increase speed, reliability, and security for all teams.
Not Just for Websites
This model applies far beyond public-facing websites:
Enterprise Systems (like Workday): This is a Staff Value Stream. The "product" is the employee's experience. The "outcome" is less time on admin and better workforce planning.
Data & BI: This is an Enabling Value Stream. The "product" is the organization's ability to make decisions. The "outcome" is measurable improvement in departmental KPIs.
Health Services: This is a Community Value Stream. The "product" is a resident's journey to get care. The "outcome" is reduced time to book appointments and better health outcomes.
A Shift in Roles
This model doesn't change who your people are—it changes the system they work in. It redirects their expertise to more impactful work:
From: Documenting requirements given by stakeholders To: Investigating underlying problems to ensure you're solving the right thing
From: Managing fixed schedules and delivering pre-defined scope To: Facilitating the continuous flow of value and adapting to what you learn
From: Tracking the status of disconnected projects To: Guiding strategic investments to achieve measurable outcomes
How to Make This Transition
This transformation isn't a top-down reorganization. It's a movement that proves its value one success at a time:
1. Pilot
Start with one or two teams. Give them air cover to work in this new way. Let them demonstrate what's possible.
2. Attract
The success of pilot teams creates demand. Other departments will want to work this way once they see results. Use wins to change the conversation from "what do you want" to "what outcome can we achieve together?"
3. Scale
Only scale the model after you've proven it works in your organization's unique culture and developed a repeatable pattern for success.
The Benefits
This new model directly addresses the frustrations we started with:
Reducing Risk: Continuous feedback prevents building the wrong thing. You deliver value sooner.
Increasing Value: Outcome-focus ensures you're always working on the most important problem.
Improving Partnerships: You become true partners with the business, sharing ownership of results.
Empowering Staff: Teams evolve from ticket-closers to strategic problem-solvers, increasing job satisfaction.
The Challenges Are Real
People Change: This impacts how people see themselves within the system. Change is hard. You have to treat this on the most human level possible—be open, listen, communicate.
Financial Framework: Budgeting and accounting structures often fight against this model. Work with finance to tie costs to value delivery.
Optics: This is a new way of demonstrating value. Be transparent, communicate clearly, and revamp how you report progress and value.
Getting Started
If this resonates, here's how to begin:
- Find your pilot: Identify a service that's painful for users and has a willing department partner
- Build a persistent team: Assign people who will stay with the product, not rotate off after go-live
- Define outcomes, not outputs: What change do you want to see? How will you measure it?
- Start small, learn fast: Launch something simple, get feedback, iterate
- Tell the story: Document and share your wins to build momentum
The shift from project to product is ultimately about asking a different question. Instead of "Did we deliver what was asked?" you ask "Did we achieve the outcome that was needed?"
That simple change in question changes everything else.
Based on a presentation originally delivered to government IT leaders. Have questions or experiences to share? Contribute on GitHub.