I make government feel effortless.

Most government forms ask people for things the government already knows.

Your name. Your date of birth. Your address. The number on the ID card that was issued by the same government now asking you to type it in. We have built a whole discipline around making forms easier: clearer labels, smarter validation, fewer screens. All of it helps. But it treats the form as a given, and the form is usually the problem.

When my team launched an AI assistant that lets people submit a government application entirely through conversation, the headline number was the time it took: down from 14 minutes to 2. What made that possible wasn't clever language technology. It was a change in the question we were asking. We stopped asking "how do we make this form easier to fill in?" and started asking "what do we actually need to hear from this person that we don't already know?"

The answer is almost always: very little.

Three questions to ask of any form

Before redesigning a form, I now ask three things.

1. What do we already hold? Identity, contact details, past applications, documents issued by other entities. If a trusted system has it, the person shouldn't retype it. One secure sign-in should unlock all of it.
2. What has actually changed? For a renewal, the only real question is often "is anything different since last time?" That's one question, not twenty.
3. What can we check at the source? Instead of asking someone to upload a copy of a certificate, verify it directly with the entity that issued it. Every upload is a small act of mistrust, and a source of errors.

What's left after those three questions is usually a short conversation, not a form. And a conversation is how people naturally explain what they need.

Why this is harder than it sounds

None of this is a design problem alone. Prefilling data means integrating systems. Verifying at the source means agreements between entities that each own their own data and carry their own risk. I've spent years on exactly that kind of work, including a service integration hub that connects more than 40 government entities, and the technology is rarely the hard part. Trust is.

That's why I'd encourage any team to start small. Pick one high-volume service. Remove the fields you already know. Measure completion time and error rates before and after. The results make the case for the next step far better than any strategy document.

The goal is to disappear

The best government service is the one you barely notice. You say what you need, and it's done.

Forms were a reasonable answer when systems couldn't talk to each other. Now they can. The question for every public-sector product team is no longer how to design a better form, but how to need one less often.

What's the most unnecessary field you've ever been asked to fill in? I'd love to hear it.

The first number everyone asks about an AI assistant is how many people used it. It's the least useful number we have.

Usage tells you people were curious, or that you promoted it well. It doesn't tell you whether their lives got easier. An assistant can have millions of conversations and still leave people stuck, confused or quietly returning to the old channel.

When we launched an AI assistant that lets people complete government applications through chat, we had to decide what "working" meant before launch day, not after. Here's the framework I use now, and recommend to any team putting AI in front of the public.

1. Outcome: did the person get it done?

The primary measure is completion, not conversation. Of the people who started a task with the assistant, how many finished it? And how long did it take compared with the channel it replaces?

For us, the headline was time: 14 minutes by form, 2 by conversation. But time only counts if the task is actually completed. A fast conversation that ends in "please visit a service centre" is a failure dressed up as efficiency.

2. Quality: did it get it right?

This is the guardrail. What share of applications submitted through the assistant are later rejected, returned for missing information or corrected by staff?

If speed rises but rejections rise too, you haven't removed work. You've moved it to the back office, and made the applicant wait longer for a worse answer. I'd rather launch slower with a rejection rate at or below the old form's than launch fast and quietly overload the team behind the service.

3. Trust: would they come back?

The third layer is the one most dashboards miss. How often do people ask for a human? How often do they abandon mid-conversation? What do they say in satisfaction surveys after completing a task?

People forgive a new channel for being new. They don't forgive it for wasting their time or making them feel unheard. Trust is slow to build and fast to lose, especially in government services, where people often have no alternative provider.

Report them together

The most important rule is the simplest: never report these numbers alone. Speed without quality, or quality without trust, invites a team to optimise one number at the expense of the others.

Before launch, agree a target for each layer, and the number that would make you worried. For us, the warning sign would have been a rejection rate above the old form's baseline. That one number would have outweighed any growth in usage.

Cost per application matters too, and it will follow. But leading with cost sends the wrong signal to the team, and to the public. Lead with outcomes for people, and the savings arrive as a consequence.

If you're measuring an AI service today, which of the three layers is the hardest to track? I suspect it's trust.

Every government service is designed twice: once by the people who run it, and once by the person trying to use it. Too often, only the first design gets written down.

Inside an organisation, a service looks like a process. There's an intake step, a verification step, an approval, a payment, an issuance. Each step has an owner, a system and a rule behind it, and every one of them is there for a reason.

From the outside, the same service looks completely different. It looks like a parent trying to renew a document at 10pm, unsure which photo is accepted. It looks like a small business owner visiting three offices because each approval lives with a different entity. The process is logical. The experience is exhausting.

The org chart shows up in the journey

One of the most reliable patterns I've seen in public services is that the customer journey mirrors the organisation's structure. Separate departments become separate steps. Separate systems become separate logins. Separate entities become separate visits.

Nobody designs it that way on purpose. It happens because each team optimises what it owns. The result is a journey where every step works and the whole still fails.

That's why, when I build a roadmap, I start from what someone is trying to get done, and work backwards to the systems. Not the other way round.

What that looks like in practice

A few habits make the difference.

• Watch before you write. Before reading the requirements, watch someone use the service, or sit with the front-line staff who help them. Ten minutes of observation beats a week of workshops.
• Map the whole journey, not just your part. Include the steps that happen outside your product: the phone call to ask about status, the visit to print a certificate, the approval from another entity. That's where most of the friction hides.
• Name the moment that hurts most. Not a list of twenty pain points, but the one moment where people give up, call for help or make mistakes. Fix that first.
• Measure the outcome the person cares about. Time to done, visits avoided, questions they no longer have to ask. Not just the metrics that are easy for the system to count.

Integration is a customer experience decision

The hardest fixes are rarely on the screen. Removing a visit might mean integrating with another entity. Removing an upload might mean verifying a document at its source. Contributing to a fully paperless service, and later to a hub linking more than 40 government entities, taught me that back-end decisions shape front-end experiences more than any interface does.

So when someone asks whether a piece of integration work is "technical" or "customer-facing", my answer is: both. If it removes a step for the person, it's the most customer-facing thing you'll ship all year.

Government is complicated. The experience doesn't have to be. Starting with the person is how you keep the complexity on your side of the counter, not theirs.

When did you last see a journey from the outside? It's worth doing this month.

The most important skill I've learned as a product leader isn't saying yes to the right things. It's saying no to good things, and keeping the relationship intact afterwards.

Every roadmap is a set of choices about what not to do. Teams are finite, releases are finite, and every "small addition" is paid for by something else, usually quietly. The danger isn't the big, obviously wrong request. It's the reasonable one, from someone senior, arriving at the worst possible moment.

A bare no damages trust

A flat no, even a correct one, tends to go badly. The person asking hears that their problem doesn't matter. They escalate, or they find a workaround, or they simply stop bringing problems to you. You win the decision and lose the partner.

Over the years I've landed on a simple rule: a good no always carries three things.

1. A reason in their terms. Not "it's not on the roadmap", but what saying yes would cost the things they care about: the launch date they'll be judged on, the service that more people depend on, the quality their name is attached to.
2. An alternative. A smaller version that meets the real need now, a workaround, or a way to test the idea cheaply. Most requests are really about a problem, and there's usually more than one way to solve it.
3. A date. When will we look at this again, or deliver the fuller version? "Not now" without a date sounds like "never". With a date, it sounds like a plan.

Start with curiosity

Before any of that, ask why. What problem is behind the request? What happens if it isn't solved this quarter? Often the answer changes the conversation completely. The feature they asked for turns out to be one way of solving something you can solve faster, or that's already planned under a different name.

No is a leadership act

Saying no well is also how you protect your team. A team that absorbs every request never finishes anything properly, and people burn out on work that was never going to matter. When a leader holds the line, with reasons and respect, the team learns that focus is allowed.

It's also a skill I try to build in the product managers I mentor. The best ones don't avoid hard conversations. They walk in with the trade-off already mapped, an alternative in hand and a date they can commit to.

People accept no far more easily than they accept being left without a plan.

What's the best no you've ever received? The ones done well are rarer, and more memorable, than we think.

Early in any product, edge cases feel like footnotes. The applicant with two nationalities. The name that doesn't fit the field. The payment that went through twice. You log them, promise to come back, and ship for the main path.

Then the service grows. On a platform handling millions of applications a year, a case that affects one person in a thousand is no longer an exception. It's thousands of real people, every year, stuck in the same place.

Scale changes the maths

At small scale, an edge case is a bug. At large scale, it's a segment. It has its own volume, its own support cost, its own call-centre script. Often it also has its own workaround, invented by front-line staff, that nobody on the product team knows exists.

Those workarounds are where I learn the most. When staff keep a spreadsheet on the side, tell people to apply twice, or ask them to come in person "just for this one", the system is telling you something.

How I go looking for them

• Read the rejections. Rejected and returned applications are a map of where the rules and real life disagree.
• Sit with support. Ask the team which question they answer ten times a day. That's your next backlog item.
• Count, don't guess. Put a number next to every exception. Ten cases a year and ten thousand need very different answers.
• Follow the person out of the system. Ask what happens after the error message. If the answer is "they call" or "they visit", that's the real cost.

Design the exception, not just the error

Not every edge case should look like the main path. Some genuinely need a human. But that route should be designed on purpose: clear, quick and respectful, not a dead end behind a generic error message.

A service is judged by how it treats the people whose lives don't fit the form. At scale, that isn't a handful of people. It's a crowd.

Which edge case in your product has quietly become a segment? It's worth putting a number on it this week.