I have just finished reading Competing Against Luck, a book that outlines the latest thinking in Jobs Theory. That theory is built on a simple premise which, according to Clay Christensen, is:

“When we buy a product, we essentially ‘hire’ something to get a job done. If it does the job well, when we are confronted with the same job, we hire that same product again. And if the product does a crummy job, we ‘fire’ it and look around for something else we might hire to solve the problem.”

The theory turns the traditional approach to product development inside out. Instead of a market being defined around a product or technology, it is defined as a job executor and the job that executor is trying to get done.

Theodore Levitt famously once said, “people do not want a quarter-inch drill, they want a quarter inch hole.” The quarter inch hole is the job to be done. It is no longer enough to build a better drill.

My Story

In 2005 I conceived, built, managed, and then developed the product that is www.radionz.co.nz today.  In that time I spent many hours talking to customers of the product about their needs and what jobs they were trying to do.

These discussions helped me form a view of the work to be done on the product side, and from there it was easier to define and build the processes and technology needed to efficiently do those jobs.

In many regards the book was a revelation, in others, it reinforced the practice I’ve followed over the last 11 years. The book has enabled me to wrap some good theory around what I’d been doing, and understand why components of the work were successful and others were not.

There are broadly three customers of the digital product I had to deal with – consumers, producers (of the content), and management. At the centre of this was my team (and some contractors) – the designers, coders, IA and UX specialists, analysts, and content wranglers.

Consumers

The consumer is the most obvious customer, and the one most businesses spend time trying to understand. While demographics, market segmentation, and regional breakdowns are useful, they do not tell us anything about the job that the customer is trying to do. Why are they visiting the site?

The decision to visit frequently has nothing to do with the consumer’s location, or technology, gender or race, so how can we find out the information we need?

From the start, the team and I took phone calls from the public who had questions or problems with the site. The first question we often asked was “what are you trying to do” to get a high level description of the job.

Examples of responses were:

• I want to listen to an interview on my MP3 player
• I want to find out what is on the radio tomorrow
• I want to subscribe to a newsletter
• I want to listen to the interview that was just on
• I want to see the pictures/find the link that was mentioned on-air

It is fair to say that I never got calls from people who could not find news stories. That group of people was obviously well catered for, although I am sure there are other services that we could have offered for jobs around news content, like alerts based on keywords for example.

In almost every case the caller described an outcome – how they wanted to get ahead in their life. Sometimes people were able to get their job done, but found it inefficient (too many steps), and wanted to know if there was a better way. Other times, we’d made changes to the site, and their old method did not work anymore.

One realisation was that some people work out their own way to a get a job done, even if this includes (sometimes elaborate) work-arounds, and will become very efficient (through practice) at executing this. Because their method is so complex, any changes to that flow are far more disruptive than shorter, more efficient, ways of doing the same thing.

What was collected through this on-going process (and my whole team would take these calls) was a deep understanding of the jobs our visitors needed to do, and the roadblocks they faced. We also collected descriptions of the (sometimes convoluted) pathways and processes used.

This information was all gold in terms of designing user experience, information architecture, labelling, and much more.

In some cases we found a label helped people find a more efficient way to get their job done. In others, the way content was displayed and prioritised on the page was changed to make it easier to get the job done.

Occasionally I would call someone back to get them to try a solution we’d come up with.

I’ll give one example of what can happen when you don’t focus on the job to be done.

In the 2013 redesign of the site, the designer made the decision to put the two download formats behind a single link, and make visitors pick the format for future downloads. In practice this was a disaster because (as it turned out) many of the site’s visitors were playing the OGG version of the file directly in the browser, while also sending the MP3 link to their friends. The two different links were enabling two jobs to be done, and removing the immediate choice was making it impossible to do one of them. Due to the high number of complaints in the first few hours of launch this feature was removed, and both links were restored.

A similar problem occurred with the 2016 redesign, with the word ‘download’ not working for such links (they play, rather than download). This was fixed by user clear labelling focused on the job – ‘download’ or ‘play in browser’.

Both are good examples of what can happen when the job to done is not clearly understood, or assumptions are made about the job (e.g. everyone downloads, when in fact they don’t).

Producers

Within RNZ there were several dozen editors of content using the bespoke CMS and internal IT systems to publish content.

There are internal jobs that need to be done to produce content that allow consumers to get their jobs done. To get a sense of those jobs I would frequently ask for descriptions of the end result, and find out more about the process being used to get there. There would be many conversations around this, and how those jobs might overlap with the existing radio production jobs. The aim always was to have a single process that supported multiple outputs.

Also, during training, observations were made around how each person interacted with the CMS. Did  the process make sense? Did they get stuck at certain points? Were fields in a logical order? Was there anything that could be removed? Training isn’t just showing people how to do a task, it is an opportunity to learn directly from the users of the system.

I want to make a specific comment on feature requests. Many, many, projects are solely driven by feature requests from users, but with little or no oversight into the processes that those features are supposed to support, their usefulness to others, or the value they will add.

Can you call to mind a feature that your team has delivered that was not used at all, or perhaps cost a lot to build and was used infrequently used? Why was it built?

It is the role of the product owner (or BAs) to work with users of a system to first determine the best process to get the job done and only then work out the features or tools required to support that process. It is also important to look at groups of users, and all users of the system to see if that process can be generalised.

When process design is first, it is very clear what existing features can be used, and what new features are needed. It is also possible to do a proper cost/benefit analysis, and look at the total cost of implementing that process and any associated features.

Features support processes, which support work, which in turn should be allow a job to be done, this work in turn allowing a consumer to get their job done.

Management

The management and board are stakeholders in the product. Hopefully, the board has only strategic input, but frequently there are jobs to be done for management.

One example of this is branding. The site probably has to be branded, and the user experience has to reflect broader brand-values. But beware. Care is needed to ensure though that these do not make it harder for the consumers to get their jobs done.

A good example is splash screens. Remember those?  “We have to make sure that our brand is front-and-centre when people first get to the site.” These days, sites that have a splash screen prior to entry are seen as a bit of a joke, because they make for a poor user experience. “What were they thinking” when that was approved.

Another example is corporate information. This does intersect with actual visitor jobs – people might want to find your phone number or office address – but it should not be at the expense of other more important jobs.

One risk with management jobs is that they can be prioritised to highly compared with other jobs, and the thinking can start to become insular, feeding on itself. Ask yourself, are we building a ‘splash screen’ here?

Summary

The value in Jobs Theory is that it is economically efficient. Not much time is spent building things don’t contribute to supporting the doing of jobs.

One other thing is that by applying a multi-stakeholder approach to identifying jobs you can document a lattice of interlocking and overlapping jobs. This helps form a view of the jobs ecosystem around a product and can contribute to better systemic thinking, identification of critical seams, and provide more chances to improve the system.

I am glad I came to this realisation earlier in my career, and I hope this post has helped you see the value of the Theory and provide an incentive to find out more.

To close, here is Clay Christensen telling the (now classic) milkshake story that is often used as entry into the field.