The power of ‘so that?’

‘So’ and ‘that’ are two little words that pack a mighty punch. If you’re trying to bring about change or want to spend your time delivering more useful things then they can be your secret weapon.

Roses in guns - my kind of secret weapon!
Deploying your (peaceful) revolutionary secret weapon. Image by Shepard Fairey.

Over the years I’ve found myself using them in conversations with senior leaders, product managers, tech evangelists, school governors and even friends and family.  Usually this happens just after one of these has told me, with great conviction, about a thing that must be done, or written, or bought – to which I respond simply (and sometimes skeptically) ‘so that?’

I realise this might seem pretty annoying at first, but it’s amazing how it can lead to really useful conversations about what it is they actually want to achieve – the end and not the means.

It all started with a story

If you’re already familiar with using user stories to express needs to be met, then you’re probably already a fan of ‘so that’. I first learnt to express what I wanted to achieve in this format as a product manager working with agile (Scrum) delivery teams – but I’ve since realised it’s powerful in pretty much any context.

If you’re not yet familiar with the user story format, it goes like this:

As a [person]
I need [to achieve this goal]
So that [this outcome/benefit is realised]

So for example

As a home owner
I need to provide accurate readings of my electricity use
So that I only pay for what I’ve used

(This need used to be met by letting someone in to read the metre, then you could do it over the phone, then online, and now via a smart metre. The solution has changed over time, but the underlying need and ‘so that’ hasn’t).

Or even

As a finance director
I need to understand the benefits of your proposal
So that I can approve your budget

Creating more productive places to work

I spend a lot of my time now helping organisations figure out how to make the best of digital opportunities, and that often includes having to change how they approach things like approvals and reporting. It’s amazing how often I’m told “we have to fill in this template and send it to these people” or “we have to produce this report for this board”. These are exactly the sorts of statements that I meet with a simple ‘so that?’

What’s important is understanding the need that lies behind the task, so that you can work out if there’s a better way to meet it (or indeed if it needs meeting at all).

So, for example, if the need behind writing a report is that the senior management team need to see what progress you’ve made, so that they can continue to support your work… why not encourage them to come along to a regular ‘show & tell’ where they can hear direct from the team, rather then you and them having to invest time in a static report that’s out of date by the time it reaches them? Or if they can’t make it in person, why not film the session and share it with them, so they can catch up on your progress at a time that suits them?

Organisations are stuffed full of processes and habits that people follow because that’s just the way it is. These are the things that slow us down, sap our energy, and get in the way of change. They give the illusion of progress, because people are busy and forms are being filled in and meetings are happening… but are the right outcomes actually being achieved?

It’s all about people!

At the end of the day organisations, and their internal workings, are created and shaped by people. If we use user stories to understand the needs and motivations of our external users and customers, so that we can build things that they want to use, why don’t we also apply this same approach to our colleagues? Afterall – they are all people too, with needs and motivations… even finance directors!

The great thing about ‘so that?’ is that it doesn’t seem threatening or revolutionary. It’s just a very simple question that anyone can ask.

So next time you’re faced with someone suggesting or demanding something that doesn’t sound quite right to you, and you think they’ve jumped to a solution without explaining what it is they really want to achieve, I’d recommend deploying the ‘so that?’. You might be surprised by what it can achieve.





It’s good to talk. It’s even better to draw.

The title of this post could actually apply to any situation where grabbing a Sharpie or a board marker provides more insight than just talking.  Which in my experience is pretty much all situations!

However, this is specifically about a game I’ve developed that helps people to share the things that get in the way of doing great work, and to come up with some practical suggestions for how to overcome them. The instructions for the game are included below.

A “Cadavre Exquis” by Tanguy, Miro, Morise &  Man Ray in the MoMA collection

Along the way I’ve accidentally channelled Freud, tapped the Surrealists, and shown rooms full of conference delegates pictures of naked creatures with tennis racquets for feet. (It turns out this is actually quite tame compared to the things produced by the delegates themselves – examples at the bottom of the post!)

I first experimented on the obliging folk at UX Bristol 2016, and then played it again with the rather more international crowd at Service Design in Government 2017.  Both groups really went for it, and people asked me to share the format so they can try it on their unsuspecting colleagues. This is for them, and for you too if you’d like to have a go.


Childish beginnings

The idea originally came from the game of paper consequences I played when I was a child – the one where you take it in turns to draw parts of a body and end up with something cute and innocent like this cat produced by US school children.

Then I discovered it was also something the Surrealists did when they were exploring their subconscious, under the influence of Freud. They called them Cadavre Exquis (Exquisite Corpses)… which is clearly a totally appropriate thing to adapt and try at a conference, right?

I went for it, and this is the version we played.

Setting up

The game is best played by small groups of people sitting at shared tables, 4-6 people per table is good. You can have as many tables as you like, but it’s ideal to have 4 or 8 tables so that everyone has a go at each part of the body.

Each table needs a sheet of flip chart paper, some post-its  and enough pens for one per person, preferably in a range of colours. You may also want some blue-tak to create a  gallery at the end.

What’s stopping you?

You need to agree 4 common blockers to work on. The first time we played we only had 60 mins so I crowd-sourced a few themes on Twitter in advance, stuck them up on the wall, and asked the participants to vote for their top 4.   The second time we had 90 mins, so we sourced the themes from the room.

IMG_0244Each participant takes a few minutes to think about what stops them doing the work they want to be doing (e.g. great service design). They write one blocker per post-it, and add these to a wall where clusters of similar post-its should start to emerge. Once you have some clear themes give them snappy titles and ask everyone to vote for their top 3. You can do this with stickers, or just ask people to mark them with their pen. You can then pick the 4 themes with the most votes.

(If you’re interested, the 4 themes at UKBristol were: 1. People thinking UX just means design 2. The “business” adding things that don’t help the user 3. The opinions/preconceptions of colleagues 4. Not enough time.  At SDinGov they were: 1. The effort of bringing people along with you 2. Organisational silos 3. Confusion around what “service design” means 4. Not enough time.)

Get ready to play!

Before you start each table needs to fold their sheet of paper in half from top to bottom, and in half again, so that they have four equally spaced horizontal strips across the sheet.

These are then the instructions…

  1. Write the first blocker top left of the top strip
  2. Does this sound familiar? What does it feel like? Discuss around the table for 5 mins
  3. Someone who fancies having a go at drawing captures the conversation – using a head. This needs to fill the right hand part of the strip, and you need to leave a bit of neck sticking out over the fold
  4. What might help in this situation? Discuss around the table for 5 mins (this is the really valuable part, so you can taken longer on it if there’s time)
  5. Capture the main suggestions as bullet points, next to the picture
  6. FOLD! Pass it on to the next table…

Repeat the above 3 more times – drawing a body & arms for blocker number 2, legs for blocker 3 and feet for blocker 4. Someone needs to be strict on timings and keep things moving along.

At the end of the last round you can unfold and admire your work!

Where do you go from here?

As produced at SDinGov17

It’s good to stick your creatures up on a wall and have a chat about what you see.

Are there some similarities? (e.g. when we looked at “The effort of  bringing people along” at SDinGov two of the groups had drawn two headed creatures, so we could talk  about why that was).

What suggestions stand out? What are you actually going to take away and do differently?

Regardless of what gets taken back to the day job everyone involved is likely to have benefitted from an opportunity to get things off their chest, to realise they are not alone, and that there are things they can do to unblock their work.

These are in fact rather similar to the benefits of running an agile Retrospective… but with more two-headed creatures and tennis-racquet shoes.

Some of the offerings from UXBristol


Service design is for everyone

There’s a lot about service design that’s good and powerful and exciting for the public sector, but as interest starts to grow there’s perhaps also a risk of some unintended consequences – particularly for smaller or less well funded organisations.

What’s in a name?

To begin with there’s a lot packed into the term service design, so it’s potentially open to misinterpretation or even abuse.

My personal take is that there are three main things going on. I’m not suggesting that this is the definitive way to view it (far from it!) I’m just breaking it down in the hope that it helps to make more of the good stuff happen. I’ve also hugely simplified things in the interest of brevity.

1. Culture

Firstly – there’s a mindset that can be applied to improving services and which involves understanding things from a user’s perspective, end to end (from trigger to goal), in a pleasingly holistic way (internal, public facing, partners etc).  Let’s call this first thing ‘service design mentality’. It’s about culture and attitude.  Even starting to achieve this in a deeply siloed, process or policy driven organisation can be hard work.  

(As an aside… ideally this mindset shouldn’t even be limited to services, but should instead start by looking at an area of need or a desired outcome and asking how those needs or that outcome can best be met. So success might actually involve designing the service out of existence altogether.)

2. Tools

Secondly – there are tools, activities and techniques that can help people with a service design mentality to make improvements to services and outcomes. Many of these are highly visual and collaborative, and draw on various kinds of research. Some of them have been around for a while (like empathy maps and user journey maps) but they’re starting to be brought together in more joined up and powerful way.  There are a lot of tools and toolkits out there – some of them are more helpful than others. None of them will be very helpful if you haven’t already got a service design mentality.

3. People

Thirdly – there is a relatively new (to government) professional design discipline called Service Design (I’m going to capitalise it from now on). The Royal College of Art now offers a MA in it. There are an increasing number of people out there who describe themselves as Service Designers and places like GDS and FutureGov have been hiring them.  In very simple terms a Service Designer could be described as a professional designer who is employed to have a service design mentality and use service design tools to improve services/outcomes.

However, I strongly believe that you don’t have to be a Service Designer or hire Service Designers in order for you and your users to benefit from service design.

As Matt Edgar very eloquently noted last year – most of government is mostly service design most of the time.  And, as he also says, it ‘can and should be everyone’s business’.

Don’t make it too exclusive

In an ideal world everyone who works in public service should have a service design mentality, and should be able to access, understand and confidently use service design tools.

I don’t think this should be a specialism, I think it should be a defining characteristic of the public sector.

That’s not to say that the Service Designers don’t have an important role to play, particularly in these early days. We need them to lead the charge, show us how it’s done, and develop even better tools.  But we also need to guard against the perception that service design belongs to them alone, particularly as there are large swathes of the public sector that probably won’t be able to find or afford them.

Here are a couple of other things that I think we need to watch out for:

Don’t make it too Kool

There’s a fine line between creating a buzz and creating a cult.

We need to guard against a cult of Service Design just as we still need to guard against the cult (or tyranny) of Agile. (I’m a big fan of both, but not of the dogma that can sometimes come with them.)

As summed up nicely by Lindsey Keighley on behalf of GDS the important thing is to ‘be agile, not do Agile’. Similarly, let’s get on with delivering successful services and outcomes using the best means possible, rather than on ‘doing Service Design’.

It’s useful to create a buzz about something new and powerful, and to have a hashtag and a conference or two, but let’s do it in a way that’s accessible to everyone who might want to give it a go. More common sense than dark art.

Don’t forget about delivery!

In her post on what GDS mean by service design Louise Downe is very clear that

‘For us, service design isn’t about mental models or double diamonds. It’s about working with users and delivering services.’

A sentiment very much brought to life by Harry Trimble, one of the Service Designers in her team.  

This is definitely reassuring, and I don’t doubt that where GDS are involved the services that are designed will also be deliverable and delivered.

However, amongst the less determined I think there’s always a risk that design activities might become dislocated from delivery.  The world is already full enough of dysfunctional teams where designers (or policy makers!)  hand over beautiful but unrealistic designs to baffled developers or front line staff. One of the major benefits of the agile ways of working championed by GDS and others is that a multidisciplinary team work together on delivering working solutions, one iteration at a time. I know it’s not intended that Service Design should become an up front idealised design activity – but in the wrong hands it could.

This toolkit poster, for example, seems to imply that service design stops after feasibility, but if that’s the case you’re walking away before anything has actually changed for the end user. Service design isn’t just a phase of work – it actually needs to deliver outcomes! 

What next?

So how do we make sure that everyone who works on or uses public services can benefit from good service design?

Some teams will be privileged enough to work with professional Service Designers – but not all.  How do we enthuse and support the rest? (Including, of course, people in local government.)

Teams that have already had experience and success sharing honest and quantifiable stories is a good start – which is where the blogs, hashtags and conferences come in handy. But this does need to reach the people who commission and run services – not just the people who follow the latest design or digital trends.

Sharing tools and techniques will also be useful – although in context rather than in a vacuum. The right tools applied with the wrong mentality can be definitely lead to unintended consequences, and can also start to really muddy the waters (I’ve seen that a lot with the use of agile).

And how to you foster a potential ‘community of practice‘ for service design if that community could potentially involve… everyone?! Particularly if the people who need the info and support don’t see themselves as service designers.

This post is already long enough… and I don’t have tidy answers.  But I do believe that service design in its broadest sense has the potential to unlock so many benefits for the public sector that it needs to be owned and embraced by everyone.


Discovering discovery

Not enough people actually begin at the beginning.

Often when I meet teams working on service transformation, or digital change projects, I find that they’ve begun somewhere else. Perhaps their work began when someone decided the organisation should be using a particular system, so they’re busy trying to implement that, or someone thought a particular process should be put online, so that’s what they’re doing. They’ve been presented with a solution and told to make it work.?

And all too often the people dictating those solutions are being driven largely by internal factors – the need to make short term savings, a contract coming to an end, a budget to spend by the end of the year, a boss to impress.

This tends to result in teams who are doing their best, but are feeling rather put-upon and disempowered; teams who find that the priorities and targets aren’t entirely clear, or that they keep shifting; teams who can’t really explain the purpose of what they are working on, or who it is for, or what will happen to it after they’ve finished their particular project.

Worse still, the people who ultimately have to use the product or service are also likely to be unhappy – faced with an experience that doesn’t really work for them, because it’s based on managerial assumptions, or because it’s had so many things bolted on along the way that it’s become unusable.

The art of discovery

In my experience the best way to avoid ending up in this painful and often expensive mess is to go through a ‘discovery’ process upfront. The time you spend on this, whether it’s months, weeks or days, will be time extremely well spent. It will help you to focus on your users and their needs, and to come up with realistic plans that the whole team can buy in to.

As far as I’m aware there’s no fixed formula for ‘discovery’ and although other people (like GDS and the Design Council) agree that it’s valuable there aren’t many detailed templates or guides out there. I’ve therefore developed an approach that makes sense to me, and (more importantly) to the teams I’ve worked with.  It isn’t possible to cover all the detail here in a single post, but I’ll share some of the main principles and steps.

It’s as easy as 1,2,3

The way I see it, there are three stages within discovery:

  1. Learning (about your users, and about business drivers and constraints)
  2. Sketching (generating and testing ideas)
  3. Refining & planning (prioritising and working out what to take into delivery)

I tend to present these as a diamond (similar to the Design Council’s) as this helps to illustrate that the team are opening up their thinking before focusing in on specific solutions and plans. (And it really is important that it’s a team going through this… more on this below.)

The main stages of discovery
The diamond of discovery

If you’re tight on time –  and provided you’ve got access to the right data, research and people – you can rattle through this in a week or two if you really have to. But if you’re working on something new or complex, or if you need to do some fresh user research then things might take a little longer. (The government Service Design Manual recommends 4-8 weeks of discovery.)

Who’s in the team?

There’s no one answer to this, but ideally you need to involve:

  • Someone to keep things moving along. In an ideal world this is the product or service “owner” e.g. in places where you have specific Product Managers. However,  this could also be a project manager supporting the service owner, or it might even be an external facilitator. The most important thing is that they understand the purpose of discovery and can bring together the right people in the right setting to keep things moving in a productive direction.
  • People with real insight and experience – about your users and their needs, about the business and its priorities and constraints, about the technology context and possibilities. A well run discovery process will tap in to all of this and help everyone to share what they know and work towards solutions they can all support. (Some of these people might just come along to certain workshops rather than being involved on a day to day basis.)  What you don’t want is observers and passengers – if someone doesn’t have relevant insight or experience to share then they shouldn’t be in the room!
  • The people who will be delivering the solution. Often these will be some of the people with the best insight and experience – so we’ve already got them covered.  You won’t be able to invite all the people who will be involved with delivery, but you definitely want the key areas represented. Often this will be an internal tech lead, perhaps your lead user experience person, and someone representing the business and/or customer service teams who will be involved with running the service. If your delivery is largely outsourced then you’ll need to involve your suppliers along the way to bring insight about how their world works – but be wary of letting them dictate solutions, particularly if you’ll be putting things out to tender.

Often the people brought together during discovery might never have met or spoken before, even though they’re all involved in aspects of designing and delivering a service. Discovery helps to cut through internal silos and bring together a group of people who can look at a service holistically and develop a shared sense of purpose and ownership.

Nitty gritty

There are various workshops and activities I use to take teams through discovery. These involve everyone in the team, a wall, and a lot of post-it notes and marker pens. Discovery is driven by conversation rather than documentation, so the approach needs to get people talking and thinking and sketching and asking questions. The wall becomes a living repository of all of this, and a reference point for the team.

Two teams mapping user needs
Two teams mapping user needs

The main events tend to be:

  • What do we know?workshop This sets the scene and gets people sharing existing headline data, research and insights. I tend to cluster things in a few key areas: User and their needs, Business context (drivers, targets, constraints), Tech and delivery context, and sometimes also Process and workflow context.  By the end of the workshop everyone has a shared understanding of the context they’re working in, and some of the problems they might want to solve. They’ve also identified and prioritised gaps in their knowledge to focus on filling in the next few days.
  • User needs mapping workshop This helps the whole team to walk in the shoes of their users, identifying needs from trigger to goal. It depends on having access to real insight about those users. I find it helps to start by building an empathy map of each prioritised user group, and giving them a name. These names are then a handy shorthand throughout the process, as everyone knows the set of characteristics and needs summed up by “Anita” or “Bill”.
  • Sketching workshop The team start to identify possible solutions to meet the needs of their external and internal users. I build things up in layers, starting with the user needs at the top, and ending with candidate solutions at the bottom.

In each case the workshops are designed to trigger the thinking, talking, researching, sketching, testing and planning that the team then go off and do. i.e. the real work happens in-between the workshops, ideally facilitated by daily stand ups in front of the wall.  This also presents lots of opportunities for other interested people to see how things are going – using the “show don’t tell” approach to governance and comms.

One of the hardest things is stopping people jumping to solutions too early. It’s really important to stick with needs, data and evidence until you’ve really understand the problem you’re trying to solve, and the outcomes you’re seeking to achieve – and only then get in to sketching solutions. You’ll be surprised at how many options you can come up with by doing this, giving you lots to then prioritise and potentially iterate – one “why” and many “whats”. Discovery can give you the foundations for a whole roadmap of service improvement.

So is this ‘Agile’?

I believe that a discovery process is valuable regardless of the approach you then take to delivery.

If you are going to be using an agile approach to delivery then a good discovery process can produce a prioritised backlog and a roadmap. (This could be a backlog of detailed user stories or perhaps just a list of epics to refine later, depending on the time available and the preferences of the team).

If your solution is going to be largely (or partly) delivered by suppliers you’re likely to be a much more confident and discerning client if you’ve been through discovery. You’ll be able to articulate your requirements in terms of the problems you want solved, and the outcomes you want to achieve, and you’ll be able to assess the solutions they propose based on what you’ve learnt in discovery.

And if you’re really keen you may even find yourself applying the principles of discovery to small everyday tasks too. If someone starts a conversation by stating “what we need is…” then maybe push back and ask “what’s the problem we’re trying to solve? What evidence do we have? How will we know we’ve been successful?”.  We all have a tendency to jump to solutions and to make assumptions – but if we do that, we’re not really beginning at the beginning. And as Maria once taught us – that’s a very good place to start.

Julie Andrews telling it like it is
Julie Andrews telling it like it is

If you’d like to have a chat about the detail of discovery, and how it might work in your organisation, then do get in touch via the comments below, or via my About page. 


Could the devolution of power to cities and regions help super-charge the work on local digital services?

As I write this post the debate around the devolution of powers to UK cities and regions is

Bristol at night
With thanks to

hotting up. No doubt by the time you read it the details will have changed – but it seems highly likely that whoever is running the country after May 2015 they’ll be conceding some powers and funding, or fundraising opportunities, to some of our larger cities and regions (“metros” as the City Growth Commission calls them).

Much has already been said about the approaches or models that might help deliver high quality digital services across local government – with “one site to rule them all” at one end of the spectrum, and voluntary standards at the other.

Much as I admire and support the great work being done by practitioners like LocalGovDigtal, my view is that bottom-up voluntary best practice isn’t going to be enough. Even if I believed that this alone would get us to consistently good and affordable services eventually (which I don’t), we simply don’t have the time to find out – the funding situation is too acute, and the expectations of citizens accustomed to interacting 24/7 online are already raised too high.

There are also far too many chief execs, service directors and elected members who don’t yet understand the need for digitally enabled service redesign (including assisted digital), or the scale of the opportunity, or the extent of culture change required to bring it about.

We need to get their attention.

Even amongst the more engaged there seems to be a leadership vacuum. At events I’ve been to with representation from DCLG, the LGA, and Solace as well as execs and councillors from local authorities, everyone has been happy to agree that standards need to be raised, skills developed, opportunities seized, and that some leadership is needed… But no one has been prepared to step forward to lead, or even to suggest who might.

In central government, when GDS was created, it wasn’t enough to have a team of experienced people, or to say what good looked like, or even to show it via Alphas and exemplars – the new digital standards had to be made mandatory, and tied to access to funding (specifically spend controls). Yes, there’s a nice juicy carrot in positive user feedback and improved performance indicators (including savings), and ideally this would be enough to incentivise change, but I don’t think this alone will bring about the shift needed. I suspect we also need some stick.

I believe we need a new mandate or settlement or hard incentive to accelerate the pace of digitally-enabled change across local government – and that perhaps the devolution of powers to cities and regions might provide that opportunity.

Imagine a devolution deal which insisted that x% should be spent on digitally enabled service redesign, to an agreed set of standards and even a timetable. Or, if that degree of ring-fencing is too strong, how about mandating standards or expectations with targets and metrics attached, regardless of spend? In July Ed Miliband suggested that his version of devolution would come with “checks and balances”, with the introduction of local public accounts committees and the requirement to publish performance data. If this approach gets developed I’d want to see digital and service design standards as part of it.

Sticks aside, stronger cities and regions could also lead the development and sharing of digital expertise. Some commentators and practitioners are, probably rightly, sceptical of a central (London based) digital team for local government – but what if there were centres of excellence in each of the large cities, each perhaps running digital academies or events for council staff in the surrounding authorities?  Would it also be more acceptable if the guardians of digital standards were up the road, rather than inside the M25?

So, do I think we need national standards for service design and digital? Yes I do. Do I think these need to be mandated in order to be truly effective? Yes. Does this mean a central team in London taking control? No, it needn’t. I think we need many centres of excellence, not just one, and I’m hoping that if we get devolved cities they might help lead the way.

GDS for local? A shopping list, not a monolith.

There’s been a lot of renewed chat recently (see below) about  “a GDS for local government’ or “GOV.UK for local goverment” but I’m curious about what people really mean when they use these terms. What is it that “GDS” represents in these conversations – a central team of specialists? A set of standards? A publishing platform? A mandate? All of the above?

I’ve only spent a few months looking into and working with local government, so my thoughts are still forming and I still have much to learn and observe. However, even with that caveat, I’m already convinced that the current approach – where over 300 authorities spend their increasingly scarce resources independently trying to meet the same set of needs and solve the same set of problems – is fairly bonkers. Particularly when in many cases the solutions they end up with are way more expensive and less flexible than they should be. Oh, and not great for their customers either.

This isn’t sensible, and it isn’t sustainable. It’s also not fair on the amazing people in local government who know it isn’t ideal but who don’t have the tools, or support, or budgets to change things. It’s one of the things that got me out of GDS and involved with this in the first place.

Being a user-centred agile kinda girl I’m not comfortable jumping to solutions before I fully understand the problem, but I’m also not comfortable with the way that “a local GDS” and “GOV.UK” are being used – sometimes interchangeably – as shorthand for some kind of fairly abstract all powerful centralised solution, something “monolithic“. (With apologies for Rob for singling this out!)

It may well be that some of the approaches GDS have taken, and some of the things they have delivered, should form part of how local government delivers information and services in the future. But that covers a lot of different activities and products. Maybe we should think about which of those might be useful in the context of local government – to move from the abstract concept of “a GDS” into the constituent parts.

So as a starter for ten – if there were a shopping list based on the types of things GDS is currently providing for central government, which would you be buying into for local government? And who might be providing them?  That list might include these kinds of things (illustrated with central gov examples for now):

This isn’t a complete list, but the point I’m trying to make is that GDS represents many things, some of which would be more difficult or controversial than others to apply across local government.

I’m interested in having a more practical conversation – one based on the needs to be met and the opportunities to be realised, and only then the models and structures and teams and technologies that might best deliver against those.  If you start by talking about the governance and politics you may end up in an unhappy place. If  you start with the problem you are trying to solve, and think about it in manageable chunks, you can end up achieving something extraordinary.

(Some notable recent contributions from Ben Welby, DXW, Phil Rumens, Rob Miller and Socitm. Also interesting to see the programme of events, training etc that DCLG are offering this year.)


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.