Changing user behaviour, and evolving privacy and security risks, mean platforms need to be developed and operated by a team with an ongoing understanding of the needs of their users. Those teams should be in a position to continuously improve the platform and respond to any risks. It is important they are funded for the long-term, rather than treated as fixed-term projects, or as quasi-commercial entities and expected to pay their own way.

1. Create standing teams to develop and operate new platforms

Bugs are a fact of life, as are malicious attacks. It’s also a side effect of a successful platform that it’s hard to know exactly how users will make use of it. This means user-behaviour and security risks will change over time. As such, a multidisciplinary team who are incentivized to improve and operate the platform is the preferred approach to the development of new platforms.

These teams do not need to be large, but they do need to be invested in the long-term health of the platform. Android, for example, has a small, very senior team. The lead developer for the Android platform, which powers 2.5 billion active devices worldwide, has a few dozen people on her team. The core framework team is an even smaller group of people, and many of them have been there since the beginning.¹

2. Fund teams for the long-term (but start incrementally)

Funding platforms on a short-term basis is at odds with the idea of shared infrastructure (who would build on top of an established platform if they didn’t know if it was going to be re-funded each year?) It also makes the retention of the team needed to operate and continuously improve a platform harder.

Cost-recovery based funding is also not easily compatible with the development of platforms for the simple fact that, because the cost-per-transaction decreases as the user base increases, early users are saddled with higher costs.

For governments used to modes of funding not suited to platforms this may represent a significant change both practically and culturally. But it’s important to get it right. If the funding processes within your organization restrict you to only seeking funding on a short-term or cost-recovery basis, see if it is possible to discuss the benefits of a platform approach with commissioners, finance and approvals teams. Work with them on how to create longer-term business cases better suited to the sustainable development of platforms.

This does not mean that each platform needs multi-year funding from day one - teams should be supported with funding models that allow them to prove the value over time.

3. Understand any legal constraints on funding models

Some organizations may be required by law to recover costs, and therefore find it harder to develop platforms. There may also be constraints on the procurement of services between central and local, or federal and state governments. In the long run, such issues may not make for a very good operating model. In the short-term, it is important to understand such constraints.

 4. Fund emergent platforms

While the need for some platforms may be more obvious, and the funding (potentially) easier to secure (for example, hosting or payments meet clear needs for multiple users), some needs will be more emergent.

As previously discussed in ‘Identifying platforms’, ‘point solutions’ developed from within product teams, with the potential for broader use will need support and funding made available to support them.

Review how you would offer funding and support to a team who have identified a shared need as part of the development of a service.

5. Make charging a strategic choice, not a budgetary one

Charging for a service may be too high a bar for some users, not necessarily because of the per-use cost, but due to the administrative costs associated with procurement. The team behind the GOV.UK Notify platform realized they could serve more users by offering the service free to the majority of them. They were only in a position to be able to do this because they were centrally funded.

In a limited number of cases, charging for high usage may be a way of ensuring efficient use.

Make an active decision about if and when to charge based on the needs of your users.

6. Understand when a new organization might be needed to operate a platform

Platforms cut across the hierarchical structure of government: shared components mean that agencies may no longer operate their own payment or hosting systems, and registers and APIs mean that they may become more dependent on data from elsewhere to operate a service. While there may be tactical reasons for developing a platform in one part of government or another, ultimately the question must arise: “where is the best place to operate it for the wider good?”

In the UK, the success of the UK Government Digital Service was in part that it was a new organization at the center of government, with responsibilities for digital across central government.² In India, the Goods and Services Tax Network (GSTN) operates APIs and other infrastructure needed to operate the national harmonized sales tax. GSTN is a non-profit company owned partly by the national and state level governments.³

While it may be outside the remit of a product manager or a Chief Digital Officer to create new government agencies, having an opinion about the characteristics of an organization that should operate each platform is not.

7. Allow for multi-tenancy and self-hosting

While there is often little reason for two different government agencies to use separate instances of a shared component, there may be legitimate reasons in some cases. For example, different tiers of government within a federal system may need to keep data separate.

Consider if having the option of both ‘software as a service’ (multi-tenancy) and self-hosting would meet the needs of more users.