On Friday I popped in to see the fantastic team at FutureLearn to congratulate them on launching their new MOOC platform. They invited me to share some tips on post-launch survival so I came up with my top 5.  This is my personal take, not anything official from GDS, but I do use government examples because that’s what I’m involved with at the moment. They’re pretty straight forward (and the FutureLearn team seemed to have most of this nailed already!) but here they are in case they are useful to anyone else…

1. Look after yourselves and each other.
(Human bugs are more difficult and expensive to fix than bugs in your code).

We all tend to over-do it in the run up to a launch or big release, but you can’t survive forever on short nights, adrenalin and donuts.  Post-launch you’re responsible for running a live service and that is a long game, not a sprint. Most things CAN wait until tomorrow – especially if you’ve got good processes in place to monitor and resolve issues.  Happy rested people are more likely to come up with creative solutions anyway – and if “the unit of delivery is the team” you’re all going to suffer if one of you is suffering. If you’ve lost your sense of humour that’s probably a sign that you need to take a break!

2. Respect the process.

Actually, respect YOUR process – you should own it (as a team) you should review it (as a team) and you can iterate it (as a team) – but always respect it. This could apply to the process for adding things to the backlog, or for triaging user feedback, or for responding to stakeholders or Tweets or the press. When things get hectic you all need to trust that the processes you’ve agreed will be followed, and that no one will be going off piste… something that is likely to generate more work and a lot of noise.

3. Know your story.
(And publish it!)

Everyone in the team should know or have access to the story you’re telling about the product you’ve just launched/your latest release.  Ideally this should be published -partly because it’s more efficient to say it once and link to it than to answer the same question over & over again – but also because you’ll be part of a conversation and the people who engage will give you valuable feedback.  (At GDS we famously blog about pretty much everything, or publish things as part of the Service Design Manual.) The same principle can apply internally, for things you’re not yet ready to share publicly. You can use a Google doc or a wiki page or another shared place to publish the latest on evolving thinking – that way everyone can take a look and if you need to get together for a discussion you can, rather than having distracting and repetitive conversations going on all the time.

4. Use your data.

This should be pretty self evident, but the data you have about your users and how they are using and responding to your product should be informing the work you’re doing to iterate and improve, and also be a big part of the story you’re telling – internally and externally.  This is likely to be a mix of the usage data you’re capturing, but also insights from user research and feedback.  Decisions that are based on data are usually better decisions, and easier to explain and to defend (if need be!).  Have a think before you launch/release about the questions you’re going to want answers to post-launch. Are you set up to capture the relevant data? Do you know where to look for it or to to ask when you need it?

5. Manage your stakeholders.

Just as you’ll have processes in place to manage feedback from your users, so you’ll want to have processes in place for interacting with your stakeholders. If you don’t it could get noisy and frustrating for all involved. Be proactive and prepared. Let them know in advance the most effective channels for feedback, and the best way to get the latest info. Where should they look? What can they expect?  Ideally have someone in the team focused on managing this, to make sure you’re hearing the priority suggestions or concerns, and that your stakeholders are kept well informed. The amazing @jennijjmoss and @ElisseJones definitely showed us the way on this one at GDS.