Thought-Experiment 39: Governments need a PolicyStore

Having founded a growth-studio which has supported governments, accelerators, foundations, nonprofits, and corporations to generate $100m+ in growth, I’ve been summarising my thinking through a series of ‘thought-experiments’. A ‘thought-experiment’ offers an alternative to the prevailing ‘mental models’. It is - hopefully - a coherent ‘thought’ which summarises and builds on countless ‘dots’: discussions, observations, and thinking. It is an ‘experiment’ because it is the very first step in putting something out into the world, inviting others to build on it or knock it down, always with the intent to rebuild it stronger. 

Some of these thought experiments have inspired organisations to create new roles (e.g. thought-experiment #25); others may be ahead of their time, while others may be just plain wrong. The following thought-experiments are all about questioning and proposing new government growth instruments. 

• Thought-experiment #38: Government Models: Govups - government startups 
• Thought-experiment #39: Government Models: Policies-as-Apps (PolicyStore)
• Thought-experiment #40: Government Models: Government business-models 
• Thought-experiment #41: Government Models: Government Ventures Studio

Please connect with me if you’d like to build on any of these thought-experiments.

------

TL;DR - Whilst the phrase there’s an “app for that” has become commonplace, it’s not entirely true - chances are there isn’t an app for the latest policies launched by your government. I don’t mean converting an existing 100+ page policy into a digital file and calling it an app - I mean a root and branch adoption of the value that apps-architecture offer. Given the speed of new policies struggling to keep up with the speed of change, we need new tools. And one such agile tool is the thinking (and creating) of policies-as-apps. 

------

The government of Denmark recently announced a cull of millions of minks to curb the spread of a coronavirus mutation. There was no legal basis for it - so now the government is drawing up the legislation in retrospect. Singapore’s attempt to regulate the scooter market, despite all the policy research and consultations prior to release, failed, because they did not expect or anticipate the rapid adoption by delivery drivers, who recklessly drove the scooters and caused fatal accidents, eventually leading to a repeal of the policy. Or the government of USA’s attempt to control migration in the 70s through border control policies, which backfired - whereas previously the migration of Mexican workers to the U.S. was seasonal and short-term, with migrants returning during the non-harvest seasons, the introduction of strict border controls ensured that when the migrants did arrive they wouldn’t return to their home countries because it would be so difficult for them to come back. In short: every policy is like hitting a moving target and almost always has unintended consequences. 

Although we need to laud the speed of new policy creation, which has been spurred along by the pandemic, it is the unintended consequences that follow any new policy which highlight the need for governments to embrace different execution models. Whether it’s health policies, fiscal policies, innovation policies, social distancing policies, travel policies – policies govern (often invisibly) every hour of our lives. And that’s why it’s so important to experiment and innovate, not just ‘in’ the policy but also ‘on’ the policy design, creation, and execution. 

Before going into detail in defining and explaining Policies as Apps, as is customary with my posts, allow me to explain a few ‘dots’ which have inspired the writing of this thought-experiment. 

Dot one: Less linear or circular, more spiral mindset

All too frequently today, we see governments taking a linear or a circular mindset to policies. 

The linear mindset typically includes the design, development and delivery of the policy - but rarely involves any adaptation to a particular policy for many years. 

The circular mindset typically includes some or all of the 10 different stages. A circular mindset probably includes waiting too long to read the signals that there is a need for a given policy to address some failure in the system (identification). The next steps would be creating a policy based on internal and external experts (research), designing the policy, framing the write-up of the policy, inviting stakeholders for consultations to tweak it, then launching it nationwide, before communicating its importance and relevance, ensuring it’s adherence, and evaluating it. After all this, there is then a crucial life stage - where there is (usually) a scramble by the government in question, either in creating another policy to address the exceptions, or repealing, incrementally widening, or tightening the original policy. 

Although each stage can vary in length from weeks and months, the overall cycle (loop) can last many years. 

What governments truly need instead is a ‘spiral’ mindset to policies, which aims to close the gap between policy creation and policy adaptation. 

This would consist of a government utilising what I call the ‘co-create - test - iterate’ spiral loop. The process would look like this: the government would first co-create with stakeholders at the beginning of the process, not towards the end. Then they would test not just one but multiple versions against each other, before iterating fast based on observed actions, rather than opinions. Crucially, the first loop in this spiral may be a matter of days or weeks, before going through a second loop that gradually increases the amount of risk, resources, or impact associated with scaling some aspect of the policy.

Dot two: less document, more product mindset

The number one advantage of a startup isn't its talent, resources, or visionary thinking - governments arguably have greater access to all three in more abundance. It's the speed of iterations it has the courage to make, be they big or small. 

However, governments rarely iterate on their policies fast enough. Most policies involve thousands of collective hours in designing and shaping it, yet a relatively smaller percentage of hours on iterating it. 

It’s not good enough to just talk about agile government - we need to create explicit pathways for such iterations. We need to balance the speed of decision-making with the speed of changing, overturning, subtracting, repealing, shifting, or adding where required. And this can’t be done if we treat policies as documents. 

We need to break this link between a policy-as-a-document and shift to a policy-as-a-product mindset - where you create the smallest version that allows you to learn something from the market. Tesla didn’t launch their own car first; they launched batteries in an existing car (minimum viable product) and then, step by step, have expanded across the value chain of the entire industry. Policies are no different. Shifting to a product mindset allows us to first create minimum viable policies as Policy-Apps. Policies as Apps which are constantly being updated with new features, bug fixes, and better experiences. 

---

In the rest of this thought-experiment I will outline how Policies-as-Apps could work.

Two things to note first:

1. Policy-as-Apps is not about creating an app to ‘communicate’ (provide info) on a policy. It goes beyond ‘digitising policies’. It’s about creating a completely new app architecture and (re)designing for all life-stages of a policy.
2. It is extremely difficult to execute Policies-as-Apps with the existing toolsets, mindsets, and skillsets. This is why we need to create new ‘execution-sets’.

At least four layers are worth exploring in high-level detail:

PolicyStore - where policies are managed:  Just like Apple’s App Store or Google’s Play Store, governments could create what I call a PolicyStore. This PolicyStore needs to define its own decision, risk, APIs, governance, data, and privacy permission layers. 

PolicyApps - how policies are accessed: The PolicyStore could operate as a platform where it’s open not just to core government entities, entities which often become a bottleneck because of limited legislative time, but also engage the small army of committees, boards and councils that instead of whitepapers and recommendations, can now also create policy apps for approval. These PolicyApps would operate in a spiral, product, and iterative mindset (as outlined above) that is much easier, given it would be literally an app. 

PolicyRoadmap - when policies are released:   Just like with any app, there is an alpha, beta and full release. We need to take a similar roadmap driven approach to PolicyApps. If we don’t, we will either only ever release fully-baked policies (which won’t withstand the test of the real world which are full of unintended consequences) or simply end up replacing the old way of creating policies, but in a digital format. For illustrative purposes, I share these constraints with an example of, say, offering Visas for highly qualified talent. 

• Up to 12 months - Twelve months, for the alpha duration of the policy, is a reasonable time horizon, which balances the need to create a sense of certainty of communicating to stakeholders that there will be an end-point for when the policy will be stable and go live nationwide. And, allowing policy makers enough time to iterate the policy based on the types of data below. 
• Up to 52 iterations - This is not just about creating an implicit expectation that a PolicyApp will be iterated, but actually tracking an explicit metric on how many times a PolicyApp has been iterated. An expectation needs to be set and managed, perhaps on a weekly iteration cycle, aka 5-day sprints. PolicyApps need to legitimise changes. Each additional clause, clarification, exception, and more, can be classed as an iteration. This changes the approach of running consultations focused on inviting feedback, to hearing and seeing the consequences of the PolicyApps focused on inviting ‘feedforward’. 

Also, it will not just be a case of making the iterations themselves, but also educating citizens and stakeholders that, yes, governments are allowed to iterate policies in this fashion, within, of course, a limited period of time. 

• Up to 10,000 instances - Because the alpha version of the app is not a ‘full-blown’ (nationwide) policy, you can create limits on the number of times the PolicyApp is applied or invoked. This number has to be big enough to yield meaningful data, yet small enough that it doesn’t ‘disrupt’ or require new systems to be developed prematurely. The ‘up to 10,000’ (or whatever is the appropriate number for a particular new policy) number is to create a ‘tipping point of evidence’ before it becomes a full-release of a comprehensive policy.
• Impact - There is often a significant gap between all the different policy life stages. PolicyApps aim to close at least one of the gaps, between policy launch and policy evaluation. It’s about creating the knowledge and the system to track what constitutes good (bad or unintended consequences) impact. For example, with a visa it’s not just about the number of visas that are issued, but what economic and social value the people issued with a visa have created. In this instance, another metric might be: what are the possible negative impacts of, say, taking away jobs from ‘locals’? These will encourage not a theoretical cost/benefit analysis, but a practical one focused on hard data. 
• Up to 2-5 versions - If you look at most policy or business case recommendations, you will invariably find a section that asks about data on the alternatives you looked at, requiring an analysis of why they won’t work. After reading a sample of these, it’s quite clear that very little evidence is offered for the alternatives - they are merely conjecture. 

The goal of the PolicyApps is to maximise the return on learning rather than maximise the return on success. With this in mind, in the visas scheme example, you may give 1,000 visas to scientists (at random), 1,000 to existing entrepreneurs for referrals, 1,000 to executives in their 40-50s who want to set up a business (this particular facet being based on MIT research, which demonstrates that the average successful founder is not 20-something but 40-something), or even 1,000 visas decided by an AI algorithm with no human intervention. Then, test their efficacy against each other. 

The key here is to test, not document, multiple versions against each other. As we saw in the Astrazeneca COVID-19 vaccine development trials, it was an accidental half-dosing that created the most effective results. Also, in my personal work with founders, I’ve seen it countless times - it’s usually the ‘wild card’ option we test against which ends up producing the best results. 

• Up to 100+ exceptions - It’s easy to design policies for the 80% of the time where the use-cases for a policy are easily definable. The issue is the grey areas - what happens for the 20% of the cases where exceptions are required? Rather than overcompensate and change the rules for everyone, which has the result of making everyone’s life difficult, every PolicyApp needs to create dedicated pathways to track and handle exceptions data, as opposed to adding more rules. Vitally, the policy can graduate from an alpha to a beta or full release only after these exceptions have been evaluated for frequency and impact. 

PolicyGovups - who creates policy-apps: This PolicyStore, and even some of the Apps themselves, can be created and managed as a Govup (see my last thought-experiment #38) - so the focus is not on changing the existing policy system we have, but rather on testing a new execution model, and then scaling what works. 

----

In summary, Policies-as-Apps is not about digitising policies but actually actioning a complete shift in the way governments perceive, design, and deploy policies. The argument against is often that the cost of all this ‘work’ is too high. I would counter with the assertion that the cost of the unintended consequences of failed or badly-executed policies is often even greater. 

----

Before you leave, please like, share, or comment - that is, if you see that this thought-experiment has any value - so that your network may come across it.