We’re at a precarious time in the history of liberal democracy. Citizens, whose expectations are set by the rich panoply of online services, demand more than ever, immediately, from their governments. If governments can harness the promise of technology to deliver better services to all, they can meet — or even exceed — those demands.

But to do so requires a sea change in how those in public service think about inertia, experimentation and iteration. It requires a bias for speed and learning. It means they have to abandon perfection, and embrace good enough.

To explain why such a change is needed to make better policy, I need to dive briefly into the rather dry world of project management, because useful services are hard to deliver well unless their creators approach projects correctly.

If you’re undertaking a big, costly project — a battleship or a Mars landing — that’s hard to update once it’s built, you get only one chance to do it right. Delivering this kind of project uses a process known as a waterfall management strategy, because it follows a set of clearly defined steps that flow from one into the next, in a linear sequence: Plan, Test, Build and then Launch.

But digital services aren’t battleships. When Google first launched Maps, it was imperfect. Similarly, when it launched Gmail, this app was a side project, with only basic functionality. Gmail was labelled beta for five years after its launch, a reminder that the product was still in development and that users should expect changes and iterations. Today, a billion people and thousands of apps rely on Maps, and a billion people communicate via Gmail. The first versions weren’t perfect. But they were good enough.

Digital is different

Modern software is built iteratively, using processes dubbed “agile” or “lean” that emphasize continuous improvement based on learning how earlier versions are being used. This approach is needed because digital services are different from physical ones in two critical ways.

The first difference is the ability to make changes after something has been delivered. Early versions of Microsoft Word were shipped on a floppy disc, and getting updates to people was expensive — Microsoft would literally have to test the new version on every device, then mail new floppies. By contrast, today’s hosted services and applications are constantly being updated.

In modern software, changes are not only easy, they’re expected. While you can’t change the size of the ship’s hull once you’ve launched it, and you can’t add fuel to the spaceship once it’s on its way to the red planet, delivering a new version of a service is as simple as refreshing a web page or updating a file in the app store.

The second big difference is that when you use a digital service, it learns from you. That was another disadvantage of the old floppy disc model: software makers couldn’t learn from it. But Google rapidly improved its office suite because every time someone used it online, the company learned more about what it should have built. It even launched a parallel product (called Inbox) to test out ideas.

With hosted software and apps, makers can immediately see what features users wish they had, where they’re getting stuck, what devices or regions aren’t adopting something, and so on. They can collect feedback from everyone, constantly, and improve their offerings. Perhaps most important, they can learn which services to focus on with all their resources, and which to kill off quickly because nobody needs them.

With connected devices, automated maintenance and the Internet of Things, this new, iterative model of delivery is spilling over from software into the physical world, too. Tesla, for example, collects analytical data from its cars and sends software updates.

In 2013, I co-wrote Lean Analytics, a book about using data to build better products faster. In it, we explain that at the outset, today’s manufacturers aren’t building a final product. They’re building a product to figure out what to build.

In a connected, digital world the old cycle of Plan, Build, Test and Launch has changed. Now it’s the lean model: Build, Launch, Measure, Plan and Build Again, in a never-ending cycle of gradual, inexorable improvement. And this is just as true for public services as for private start-ups.

Why we can’t have nice things

But digital government initiatives struggle to harness the promise of rapid, exploratory, iterative innovation, thanks to a risk-averse, politicized culture that demands perfection at the outset. And this is where we get back to policy. Because when governments launch incomplete things, they expose themselves to criticism.

The lean model of product development centres on the minimum viable product, or MVP: the least complete thing a company can create that will fully test an idea. That means the MVP won’t work for everyone. The makers will be accused of experimenting on their users. They’ll be accused of making something inaccessible. The government service they build at first won’t have every feature — and critics will pick it apart, turning it into political fodder to win points and votes or further their particular agenda.

In a climate where we deride imperfection when we should be celebrating progress, the safest thing to do is often nothing, or building something huge and monolithic that runs over time and budget by trying to please everyone in its first version. The demand for perfection in nascent government services breeds inertia. And yet if Western liberal democracies are to compete with command-economy nations and benevolent technocracies, we must act, or fall behind.

The new project management

To remain competitive in a digital era, governments, civil servants and citizens must embrace three things: a measurement mindset; an agreement on what the minimum should be; and freedom to experiment.

• We must not build without an intent to learn. When departments build the first version of a government service, they need to set up detailed analytics to measure how it is being used. If the service is valuable, they need to work as fast as possible at improving it. And if it isn’t, they need to kill it quickly.
• We must agree on what’s minimally viable. The minimum may be accessibility from the outset, multilingual support, support for certain devices or a level of ease of use. MVPs must be complete, so that the makers can learn from the users. But they have to be small and incremental, so effort isn’t wasted on features and services nobody needs.
• We need to give digital government permission to experiment. A build-and-iterate approach must become the new norm, with the proper transparency and accountability. At the outset, what the builders learn is more important than what they deliver.

Other countries embrace this approach — with considerable success. For example, at the FWD50 digital government conference last November, Taiwan’s digital minister, Audrey Tang, talked about how her government approaches iteration. It has a “shadow Web” for government services. Any citizen can simply replace the “gov.tw” in a URL with “g0v.tw” — changing the “o” to a zero — and see an alternate, experimental version of the service they’re using. The designers learn and iterate, and when the government wants to, it can make the experimental version the new normal.

Digital government will accomplish what citizens hope only when we give it permission to fail, learn and iterate. In return, it must be accountable and must rush to improve what’s working while killing what’s not. Only when we embrace good enough as a starting point can we have the future that digital government promises.

This article is part of the Wiring Public Policy for Digital Government special feature.

Photo: Shutterstock/By patpitchaya

Do you have something to say about the article you just read? Be part of the Policy Options discussion, and send in your own submission. Here is a link on how to do it. | Souhaitez-vous réagir à cet article ? Joignez-vous aux débats d’Options politiques et soumettez-nous votre texte en suivant ces directives.