Governments Should Adopt Startups Way of Thinking When Developing Services

Ever tried to fill in your tax form or submit files to government offices? Some countries are highly digitized and made the leapfrog of digital transformation, like Sweden, Estonia, or Lithuania. Others, and among them the most developed nations in the world, very much lag behind.

In some cases, digitalization did not simplify government services — it just moved the bureaucratic red tape online.

In fact, global data from Accenture shows that more than half of survey respondents (53%) find accessing government services to be frustrating, and more than one-third (36%) find government processes and interactions intuitive.

It is my belief that government should behave more like startups offering innovative services and products to their citizens — essentially, their customers.

When initiating a new service, or innovating an existing one, government should follow the same rules as a innovative startup focused on its users’ needs and satisfaction.

Last month, I spoke at the World Government Summit in Dubai on two connected topics: What Governments can learn from entrepreneurs, and how they must embrace innovation when developing services. I would like to focus in on the second.

When I speak with government leaders around the world about their digital services and digital transformation (digitization), what I constantly hear is “it is complex”, and occasionally with the addition of “I need someone to do it for me and therefore it is also expensive”. It doesn’t matter if these are DMV (Department of Motor Vehicle) services, tax-related issues, social security ,or any other service. The experience is the same.

And they are right, it is complex. There are actually three main reasons for this:

1. When governments offer digital services, they need to support 100% of the cases, and that’s hard to realize. It is true that Pareto is going to work beautifully, so we could have supported 90% of the cases with a simple approach and 10% of the efforts, but the requirement to support 100% of the cases makes it hard, long, and complex.
2. They put themselves in the center, instead of the user. So for example, a government is likely to decide to reduce the amount of work for themselves if they offer a digital service, and define it around this objective, rather than make it simpler for the user.
3. In many cases, they will outsource the project on a cost-plus project basis, which makes it even more complex as the developer will further complicate the process in order to earn more money.

How do we change that? What is it that we need to do differently? Change the mindset, and think like… a startup or a product developer in a commercial company.

1. Adopt a customer- centric approach
2. Move to a Pareto optimization. It may not be necessary to support 100% of the use cases. 80-90% support will be good enough.
3. Set different objectives. For example, a combination of how fast your service is adopted and how satisfied your users are may be the best way to measure how much value is delivered to the users.

Focusing on the user is a lot harder than it looks. We all want to think that we understand our customers, but the reality is each of us is a sample of one person, an amazing sample, but still just one.

The graph of user segmentation above demonstrates users’ behavior when it comes to adopting new services.

Users are different from one another and don’t fall into the same group. It is important to understand the four different types of user categories:

1. Innovators will try anything just because it’s new.
2. Early adopters will use an app even if it is new. Most people are afraid of changes, but early adopters don’t mind them. As soon as they understand the value for them, they will give the service or product a try.
3. The early majority (which includes me, I admit) are afraid to try new things. They don’t like changes. In fact, their state of mind is: “Don’t rock the boat.”
4. The late majority will use something only if they must. You should always be thinking of this category of users, even though they are not relevant at the beginning.

Service providers and product developers get stuck with the first two groups, innovators and early adopters, without being able to expand to the target audiences who are the early and late majority of users.

We start with, “we’re going to make the life of our users better,” but the reality is the state of mind of the users in the early majority we’re aiming our efforts at is simple – they are afraid of change and do not want us to ‘rock the boat’. They will not make changes, unless someone takes them by the hand and shows them how to do it.

The late majority is an even harder target audience. They will not switch to a new service unless they must, so discontinuing the old service should trigger desired change. However, they are way more likely to switch to something completely different from what they were used to – for instance, from a manual service to a digitized one (let’s say, submitting files online or via an app) to a manual service which will do the digital service for them and is therefore “complex and expensive”.

Focus On The User

Placing your user in the center is rather simple, you aim at the early majority group and not any other group. You speak with many of them to get their perception of the problem and the services before you even start defining it.

Then, you design the user side (app or website for example) and run a test with a few hundred users that belong to the early majority group. At this phase, your server side may be actually still manual work.

The idea is to learn users’ behavior at this stage. You watch those users and see how they interact with the service, and every time someone is doing something that you didn’t expect, or not doing what you expected them to do, you ask them “why?”

Then, you iterate this process until it is streamlined by the users – a new group of hundreds of users each time – as your challenge is always with first-time users.

Only then do you move forward to building the system where the user flow is already optimized for the early majority of first-time users. In fact, this is the only way to build a successful user-centric service.

It is the same for government services as well as for commercial products, digital and non-digital.

And what about outsourcing the solution to a local developer? It is not necessarily perfect but can work, provided you align the interests and set the objectives to be good enough.

Correction, March 7: An earlier version of this article reported incorrectly the percentage of survey respondents who found government services frustrating. It’s 53%, not 51%.