Month: November 2012

Agile content strategy (or how I learned to stop worrying and love the Post-it)

By now, I will have spoken about agile content strategy at the Content Marketing Show: if it was a success, my slides are here for you to gaze at in wonder; if it went badly and my voice was a barely audible because my throat was constricted with terror, here are my slides, plus a blog post explaining what I was going on about.

I work for uSwitchforBusiness, which is a leading business energy broker, we also have two other brands: Business Juice, which is a business energy broker targeting a slightly different audience; and Energy Forecaster, a website dedicated to helping businesses work out which way the wind is blowing on energy issues.

We’re owned by Forward, a media technology company, which also owns uSwitch, the domestic price comparison site.

I’m responsible for content, social, organic search and PR for uSwitchforBusiness, Business Juice and Energy Forecaster and until three weeks ago I was doing this on my own. It’s a lot to keep on top of, and this is really a case study in desperation – it’s about how I try to make the best content with limited resources, using an agile approach.

uSwitchforBusiness and Forward are both really committed to agile on the software development side of the business, as is uSwitch, where I spent three years before moving to uSwitchforBusiness. After spending time working with agile developers, I started to think that it would work really well as an approach to content strategy too.

Slide 3 is a diagram showing how I see an agile content lifecycle, and I’m going to go through each of those steps in detail below, using Energy Forecaster as a case study.

Energy Forecaster (slide 4) is a pure content project, which went live at the end of May. As a business energy broker, we want to get businesses to switch their energy supplier, but the truth is, most business owners don’t bother and rarely think about gas and electricity. But when you press them on it, you find that many are under a lot of pressure because of rising energy bills – around 7% say they could go under if prices carry on going up at the current rate – but they feel powerless when it comes to doing something about it. With Energy Forecaster, we’re trying to use content to help businesses to feel in control of energy and prepare for the higher prices that are coming in the future.

Everyone in the team was really excited about the project, and we all had a lot of ideas for features and content that we wanted to see. When we started to spec out the project, the list of features and content was pretty breathtaking. Slide 5 is a photo of some of those features written down on Post-its (hence the title of this post ‘Agile content strategy: or how I learned to stop worrying and love the Post-it’ – they feature heavily in this presentation). People wanted multiple blogs, a news centre, guides, a walk-through for first-time users, user account management, Q&As, FAQs, a ‘lobby zone’…but at the same time, the time scale to get the site up and running was only about two months, and we had one part-time designer, one developer and me. If you look at the website again, you can see it’s actually very simple – sparse even – and it was an agile approach to content strategy that was at the heart of the simplification.

Step 1 – Ask why, not what
Slide 7 is what we call a story – I write one for every feature, content type and piece of content that goes on the site.

The format is ‘As a _____________, I want to __________________, in order to _____________.’

It should almost always start ‘As a user’ but if you have a specific kind of user in mind, or if you use personas, starting with those is even better.

I love this format for two reasons:

  1. It puts the user and what they’re trying to achieve at the heart of what you do.
  2. It doesn’t assume anything – it starts with a problem or a need, leaving you free to explore different solutions.  

Slide 5 was a long list of ‘whats’  – I narrowed it down and refined it by turning it into stories that ask ‘why?’ 

A word of warning – this can make you unpopular. When people are excited about an idea, and you ask them to justify it, and they can’t, it’s like pouring a bucket of cold water on them. But I think you have to do it if you want a website that isn’t full of features people don’t use and content people don’t read, that cost a lot of time and money to produce.

However, you can soothe people with the next step in the lifecycle:

2. Don’t wait, iterate
Slide 8 shows an old printing press, and the beauty of digital when it comes to content and publishing is that this isn’t like the days of print, you don’t have one shot to get it right – you can publish once, then published again five minutes later. Content shouldn’t be created and then left to stagnate, you should always be improving it with iteration after iteration.

I think it’s helpful to think of the lean notion of the MVP or minimum viable product. Ask yourself what’s the bare minimum you can go live with that still provides user with value. Get something quick and dirty live, start testing and getting feedback on it and then see if the idea is worth pursuing. You might find it’s not worth it, or that it needs to go in a different direction, saving you time and money.

For example, with Energy Forecaster, we’re dealing with some complicated subject matter that’s time-consuming to research. So rather than waste days or weeks working on content that I’m not sure users want, I’ll prove the concept with short post of about 300-500 words – if it works I’ll go ahead and produce something longer and more detailed.

I’m already jumping on the the next step:

3. Analyse 
To analyse my content, I like to run retrospectives.  There are a lot of different ways to do a retrospective, but I like to keep it simple.

In a retrospective, I get all the Post-it notes with all the stories I’ve worked on and discuss them and put them in one of two categories (slide 9):

  1. Things that didn’t work.
  2. Things that did work.

Then I’ll look at the two lists and come up with actions (also written on Post-its) – these could be very specific, for example if a specific piece of content needs improvement, or they could be more general, like observations about how to work more efficiently, or a process that worked particularly well.

It’s vital not to rely on opinions – you also need data.

Now, I’m not an analyst, but these are a couple of simple Google Analytics reports that I use to see how my content is performing.

The first is a page-by-page custom report (slide 10), it looks at pageviews and conversions, which are two pretty standard measures of success. I’d argue that looking at pageviews alone is a total waste of time though – you could h
ave a million visits, but if all of those people bounce in under a second, then they may as well not have visited, so I also look at bounce rate, time on page and social actions. Those three metrics give a good indication of how people are interacting with your content – are they finding the information they need, are they reading the content, do they like it enough to share it?

The second report (slide 11) looks at visits, time on page and time on site by keyword. I like to download all the data, and then go through and group the keywords thematically – this is time-consuming, but very worthwhile. I then turn it into a pivot table (slide 12) which gives you a great insight into how your users are interacting with your content. For example, the row highlighted in orange – keywords relating to rollover –  is an area where I can see the content isn’t quite up to scratch; the number of visits is fine, but time on site is way below average – only about 40 seconds, and the bounce rate is above the site average, so I know that I need to do more investigation and work out why, for example by looking at the keywords individually to see if there are any user needs I’m not meeting. By comparison, the line in green – out of contract rates – is performing well, time on site is over eight minutes and the bounce rate is low, but our content on the topic is actually just one paragraph in another guide, so on the basis of this, I’d say it’s worth building it up into a bigger piece of content.

So by doing a retrospective and analysis, you’ve got all the tools you need to do another iteration, then analyse again, then iterate again, then analyse again…you get the picture (slide 13). This cycle can go on indefinitely – content shouldn’t stand still, you need to revisit it, update it, expand it, change it and keep it fresh, until it comes to the end of its lifespan – this could be because your user have changed, your marketplace have changed – in which case you have break the cycle of analysing and iterating, and go back and ask why again, to find out what it is that your users need now. (slide 14)

So to summarise (slide 15):

  1. Buy Post-its
  2. Ask ‘why?,’ not ‘what?’
  3. Don’t wait, iterate
  4. Analyse
  5. Do it all over again