Post-launch survival tips

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.Look after yourselves
(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!

Respect the process2. 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.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.

IMG_21264. 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.IMG_2127

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.

Advertisements

Girl talk

October 16th 2012 was Ada Lovelace day and it prompted a small flurry of articles, posts and podcasts bemoaning the lack of women in tech and wondering what could or should be done about it.

Ada Lovelace by Alfred Edward Chalon
Ada Lovelace by Alfred Edward Chalon

I didn’t join in at the time – perhaps because I was rather busy launching GOV.UK that night – I and many fabulous and talented colleagues, male and female. We reached over a million people on the first day and made it simpler, clearer and faster for them to interact with the UK government.

I could perhaps claim that being the proud if exhausted Product Manager of that product, on that day, was a more fitting tribute to Ms Lovelace than any tweet or comment or turn at a women’s networking event.

But that would be to suggest that, in the midst of all the hard work and euphoria, I was thinking about Ada, or even conscious of being “a woman in technology”.  And if I’m honest, I wasn’t.

What I was conscious of was everything that can be achieved when passionate, creative, experienced, proactive people come together and listen to and respect each others’ views and skills – regardless of their gender.

So it is only this evening that I’ve finally found and read those articles, and looked for those networks, and that’s because I went to listen to Martha Lane Fox speaking at a Nesta event and the subject came up. Again. In fact, I even tweeted Martha’s comment that women in tech should “Stand up, lean in & shout!” and in doing so I realised I’d sort of joined in, and perhaps it was time to form an opinion.

So here is my opening salvo.

What strikes me is that the discussion too often seems to centre around the relationship between girls and computers and how they need to be encouraged to “do IT “at school, or to write code – as if this alone will redress the gender imbalance at the top of tech companies and in the tech community as a whole. (The Indy took a broader view, but only just).

But surely computers and code are now a means to an end, many ends in fact – digital technology is about connecting people, and understanding their needs, and communicating, and being creative, and solving problems, and collaborating, and creating products that people want to use.

And, unless I’m missing something, I think girls tend to be quite good at those things – in fact possibly better than boys at some of them (I have no data – I’m just jumping on the gender stereotype bandwagon! But I also speak as a woman with a degree in English Literature who’s never written code, but who’s been able to work on some pretty big digital projects).

The computers and the code are the tools that make all of this possible, and yes, we absolutely do need talented people who know how to wield them skilfully – be they male or female. But TV is about more than cameras, newspapers are about more then typesetting, and creating great digital products and experiences is about more than computers.

So maybe, in 2013, we could talk less about IT and more about digital products, less about coding and more about understanding the needs of real people, less about “geeks” and more about creativity. And perhaps if we did that we might do better at attracting the full spectrum of people who will show us where digital technology can really take us… regardless of their gender.