Government Services Can Behave More Like Startups If They Treat The Needs Of Their Citizens Like Product Innovation

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 Lituania. Others, and among them the most developed nations in the world, very much lag behind. In some cases, digitalization did not succeed in simplifying the interaction with the government service – they just moved the process as is to online platforms.

In fact, global data shows that 51% of consumers find accessing government services to be frustrating, and only about one-third (36%) find government processes and interactions intuitive.

It is my belief that government services should behave more like startups offering services or products to their customers or users i.e citizens or inhabitants.

When initiating a new service, or innovating an existing one, their process should follow the same rules of any innovative startup. They should focus on their users’ well-being and satisfaction while making sure the solution fits their needs.

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; they don’t all fall into the same homogenous group or category. 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 often get stuck with the first two groups – the innovators and the early adopters – without being able to expand to the target audiences who are the early and late majority of users.

We start with the conviction that we are 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.