How 3 researchers used the ‘jobs to be done’ framework

Earlier this year, strategist and researcher Stephanie Troeth and Adam Warburton, Co-op’s Head of Product, gave some of the Co-op Digital team Jobs to be Done (JTBD) training. Since then, our digital teams have tried out this way of working.

A quick introduction

JTBD is a framework for understanding the outcomes users are trying to achieve – this could be a job, a task or more widely their goals in life.

It’s been particularly popular in commercial organisations because it helps us understand where users underserved needs are and, therefore, where the opportunity for the business is in the market. More traditional user needs frameworks don’t say much about the market, and as the Co-op is an organisation looking to make a surplus to put back into member initiatives and community work, we thought it could be useful.  

In this post, 3 of our user researchers talk about their experiences using JTBD.

Vicki Riley, Ventures team

Functional, social and emotional motivations

We’re working towards developing, testing and improving an online platform that connects customers with products from independent sellers, providing benefit to their local community. It’s my job to understand the needs of customers and sellers so we can provide mutual benefit to both.

We used the JTBD framework to find out customers’ underlying motivations and desired outcomes for buying from small independent businesses. We also wanted to understand the competitor landscape from a customer point of view, and identify areas of opportunity, where customers are underserved in an area that’s important to them.

We started with interviews to identify functional, social and emotional jobs, and then created a survey to validate or disprove, then prioritise in terms of importance.

We found that JTBD has worked well while we’ve been facing a new challenge and figuring out a value proposition. This might be because it allows for wider thinking and delving deeper into motivations or desired outcomes, and takes the insights out of the current solution and up to a broader level that could be applicable across different categories.

It’s also been really useful when we speak to stakeholders. Categorising what people are trying to get done into functional, social and emotional needs helped senior stakeholders understand what’s important to people and also identify our value proposition. It became clear our proposition – the area where we were able to leverage some competitive advantage – was going to be more emotional, than functional or social.

It was the unintended consequences that people talked passionately about, for example, the conversations that buying from small independents allowed them to have with friends and the way it made them feel when someone complimented the thing they’d bought. JTBD allowed us to put our focus on these emotional and social elements when developing the service.

Simon Hurst, Healthcare and wellbeing team

A survey to identify underserved needs in the market

We wanted to understand where there were potential underserved needs so we could potentially build a service around them. To try and identify a gap in the market, we ran a survey to assess which jobs around getting access to healthcare we’d identified in interviews were more significant, and which of those users were unhappy with the current way of doing it.

It looked like this:

Screen Shot 2018-07-12 at 16.03.14

Our product manager Derek Harvie wanted to do the survey so we could back up our qualitative insights with some quantitative data. Seeing the data gave both the team and the stakeholders more confidence – data is, of course, very important to new businesses which is what the Healthcare team is aiming to be.

The results of the survey allowed us to map jobs according to whether people were underserved or not – and from that helped to determine the product strategy. This abstract graph is what we worked from:

Screen Shot 2018-07-12 at 16.04.31
The survey worked well. It’s given us additional confidence in our qualitative research. Whilst I can write a decent survey, I sometimes struggle to analyse raw quantitative data, so having Michael Davies, a data scientist at Co-op who could help us with that, was invaluable.  

However, writing a survey for JTBD is challenging. It necessitates a substantial use of matrix style questions. This results in the survey having lots of very formulaic questions, and runs counter to good survey design (something we’ve learnt a lot about through Caroline Jarrett).  

Also, recruiting people for surveys is expensive. Current quotes to go out to non Co-op members is between £3 to £5 per participant. We need to find a way to get these surveys out more quickly and cheaply.

Naomi Turner, Communities team

The switch interview

I’ve been researching how and why people participate in communities. It quickly became apparent that there are lots of tasks involved even when community organisers wanted to do something relatively simple, for example, arranging a meet up. We were interested in:

  1. How people performed these tasks, eg, with a Trello board/ringing round/emailing community members.  
  2. What they were ultimately trying to achieve, eg, a community dog walking day.

Looking at these things together would help us see if there were underserved needs we could potentially build a service around.

I interviewed 3 types of community member:

  1. New volunteers.
  2. Volunteers who had stepped up to an organisational role.
  3. Volunteers who had recently stepped away from an organisational role.

We asked each of them to recall, in detail, when they have switched from using one solution, to using a different solution (for example, moving to Google Docs to record member details from Microsoft Excel). This technique is called a ‘switch’ interviews – it aims to help us understand more about what pushes someone to change their behaviour, and what the pulls of a proposition might be.

Screen Shot 2018-07-12 at 16.05.48
Image: Intercom

Once we had a broad idea of the kinds of generic ‘jobs’ that people were trying to do, for example, how they manage recruitment or finances, who opens up the hall they use – setting up a process routine which meant they as organiser could step back on some tasks), we could break these down further and see broad patterns of activity (the tasks they perform for example?) across people’s experiences, and why.

It was challenging to apply the functional framework to varied and emotive reasons for participating in groups to achieve an outcome. It was also hard to understand what outcome they wanted from their participation in the group.  Creating the most helpful level of abstraction is key to needs being useful to designers to work with, and something we got better at knowing. We went in too low level initially and had things like ‘handling cash’ when it was the higher level that was more useful to design solutions for, in this case ‘managing finances’.

Where we’ll go from here

Overall, we’ve found that JTBD is a useful way of working. However, we think teams would get most of of it if they look at it as part of a toolset rather than as a framework, and tweak their use of it depending on their specific situation.

Vicki Riley
Simon Hurst
Naomi Turner

How Co-op Insurance is making its marketing terms and conditions more accessible

Most people need insurance at some point in their lives but so few people read the small print before buying it. It’s not laziness on the part of the customer, member or consumer – it’s lazy content and bad design.

At Co-op Insurance, we’ve been making changes to our marketing terms and conditions (T&Cs) because we believe that everyone deserves to understand what they’re agreeing to when they tick a box or sign their name.

Part of my job as a direct marketing consultant at Co-op Insurance is to look after the leaflets and customer letters we send out. I teamed up with Sophy Colbert (a content designer at Co-op Digital at the time) to work out how we could present the small print in a clearer, more succinct way so we don’t alienate people with legal jargon.

Understanding the challenges

Regulations from the Financial Conduct Authority mean that there are certain things that we need to include. Thankfully, how we say them can sometimes be flexible. But writing T&Cs that are easy to understand, as well as legally compliant, isn’t easy.

When writing the legal parts, there’s a tendency to include more information to be certain that all bases are covered – there’s a misconception that saying something in a long-winded way might reduce risk. This is not only problematic from a plain English point of view but also in terms of the limited space there is.

We believe that through good content design and good visual design we can move away from this approach: instead we can say things once, clearly.

A simpler layout

Before we changed much of the copy, we changed the layout. Here’s an example of a leaflet from May 2017:

From May 2017, an example of how the T&Cs used to look. Text is in one big block. Hard to read.

And here’s our communication from June 2018:Example of Co-op Insurance communication from June 2018. Shorter copy, less crowded layout, easier to read.

Putting the terms into columns and adding subheadings makes the content feel less daunting because the shorter lines make it easier to read. Laying things out like this also makes it easier for us to check there isn’t any repetition.

Making the language accessible

According to the National Literacy Trust, around 15%, or 5.1 million adults in England have literacy levels at, or below, those expected of an 11-year-old. This means they can understand short, simple texts from everyday sources on familiar topics, but reading information from unfamiliar sources, or on unfamiliar topics like terms and conditions for example, is likely to be difficult for them.

With this in mind we’ve:

  1. Explained any terminology that we’ve been advised not to reword completely.
  2. Got rid of repetition.
  3. Been consistent with our choice of language.
  4. Improved the flow of the copy by taking out a lot of the brackets and incorporating information into the main sentences.

Nobody should be excluded from understanding what they’re agreeing to. Communicating simply and clearly is not only the right thing to do but it will help us build greater trust.

Increasing white space

Adjusting the space between letters and lines of text can make a big difference to how easy the copy is to read. We’ve made the size of the terms text slightly smaller than it was before, which might seem counterintuitive, but doing this meant we could add more space between individual letters, making it easier for the eye to identify the shape of a word. Making the type slightly smaller also means that we can increase the line spacing, or ‘leading’, slightly which makes it easier to scan.

The right thing to do

We believe we have a responsibility to make our marketing easy to understand and accessible to all customers and potential customers. This is our first step. We know we have a long way to go but content designers across Co-op are committed to inclusive design.

It’ll take time but we’ll get there.

Give us your feedback

We’d like your feedback on how we can improve further. How can we open up our communication more so that it’s accessible to even more people? Let us know in the comments.

Vicky Lowry, direct marketing consultant at Co-op Insurance
Sophy Colbert, content designer (ex) Co-op Digital

Karen Lindop: we’re hiring! Plus news from our latest All Team

(Transcript) Karen Lindop: Hello, and welcome to our update on what’s happening in the Digital team. Busy week this week.

On Wednesday all the team got together to share their work. It was great to have lots of the team members on their feet and talking about the work their doing. We heard all about digital coupons; our Design system; service design with our Food business; how we’re using our data ethics canvas; plans for one web and celebrating award success. Thanks to everyone who presented.

We’re looking for some new people to join us right now. We’re expanding the work on Funeralcare Guardian, and because of this we’re looking for product owner, delivery manager, BA, software engineer, platform engineer, QA, user researcher and interaction designer. If you, or you know anyone who might be interested then please get in touch.

You can also find out more about the Guardian roll-out and lessons learned on our Digital blog.

Also this week, some of our interaction designers have been involved in OH’s Catalyst programme – a 10-day alternative education programme for people looking to get their foot in the door of the creative and digital industry. Katherine Wastell and Jack Fletcher took part in a panel discussion about their design career paths. Then together with Nate Langley they all led a session called ‘Everyone is a designer’, which focussed on turning research findings into product opportunities.

That’s it for this week. Don’t forget to subscribe for all our updates on our blog and follow us on Twitter. See you soon.

Karen Lindop
Head of Digital Operations

Introducing our software development standards

There are many software engineers across Co-op Digital – they’re responsible for building our products and services. Because they’re all great and eager to build things well, it’s easy to assume that everyone will build things in the ‘right’ way.

However, that’s a risky assumption and it’s not always the case. Instead of leaving it to chance, Ian Waghorne, Andrew Liddell and myself started to create software development standards and pin down Co-op Digital’s previously unwritten guidelines.

Our aim was to come up with a set of software development standards that:

  • could be used across Co-op Digital
  • take into account the uniqueness of Co-op products, services and platforms
  • could potentially be used throughout the Co-op Group

The benefit of having a set of standards is to make sure engineers don’t move too far off track and build things in a way that their stakeholders aren’t comfortable with.

We started small and got feedback quickly

The 3 of us quickly compiled a set of standards. They were short notes, just enough to get feedback. When we shared them with the other engineers intense discussion followed and the feedback was that we’d been too prescriptive.

At Co-op we have many different services at various stages of their life cycle, each with different contexts. The feedback had told us that (fairly obviously) one size wouldn’t fit all – or rather, a set of standards with narrow and rigid boundaries wouldn’t fit all. The engineers working on certain services needed more flexibility to get the job done effectively.

Balancing flexibility with governance

The main challenge was making sure the standards were flexible and worked for our engineers but still met our wider stakeholders’ needs. What we needed was just enough governance to allow us to keep working quickly, while providing a good level of reassurance that we were not exposing the Co-op to an uncomfortable level of risk. We coined the term ‘outer governance’ to help us frame this.

Striving for clear, concise standards

We think that figuring out whether your product or service meets each of the standards should be through a conversation both within a development team and between the team and other stakeholders. To help facilitate the conversation, we thought carefully about how to word the standards so there’s less room for misinterpretation.

So, each standard contains:

  • a ‘motivation’ to explain why this aspect is important
  • a brief explanation of the standard with an example
  • a few questions to help teams assess the state of their product or service

Standards can be quite abstract and we felt that including the questions would help people really consider how each standard applies to their work.

Software standards could help us assess the condition of a service

In software development, teams often build up levels of ‘technical debt’. Technical debt happens when we choose a lower-quality solution in order to deliver sooner and get quicker feedback on whether something works. You could think of it as the equivalent of a business borrowing money to get its product to market sooner. Although taking on an amount of technical debt is a common practice in the technical world, we need to be sensible because it means we’re taking on more risk. Like any debt, technical debt needs to be incurred intentionally, managed carefully and, most importantly, paid off at some point.

Quite rightly, stakeholders want to know about the level of risk involved in a project but in most cases, they’re not digital experts. We believe that software standards can be used to provide a consistent view on the technical debt being carried by a service. By rating each standard for a given service we can provide a view of technical debt at a level that stakeholders can understand.

Rick Healy and I have been working on how we can represent this in a clear and simple way. Our next step is to try it out on some of our services and see what it tells us and if it’s helpful for those services’ stakeholders.

Screen Shot 2018-06-25 at 10.09.57 The Assessment Wheel

Engineers, we’d like your feedback

You can read our software development standards.

This is just the first version and we’ll be iterating them as our teams use them. We’re keen to hear feedback from internal and external digital teams and in particular engineers so let us know what you think below.

Andy Longshaw
Principal Software Engineer and Tech Lead on Co-op Guardian

Guardian update: rolling out, listening to feedback and fixing problems

We’re conscious that we haven’t blogged about Co-op Funeralcare for a while so this post aims to give an overview of what we’ve been doing and how it’s been going.

Co-op Digital worked with subject matter experts from Co-op Funeralcare to design and build a digital service which would give time back to our Funeralcare colleagues by taking away arduous admin and keeping customer data safe and secure. You can find previous posts about our progress on this blog.

The service is now called Co-op Guardian.

We’ve started to roll out the service

The last time we posted back in August, 29 branches and around 110 colleagues were using Guardian. Since then we’ve been gradually rolling out. Here are the latest figures:

  • 1,948 colleagues across 563 branches in England, Scotland and Wales are now using Guardian
  • 16,642 funerals have been arranged using the Guardian digital service so far
  • we’ve rolled out to 18 of our 36 regions
  • 12 regions are receiving training at the moment and we’re checking tablets are working and that wifi is in place

It wasn’t easy from the off

When we began the initial roll out there was a lot to contend with. Some of the problems we ran into were consequential and some were mistakes we needed to learn from.

We found we needed to:

1.Extend wifi coverage

A lot of our funeral homes were based in old buildings with thick walls and, consequently, the wifi was weak. We upgraded our coverage so it doesn’t just work in client-facing areas but also in places such as our mortuaries and garages.

2.Make initial training groups smaller

We learnt quickly that our approach to training colleagues up to use the service needed to change. We had too many people in a room at one time and too few people to support them. Now, there’s a maximum of 8 people per session so that each colleague gets the support they need and their confidence is much higher at the end of a session.

3.Give managers more support

We started out giving managers high level training and asking them to support their colleagues. But this put teams under too much pressure. Now, our Learning and Development team give managers much more comprehensive training so they feel more confident supporting everyone in the branches.

4.Improve communication and access to online help

To tell colleagues about updates and changes we had a ‘what’s new’ section within the digital service and we offered support through guides on the intranet. However, we knew colleagues weren’t using either of these things. So, we’ve created a ‘help’ section within Guardian which lets colleagues search and find the help they need and has a much more user friendly layout. It’s also easier for us to update.

This feature had more visits within the first 2 weeks than the intranet did in 7 months.  

Kind words: we’re making a difference

Introducing a digital service into this very traditional profession hasn’t been easy but we’re getting there. The feedback we’re listening hardest to comes from the people who use Guardian everyday: our colleagues.

We asked some of the first colleagues who received Guardian training what they’d say to colleagues who were about to start using the service.

“If you can buy something online, if you can book a holiday you can confidently use Guardian.”

“Having to learn something new in such a short space of time can be a bit daunting but once you go onto the system and see how easy it is to use, that anxiety goes straight away.”

Hayley is a Senior Care Logistics Manager who is based in Crewe care centre.

Exciting problems to solve

We’ve learnt a lot over the last 2 years and these last 6 months since we exited beta have been a really steep learning curve. Now, not only is Guardian getting better with every release, roll out is smoother and training is more colleague-focussed. All of this helps our colleagues trust the service, and we’re getting better data that helps us make improvements for Funeralcare colleagues and their customers.

In the next few months we hope to:

  • complete roll out
  • build data tools to help predict demand peaks
  • explore the option of giving customers access to Guardian
  • look at extending Guardian to also capture funeral wishes and pre-need funeral plans

The Guardian team

We’re looking for engineers to work on the Guardian team. Visit our jobs page for more details.

Lessons learnt: starting out as a product manager

I came to Co-op Digital as an agile business analyst and relatively speaking, I’m pretty new to product management.

I wanted to take on a product manager (PM) role after working with some inspiring people – Anna Goss, Lawrence Kitson and Charlotte King to name a few. I saw each of these people lead teams to meet user and business needs with design and technical solutions. And I wanted to do the same.

Since then, I’ve had to learn a lot of stuff. And quickly.

The other week at Product Camp Manchester, I gave a talk at on the advice I’d give my less experienced self. This post is about what I know now with the power of hindsight.

1.Context is everything

Yes, it’s the dream to get something in the hands of your users within a couple of months – weeks even – and that might be possible if you’re a product manager in a start-up.

But Co-op isn’t a start-up. It’s a huge, traditional organisation and for the vast majority of stakeholders, the pace digital teams move at can be scary. I understand that worry. Of course, it can take longer to get digital products and services out there when you’re working in an organisation going through digital transformation. And I’ve learnt that that’s ok: you need to take into account the time it takes to communicate what you’re doing clearly, and convincingly, to the right people. That way, you get the credibility to continue.

2.What you work on affects your learning

Many new PMs choose to work on ‘safe’ products or services. I didn’t. Instead, I prioritised working on the most interesting product. I pushed for my first product to be one of Co-op’s new ventures because I was really interested in lean product techniques and working on something new felt like a good way to test them out.

However, there have been times when having more experience would have been useful with a product like this. With experience comes confidence and with that comes the willingness to make decisions more quickly (granted, not always better ones). With the power of hindsight I’d be in a better position to be able to weigh up working on something that has more structure because it already exists and the challenge of shaping and influencing the direction of a product from inception.

Although I’m glad I stuck with the product, having the right people in place (an excellent community of practice and a supportive team) has been essential.

3.Influence team morale

Part of a PM’s role is to be in tune with the team’s morale, and sometimes to influence it. I’ve found that keeping these 3 things in mind is helpful.

‘Failing’ is just part of the process

Occasionally, things won’t go to plan. That’s unavoidable. We’ll make the wrong assumptions; we’ll test the wrong thing; a user will interact with a prototype in a completely different way to how we expected, and there’ll be times when we don’t do everything we set out to in a sprint.

As a PM you need to make sure the team knows that all of those things are ok and that making mistakes is fine as long as we’re learning. Letting them know gives each person autonomy, it shows you support them to get on with their job and that you trust their expertise.

The best bad decision is better than no decision

Sometimes, you won’t have enough information to make an informed decision. In those instances, accepting a sensible amount of risk, taking a punt and learning is more beneficial for the team because it keeps things moving. It’s always a good idea to explain a ‘best bad’ decision and the options to the team.

Hand-drawn doodle. A man standing in front of a sign post choosing to go in the direction of 'bad decision' rather than 'badder decision'

Any compromise warrants a thank you

You’re undoubtedly working with some very skilled and knowledgeable people and sometimes you’ll be in a position where you need them to compromise in the name of progress. Nobody likes compromise so if someone does it, showing your gratitude is essential.

4.Learn from doing, not just reading about doing

So much of the role is about how you interact with people, how cooperative they are and how much confidence they have in you – a lot of this can only be learnt through experience, through doing the job. You can read as many PM books as you like but the only way to learn properly is practically, by being on a team. Applying theory to deliver something valuable is the hard part.

5.Empower the team by being clear on your mission

Teams always say they want autonomy. But, if a team has complete autonomy but no mission they might end up building something super impressive and, unfortunately, completely useless to the problem they’re trying to solve.

They might end up building a rocket and not know why.

Hand-drawn doodle of 3 people looking at a very impressive rocket. One says: We built a rocket! Another says: Why?

Autonomy only works if the team is aligned. Creating a mission and communicating it to the whole team will give a clear purpose and empower each person to get on with delivery.

I’ve learnt a lot in a really short time. And as long as there are problems to solve, the learning won’t stop. We’ll be hiring product managers again very soon. Keep an eye on our jobs page and follow Co-op Digital on Twitter to stay in the loop.

Anthony Wilson
Product manager

Illustrations by Maisie Platts

 

 

Karen Lindop: our first ‘Federation presents’ event plus winning an award

(Transcript) Karen Lindop: Hello, and welcome to our update on what’s happening in the Digital team.

I’ll start with some brilliant news. On Tuesday our service team won the Special Innovations Award at the IT Service Management Foundation awards. A massive well done to Michaela and the entire team, past and present,including our partners BJSS.

At the Federation last week we hosted the first in the Federation Presents series. A massive well done to Emer and the Federation team, plus a thank you to Mary Mazzio. If you missed the event you can watch it again, we’ll add a link to the blog, plus you can always register for the next in the series which is next week on the 13th June. It’s on the very topical subject of responsibility with data.

We’re delighted that Aurelie Pols will join us to deliver the keynote, talking about how digitisation may be challenging our values as citizens and about our responsibility as data subjects, citizens and parents to assure technology works for the benefit of human beings. There are a few tickets left, so be quick and register. We also realise that not everyone can make evening events, which is why we’ll also be live streaming the event, and will make the recording available after as well.

Richard Sullivan and Cara Bermingham have been busy planning our next agile masterclass. It’s on 22nd June, and open to any of our colleagues across Co-op, so get in touch if you’d like to sign up.

Also this week, Katherine Vaughn and the user research team from Citizens Advice Bureau spent the day with our user research team sharing ways of working. It’s always so valuable to learn from others, so thank you to Katherine and the team for taking the time to come to see us.

Finally congratulations to Adam Warburton who completed his MBA this week – a fantastic achievement, well done Adam!

That’s it for this week. Don’t forget to subscribe for all our updates on our blog and follow us on Twitter. See you soon.

Karen Lindop
Head of Digital Operations