The MES ecosystem has adopted product language while remaining organized around specific systems or solutions. Modules are called products. Platforms are called products. Certification tracks product lifecycles. But the product of a Medicaid enterprise is not software. The product is the service a person receives: preventative medical care, transportation to receive that care, life-saving medication provided consistently on schedule. Systems and capabilities are inventory in service of that product, and inventory is a cost to minimize, not an asset to accumulate.
Defining a product's boundary around a system takes a model built for end-to-end outcomes and folds it into a silo, and inside that silo, many of the benefits a product mindset is supposed to deliver turn into liabilities instead.
Part of what makes the product model work in commercial settings is that product management places both accountability to a customer and the authority to make product decisions in the same person. When we name a system owner a product manager, both usually go missing. The customer named in practice is often a business stakeholder rather than the person the system ultimately serves, and the decision authority granted rarely extends far enough to matter, because the system is only one small factor in the organization's ability to actually serve that person.
This is not a recommendation to move away from product management or the product model. It is a recommendation to apply that model to a definition of product that is relevant in government: the needs of the people government serves, not the systems that support operations behind the scenes. When we build our structure around systems instead of services, we create local optimizations, improvements that look like progress inside a system while the person on the other end of it never notices the difference.
The recommendation: define services, not systems, as the product. Build product management practices around those services. Treat systems and platforms as part of the shared capability ecosystem that supports the products, not as products in their own right.
For additional information about shared supporting teams acting in support of an organization's products, we recommend the book, Team Topologies, which draws a useful, practical line between the teams that own an end-to-end value stream and the teams that provide shared, enabling capabilities to those streams. Getting that line right is what lets a product team stay accountable for an outcome without also having to own every capability it depends on.