How do we know a solution satisfies a Job to be Done? “Transport me and my belongings via the ground”. That said, we believe it may work better if you were to use job statements which are considerably less wordy e.g. Prioritisation exercises aren’t quickĪcademically it sounded like a great idea but in reality we found them to be long, cumbersome and people found it hard to understand what we were asking. This basically meant we ended up applying the JTBD theory in our own way (also known as “Winging it”). The information that is available is often conflicting, with the likes of Tony Ulwick and Alan Klement having a public and long running argument over who really understands JTBD. Conflicting approaches from ‘the experts’ We found various medium articles, blog posts about why and when to use JTBD but felt there was a lack of information on its practical application and any real case studies (one of the reasons I felt we should share our experience). What didn’t work well Limited resources on practically applying JTBD Although the two users in this example want to get their details on the electoral register, you may have to design different solutions to meet their needs. In the example user story there is no context of time or confidence, so this can’t be fed into the design process (unless you start adding lengthy acceptance criteria). This shift in ‘job fidelity’ meant the job stories were more flexible and could evolve as we moved from uncertainty to a greater level of confidence. It also ensured we didn’t get swamped by an unmanageable number of ‘similar’ job stories and we felt it would help us to design better solutions.Īfter multiple rounds of testing we made the job stories much more granular to improve clarity for our delivery partners.

Though this was not mentioned in any literature we found, we decided to make the job stories high level to begin with as this enabled us to maximise our freedom within the design process. After every round of testing we made sure that any new features were linked to one of our uncovered jobs to be done. We took their ideas and created an initial prototype. It turned out they had no problems understanding the jobs we’d written and every idea they proposed was clearly linked to a job to be done. We included subject matter experts that had no prior knowledge of jobs to be done and indeed had little experience of any design process. We kicked off the design process with an ideation workshop that used our job stories as the focal point. You send this survey out to a large number of users to try and get a quantitative angle on the problem. For every job story or job statement, you ask users how important that job is and how satisfied they are by current solutions, using a 10 point Likert scale. One of the recommended approaches for JTBD is to use a prioritisation survey to uncover the under served and over served jobs in the market so you can focus on developing solutions that are going to make a difference to users (suggested by Tony Ulwick in his ODI method). We had to really ask ourselves why the users wanted to do something. We found it difficult at first to capture the real outcome of the job.We weren’t necessarily solutionising, but we were reducing the freedom we wanted in the design process - one of the benefits of the JTBD approach

A lot of the initial job stories we wrote had specific motivations.We weren’t sure whether we should write out a different job story for every potential situation when the motivation and outcome were the same.

Get it done case study