Thoughtful people are advocating for it and treating it as the organizing concept for a new era of state technology. I think they are largely right. But the concept is being interpreted in ways that worry me, and I want to offer a different read before those interpretations harden.
The term means different things depending on who uses it. In the commercial world, it centers on the end user and whether a product actually solves their problem. In government, the framing tends to focus on the difference between funding a project, which ends at delivery, and funding a product, which should keep working well for the people who depend on it long after launch. Both definitions would agree that the work does not end at go-live.
My concern is not with the product mindset itself, but with what some take it to mean in practice.
GREENFIELD VS. INFILL
As AI tools have made software development faster and cheaper, some are reading a product mindset as support for more product development, meaning more custom-built applications and leaner upfront requirements. If we can build faster, why not build more and learn as we go? In some settings that logic holds. For genuinely greenfield projects, where a department builds something new without an existing system underneath it or a public already depending on current functions, a more iterative approach can work well because the cost of getting something wrong early stays manageable.
Most large state IT efforts are not greenfield, however. I would describe them as infill, borrowing from urban planning. Infill development neither renovates what already exists nor builds on an empty lot. Instead, it constructs something entirely new on a constrained site, where everything surrounding the project shapes what can be built and how. For state IT, that constraint comes directly from the legacy system and the people who depend on it every day. The requirements are not invented from scratch but inherited from years of accumulated policy, state and federal mandates, and public expectations. Learning your way forward through iteration works when you have room to experiment. But infill projects do not offer that room.
THE HIGH COST OF CUSTOMIZATION
Troubled IT projects rarely fail for a single reason. Weak executive sponsorship, poor governance and unrealistic timelines all leave their mark. But across my years in state and local government, the factor I kept finding underneath those surface problems was over-customization. Systems would be built around specific workflows that became outdated or modified so much that the original product became unrecognizable. Customization alone does not cause failure, but it almost always makes every other problem harder to fix.
A genuine product mindset should make agencies more cautious about customization. The question worth asking before any development conversation begins is not whether a system can be built but whether the department can operate and improve it over time with the staff and resources it can realistically sustain.
WHAT AI CHANGES AND WHAT IT DOES NOT
AI tools do shift some of the calculus here. Agentic AI can bring real discipline to documentation, testing and code review in ways that informal development processes rarely achieve. But better tools do not reduce the risk of over-customization; they accelerate it. The faster we can build, the faster technical debt accumulates when we have not been deliberate about what we build and why. The arrival of powerful AI development tools is precisely why the state needs a clear framework for when custom development does or does not make sense. For greenfield work the case is reasonable, but for large legacy replacements with deep functional requirements and a public that demands it works immediately upon implementation, the bar should be high and the judgment clear-eyed.
THE REAL MEASURE OF A PRODUCT MINDSET
A product mindset in government shows up not in how much an agency builds or how fast it moves, but in whether the agency takes genuine responsibility for what it delivers long after the implementation team has gone home. That means treating maintenance as a critical phase of any technology investment rather than something to sort out after launch. We have always been able to build more than we could maintain, and agentic AI does not change that. If anything it raises the stakes for governance, sponsorship and architecture, and for having a clear picture of the entire system before anyone writes a line of code. In my next commentary I will address where, and for whom, agentic AI genuinely changes what is possible.
