Measuring progress: A product maturity model for digital government

In the private sector, a scale-up, or high-growth firm is defined by its growth rate, either in revenue generated or employees, for those sectors with a larger footprint. Ideally these outward metrics of growth are accompanied by an enabling “inner transformation” – innovation, investment, network expansion, operational processes, and professionalization or formalizing enabling functions and roles, or increased adoption and market-share. Growing tech companies need more than just a solid product to succeed and the same is true in the public sector.

Introducing a product maturity model for the public sector

At the Canadian Digital Service (CDS), we have developed a draft in-house Product Maturity Model, tested iteratively on our suite of existing products – interconnected government-ready additions to existing departmental technology to improve digital services. It was built with the expertise and input of product and enabling support leads, to ensure it captured a range of product types, founding conditions and stories, and scaling needs. We also built off of existing work in this space, by David Eaves and Ben McGuire for instance or Think Digital’s Digital Maturity Assessment Model, and are hoping to continue the dialogue with digital government teams across Canada, and internationally. The model CDS has developed is used to understand and communicate the maturity level of each product and to ensure the conditions for success are in place for growth as a planning tool. 

We are sharing it now, as part of our commitment to working in the open and as a resource for the digital government community, inviting recommendations, critique, and stories from teams who apply it to their own work or want to share their own versions. You can find an overview of the model below, and the full model on Google Docs, where you can make a copy for your own use.

While there are private sector models for what this growth trajectory and success factors can look like, they are more difficult to apply in digital government’s unique context. In the public sector, in-house products operating successfully at scale may focus more on widespread adoption and stable operations than high-growth revenue or head counts. Existing public sector models look at the digital or technical maturity of an organization to deliver technical solutions to technical problems, and conditions for success, rather than assessing individual products, with the implicit understanding that if an organization is healthy and mature, the products it produces will succeed. A good product maturity model is both a point-in-time performance assessment and a needs assessment. It should be able to capture both optional and enterprise-wide mandatory software, home-grown and partially-procured. Taken collectively across a suite of products, it can pinpoint patterns and gaps in team and organizational needs, skills, and prioritization. 

Defining growth: an overview 

Fig 1: Data Maturity Model circular diagram, segmented into eight colored sections representing different domains: Team, Data, Analytics, Visualization, Clientele, Data Management & Governance, Data Competency, and Enterprise. Each section includes concentric layers labeled Adapting, Emerging, Mid-career, Established, and Twilight, indicating levels of maturity. Each segment lists specific competencies or characteristics related to the domain it represents.

Phases:

The model borrows from the arc of an artist’s career, from aspiring through emerging, mid-career, established, and twilight, with dedicated phases for pre and early-development discovery and end-of-life sunsetting and decommissioning. Not every product will fit neatly into each phase: some may be more mature in one element (e.g., features) and less mature in others (e.g., marketing). Some may come with unique procurement needs for key components and others will be built entirely in-house. Some may have dedicated funding from the start and others may be seeking ongoing funding after launching. 

Categories:

Beyond product development and new features, the model covers the full breadth of elements needed to mature a product, from team skills and product governance to technical support, client satisfaction, policy compliance and documentation, and performance measurement and data. The categories are intentionally divorced from CDS’s own existing team structures, recognizing that our own work is highly collaborative and that not every digital team has the same organizational chart. 

Indicators:

Within each category there are a number of indicators – activities or metrics a typical product would need, at each phase of maturity. An aspiring product won’t be actively marketed, but the team would need a loose idea of how to go about getting adoption, the potential market share it could take, and early understanding of client use cases. A mid-career product would have an active marketing practice and growth plan in operation, sharing insights from client demos and support tickets back to the product team in a virtuous feedback loop. A twilight product may no longer be actively marketing or updating its materials, other than self-serve and automated approaches and maintaining existing clients. 

Early Insights:

1. The work of a product begins before a line of code is written or a client onboarded. The discovery phase includes:

• Early market, competitor, and user analysis.
  • Is the product unique in the field or is there an existing enterprise-wide solution with a multi-year contract or a thousand micro-solutions across departments?
• Understanding the policy environment the product will operate in.
  • Is the product concept theoretically compliant with the Privacy Act?
• Understanding government culture and process.
  • Is the product seeking to solve a problem for which your users are exhausted by change or have given up on stagnation, or one where there is political and bureaucratic momentum to improve things? 

2. The work of a product also continues past the Twilight Phase and into Decommissioning, including knowledge transfer, transitioning and/or offboarding users, documenting, and storytelling. The scraps of a decommissioned product and the expertise the team developed along the way can be the kernel of the next big thing.

3. The model of small, agile, independent in-house product teams quickly runs up against the behemoth that is government policy meant to ensure consistency, coherency, and reduce risk. Additionally, limitations on funding and staffing necessitate economies of scale in cross-product needs. The model seeks to capture both individual team metrics and success factors as well as the critical centralized functions needed to lift a product into full maturity and help it gracefully decommission when its use case is no longer needed or technology has moved on.

4. It’s hard for product teams to keep all project trajectory variables in mind, particularly on multiple development tracks, complexities, or challenges. Most have their own systems and trackers to measure progress, both digital and old-school. These can work incredibly effectively for an individual product but may pose challenges for senior leadership or other teams to compare across products or track shared objectives. 

The model is not meant to replace individual product roadmaps and planning, but to provide a common language and methodology, and help identify patterns that could speak to systemic issues that require action and dedicated attention beyond one team. More than that, we hope this type of tool will also provide some answers to a more challenging question: how do you know your product is mature enough to provide assurances to even your most skeptical prospective clients or to scale to serve all of government? 

Possible applications

• You’re an executive in charge of a suite of products, looking for information on systemic barriers and needs across your portfolio or to assess when you can reallocate resources to support a new product.
• You’re a product manager and you have your own ways to track progress on where your product is going, but you use this tool to communicate product status to senior management or other team leads. You may also invite your team to self-rate your product, and use discrepancies in perceptions as a launching point for team discussions. 
• You’re a CEO who needs to know when a product is mature enough to be pitched as a reliable, enterprise-wide solution for broader adoption. 
• You’re responsible for a centralized product support function, such as marketing or security, and need to make decisions about resourcing and assignments that align with product growth plans. 

We want to hear from you!

If you and your teams are using the model, or have feedback on its application, we would love to hear about it! Please send us an email, or reach out on LinkedIn. We’re looking forward to working with all of you to develop this model for better digital products in the public sector.