When building and running services it’s important get into the habit of releasing updates to users on a regular basis.

This applies to all phases of a product lifecycle – whether you’re prototyping something new, or maintaining a service that’s already in use.

Deliver value early

When you’re building something, find the smallest thing you can deliver which adds value to the overall product.

If you’re in an alpha stage, the smallest thing could be a clickable prototype to show your initial thinking about the end journey.

If you’re in a beta stage, the smallest thing could be a service which meets the needs of a particular group of users, or a subset of the overall service features – a minimum viable product.

If you’re adding new features to something that already exists, follow the same principle.

Don’t wait for the prototype or service to be perfect before putting it in front of your users.

You don’t have to cater for every need or every group of users straight away. Deliver something, then iterate wildly based on real data, feedback and user need.

Delivering something early means you can start getting real data about how people use your service, which helps you validate if you’re taking the right approach.

It also helps you identify potential problems you might encounter later on as you expand the service.

Delivering early also helps you get buy-in – it shows that what you’re doing is real and can work.

If you’re building a prototype, letting people see a real thing helps them understand what you’re trying to do. Having something people can click around for themselves will beat a paper prototype, options paper or PowerPoint wireframe hands down.

Deliver value often

Once you’ve delivered something early, don’t stop.

Constantly ship small updates all the time.

Releasing small updates on a regular basis lets you make tweaks and changes as you learn how users interact with your service. You can react to what they do quickly and give them a better service.

Deploying small changes also helps you reduce your risk.

It’s easier to understand something small and what impact it’ll have than a huge set of changes bundled together. A small understandable change is less likely to break something, but if it does, it should be easier to identify the cause and fix it.

Delivering regularly also gives you confidence that you can make changes quickly.

Don’t fall into the habit of bundling up lots of changes and releasing them at once. Once you start down that path, it’s easy for time between releases to become longer and longer, making it more difficult for you to react to urgent issues. Just don’t do it.

Following on from my previous blog post– if you have to go to a change board to get approval to deploy changes, you’re doing it wrong. Your change board is increasing the risk that when a release goes wrong it’ll be a big problem rather than a simple rollback.

The Digital Service Standard says that you have to be able to update the service on a frequent basis. GOV.UK deploys technical changes multiple times per day. DVLA’s vehicle tax service was released at the end of every sprint (2 weeks). If you can (and do) release more frequently than those, you’re probably in a good place.

Avoid the big bang

It’s easy to get pulled into doing ‘big bang’ major feature launches.

Ministers, chief executives, senior civil servants, press offices all love ‘big bang’ launches of new services or policies. There’s nothing better than getting to sit on the breakfast TV sofa introducing the latest new thing.

Don’t do it – it rarely goes well.

Start small. Release the service to a small set of users first. Prove the service works, then slowly ramp up the number of users using it.

If you’re replacing something that already exists, consider offering the new version to a small percentage of users. Slowly increase that figure over time to prove everything works.

Wait until you’ve been running for a while and have confidence before you let press teams get hold of it.

Continually deliver value

Building, running and improving a good service is not an exact science.

All too often, potentially good services fail to work because it doesn’t meet the needs of its users, or something goes wrong when a change is made, or it can’t cope with the number of people using it.

Following these principles doesn’t remove the risk of those entirely, but it does make them less likely..

Continually deliver value and learn from your users as you go.