This article is written by Simon Manby, Senior Product Manager, Ministry of Justice, and Kaz Hufton, Lead Product Manager, Ministry of Justice.
This article will be featured in Apolitical’s upcoming Micro Course about how to design a digital service. In this article, Simon Manby and Kaz Hufton from the digital team at UK’s Ministry for Justice explain why it’s important to have a clear vision and metrics for success when working on digital services.
Knowing when to go Live with a product is probably the most difficult point to recognise across the phases of delivery.
The right time to transition from Discovery to Alpha (is there a problem to solve? Is it valuable and feasible to do so?) or Alpha to Beta (have the riskiest hypotheses been tested? Is there a solution? Are we ready to get users to put live data through?) is felt by the team intuitively; they are gateways because each phase is set up to do a specific “thing”. But the move from Public Beta to Live is more nebulous.
Often products stay in Public Beta almost indefinitely because it’s so rarely obvious when to make the switch; if it is already being used by large volumes of people who are able to do what they need, then what’s the point?
Any product becomes legacy the moment you stop iterating.
But the Live phase is where the real work starts. When the glitz, glam and attention from the comms team has passed, making sure the service remains sustainable and relevant for its lifecycle, that it continues to have a multidisciplinary team available and funded, so that you may continue to iterate and respond to changing needs over time is so important. It’s all too easy to slip into a service becoming static as business focus shifts to the next shiny thing and teams have to support an ever-increasing portfolio of products.
When to go Live
Any product becomes legacy the moment you stop iterating, and a team should be setting clear conditions and pointers for when they move to Live very early on in the Beta phase, as this helps to define to everyone what success looks like, and gives a common goal to aim for.
A service should move to Live when it clearly meets the user needs set out in the previous phases of delivery, and users can achieve the outcome they want from it.
A service should move to Live when it clearly meets the user needs set out in the previous phases of delivery, and users can achieve the outcome they want from it. Critically, you also need to show that people are actually using it; in volumes that display it is both valuable to them and sustainable for the organisation. Try not to delay the move to Live any longer than you need to because not only does it provide a real milestone and sense of achievement to the team and wider organisation, it also allows you to set out your stall for future sustainability and quantify the value of the service in the organisation’s eye.
If it’s not worth sustaining then it’s not adding value and we can just switch it off, right? A Live banner should be a badge of honour and pride; you have successfully navigated to a point where you have not only proven a user need, but also served it, and better than anyone else has done previously.
You should use the move to Live to ensure there is a plan in place and a commitment to fund that plan for the service’s lifecycle. Live is where you can finally start to address any constraints identified through Beta and take time to work closer with areas like operations or policy to unblock those constraints. It’s also the time you can address performance and refactoring issues that have fallen by the wayside in the constant drive to release early value, to test some of the slightly less risky hypotheses and to enhance features users really want rather than specifically need.
Take pride in your boring magic
Think about the terminology you use in the run-up to Live; we’ve already used the dreaded “legacy” term above which often has negative connotations, but a Live service in “maintenance mode” or similar also doesn’t sound as appealing to a high-functioning multidisciplinary team as a new product entering Alpha with a blank canvas to flex their bleeding-edge technical preferences on. It’s also a misnomer; we’re not maintaining a product, we’re keeping it relevant to the service and valuable to users, this is often the most vital work but it is also quintessentially “boring magic” to quote Steve Messer, a product manager at UK’s GDS.
Don’t be precious about a product, if it’s no longer valuable or if there is a better way to do something, you need to be in a position to switch off with little or no impact to users or the organisation.
Your live services are usually the revenue-generating ones, which keep the business running, give users the ability to do what they need and ensure continued funding for exploration around newer hypotheses. Don’t undersell them to your teams or make them feel less worthy of attention. Live allows you to take your foot off the accelerator a little but it’s also the time to start really looking at the data you are collecting around user behaviour and feedback and to use these larger sample sizes to drive focus and strategy across the entire end to end service. Planned right, you will add more value in Live than you ever have in previous phases.
It’s also worth saying that preparing for retirement is a valuable part of the Live phase, just as you should be looking towards Live at the start of Beta, having a plan for retirement means you should be constantly measuring usage, value and satisfaction. Don’t be precious about a product, if it’s no longer valuable or if there is a better way to do something, you need to be in a position to switch off with little or no impact to users or the organisation. Don’t think about retirement too late.
In summary, have a clear vision within the team for what success criteria allow the move to Live and don’t delay when you have met them. Use the transition of phases to ensure commitment and funding for a multidisciplinary team for the service’s lifecycle and continue adding value, and always look to the next phase as early as you can. — Simon Manby and Kaz Hufton
👋 You can create a post like this one! Share your thoughts with a community of public servants. Learn more.
(Picture credit: Unsplash)
Make sure to share your own thoughts with the author by leaving a comment below

Log in or sign up to continue the conversation