Author: David

As I’ve mentioned in my previous post on a DIY JTBD Workshop, there are a lot of great resources freely available on the web about Jobs-to-be-Done interviews. However, I’ve found a surprising lack of material on the analysis steps that ensue after that round of interviews. The Disruptive Voice podcast has an episode in which the debrief is explained roughly, but that’s as much as I could find until recently. That’s why I am going to share the steps we went through at store2be when doing a JTBD analysis project on “Why do brands hire Live Marketing?” from March to June 2020.

Interview Debrief

Over the course of around six weeks, we interviewed eight customers to figure out what caused them to reach for a live marketing campaign. During each interview, my research partner and I would both fill out a Forces of Progress diagram. In the debrief, we’d then compare notes and argue about our individual understanding of the forces we had noticed, and why we’d put them where we did. Quite often, I would hear something as a push, for example, and she’d hear it as a pull (or the other way around). It was in these discussions that I truly came to cherish doing this research as a team of two. Language is tricky, and having someone to go back and forth with on how something should be understood was invaluable.

Ultimately, the outcome of this step were eight Forces of Progress profiles – one for each interview. The forces were idiosyncratic, i.e. they were using language from the respective interview, for example. We purposefully did not try to abstract from what was actually said at this stage.

Affinitizing (and Coding) the Forces

Next, our goal was to compare and contrast stories – and the forces therein – with each other. I’ve heard Ryan Singer refer to this step as Affinitization or Forming Affinity Groups. After hearing Ryan talk through this process in a recent episode of his podcast Synthetic A Priori, I realize that our approach wasn’t “by the book”. However, we ended up pleased with the results, so I’ll still share what we did.

We were working off of a screenshot that Ryan shared a while back, which showed a spreadsheet containing different stories as rows and pushes and pulls as the columns. Any given cell in the spreadsheet would either be coded as 1 or 0, depending on whether a given push/pull was causal in that story or not.

Seeing this as our ultimate goal, we set up a new spreadsheet and started “importing” the stories one by one. The way we handled the Affinitization was iterative:

• We started by pasting the first story into the spreadsheet as-is, meaning that we did not abstract anything from the original phrasing of the forces. At the same time, we coded each cell as 1 for that particular story.
• Then, we copied over the second story and all of its pushes and pulls, while immediately starting to look for similarities between the new and old forces. Whenever two forces felt like they were describing the same thing, we’d not add a new column, but code the latest story with a 1 for that force and try to find a more abstract description for it.
• If a new story did introduce an entirely new force (=column), we’d go back and code all the stories already in the spreadsheet as 0.

I realize that this approach only ended up working because we had a manageable number of stories and forces – usually no more than three for any of the four forces per story, and mostly just one or two. The proper way – which Ryan describes here (jump to 12:35 on the recording) – would be to first get all of the forces across all of the stories out in the open (he actually suggests printing them on tiny strips of paper to be laid out on a tabletop), then look for similarities and finally find suitable titles once you’re satisfied with the groupings.

Cluster Analysis

After having coded all of the stories into a spreadsheet like the one shown above, the penultimate step in a Jobs-to-be-Done project is to identify which stories are closer together overall, and which are further apart. The goal here is to find clusters of similar stories. These clusters will be your Jobs.

With Ryan’s guidance (thank you!), we were able to run a cluster analysis using a hierarchical clustering approach and Ward’s method to measure cluster (dis)similarity.

I’ve put together an extremely basic web app using Shiny and R here, where you’ll be able to upload your spreadsheet (as a .csv file) and produce a dendrogram that shows how the stories are combined into fewer and fewer clusters.

You can use the following demo file to try for yourself:

The app should produce the following dendrogram:

(Don’t forget to select the right separator and quote symbols for your file – “Comma” and “None” in the case of the demo file)

If you’re not yet familiar with how to read a dendrogram, it basically shows you how each of the stories were grouped together for each iteration of the clustering algorithm (read the image bottom-up). In the case of the demo file, you’ll see that stories 5 & 7 were combined first, then 6 & 8 and then 1 & 2. After that, story 4 was grouped in with 6 & 8 and that group is then combined with stories 5 & 7. In the second last step, story 3 is grouped with 1 & 2 before, theoretically, all stories are grouped into one big cluster in the very last step. The thing I like about this representation of the clustering process is the fact that it let’s you try to interpret different solutions and check how they feel in reality. This demo file is actually a redacted version of our original research and in our case, we ended up going with a three-cluster solution in the end, as it felt like it captured the essence of the stories best:

1. Stories 5, 7, 4, 6 and 8 as a first cluster.
2. Story 3 as a second cluster.
3. Stories 1 and 2 as a third cluster.

Detailing the Jobs

The last step is that of detailing the Jobs. It includes defining the Job Statements that you see in the screenshot of Ryan’s analysis above. We, again, formed these together between my research partner and I, by discussing how the clusters share a distinct essence within them.

“When X, do Y so Z happens.”

Example format of a Job Statement.

The Job Statement usually consists of a context, solution and outcome, and we worked off of the following recording of a JTBD workshop by Bob Moesta (the video should start at 1:01:30):

In the end, we created a kind of canvas for each Job based on this slide that Bob briefly shows in the above workshop:

As we didn’t have much else to go on, we went a bit freestyle in the end and also included some notable quotes that we felt described each Job well. For future projects, I’m looking to be more rigorous in this area, and appreciate any resources that you can share with me!

I’m curious to hear if anyone else has gone through this full process and how you’ve distilled raw interview data into a detailed understanding of your customers’ Jobs-to-be-Done. For now, this post purposefully is a rough draft, so let me know which areas trigger questions or require more detail.

If there’s one thing that’s stuck with me from attending a JTBD interview workshop with Bob Moesta and Greg Engle, it’s this mindset of how to approach customer interviews: You’re trying to uncover patterns across different stories – and not to find the needle in a haystack!

Two weeks ago I participated in a digital JTBD workshop with Bob Moesta and Greg Engle. The workshop was designed for JTBD practitioners who’d had some experience doing this kind of research and wanted to up their interviewing skills. After discovering Bob’s flavour of Jobs-to-be-Done during my parental leave in 2018, I had become enthusiastic for this way of doing product research. But so far, I had been entirely self-taught – based on freely available resources like conference talk recordings, podcasts, blog articles and so on. Since I’d had so much free time during my parental leave, I had enjoyed sifting through a huge mountain of podcast episodes and conference talks. But I know that there are also people who would like to learn about Jobs-to-be-Done, and do so in a more structured way while still leveraging resources that are freely available on the web.

On the face of it, Shape Up is a framework for IT project management. It talks about backlogs, how developers and designers should slice projects and about stubbing an interface to figure out affordances before a complete visual design. Beneath that surface, though, lie basic truths about work and project management that I believe could have tremendous effects on the work in other business functions and teams.

For example, take the notion of No Backlogs. For my work as a product manager, it’s had a couple of consequences. We take on development projects that have a clear end in sight and with a mindset that it’s OK if we only work on this problem for one cycle (= 6 weeks) and are then free move on to something completely else. Or consider the consequences of submitting Pitches to the Betting Table, where a collection of projects for an upcoming cycle of work is bet on. To everyone involved, it is unquestionably clear that there’s only so much we can do in 6 weeks, given the people that we have. There’s things that we believe are worth more resources or less resources. So we specify an “Appetite” for a given project, which is to say: “How many people should work on this for how long, and not longer?”

If we want to do one thing, it’s always clear that this means we will not be doing something else.

In our work as a product and engineering team, these concepts have provided us with such focus and intentionality about what we do and do not work on at any given point in time, that it’s become a basic expectation for me to be working this way.

But a recent interaction at work reminded me that this is not at all the reality for other teams. Even though they don’t call it that, those teams (from functions like marketing, operations or business development) usually operate as if they had a public backlog and are in a constant sprint. Any request that comes in is just added to the list, and when it comes up, is executed. “Yes!” is the default answer to any task.

For their sake, I wish they too would see their time as finite, would see trade-offs in what they work on. This is the power of committing to any time box that constrains you. Without those clearly visible constraints, like a 6-week-cycle, you just say yes and step on the hamster wheel of meaningless, unintentional work. This is also the power of committing to a healthy 40-hour-week. If something comes up that you want to say “Yes!” to, then this means you’ll have to say “No!” to something else you had previously planned.

My time is finite, and knowing it makes my work so much more intentional.

I’ve recently asked several internal stakeholders for feedback on a new product idea pitch, to build a first version of something that potentially has a high return, but also contains a lot of unknowns for us (in terms of business value). A classic bet.

As our team is using Shape Up to build products, the pitch mentioned a very specific appetite of 3 weeks, 2 developers and 1 UX designer.

Can you guess what happened?

Exactly.

And it reminded me just how much I love trade-offs. This will be fun!

Side note: I mean this with absolutely zero sarcasm. Problem-solving within constraints, making hard and deliberate decisions about what to do and what not to do, steering discussions and lobbying for understanding – I cannot image a more fulfilling role.

There was a time in late 2018 where we were having real trouble shipping the things we had planned to ship within the timeframe we’d estimated. I remember a particularly gnarly project where we wanted to enable our users to book multiple spaces within a given location – instead of being able to book just one space per location at a time. What we’d originally estimated to take roughly 3 sprints ended up taking around 5. Some people on the team will still shudder if you mention “multi-space bookings”.

For context: At store2be, we’re building a platform where brands and live marketing agencies can book promotion spaces in physical locations such as shopping malls, train stations, universities, airports, public spaces and more.

Since then, we’ve started to implement Shape Up – a product development framework developed at Basecamp and put into writing by Ryan Singer a few months ago. For the purpose of this post, I’ll assume familiarity with the framework. If this is your first time hearing of Shape up, you best get started by reading the book (online or PDF) or by listening to some of the podcasts linked here.

If you don’t know something today, you google it. That’s great for a lot of things, for example if one of your biggest concerns is settling dinner-table arguments around “Who played X in the movie Y again?” or “When exactly did Z happen?”. Googling has become such a knee-jerk reaction to any question for my generation (90s) and the ones after us – but it’s not always helpful.

When I entered the workforce at age 26, I joined a new company as one of their first full-time hires. It was four co-founders, me, a programmer and a few interns. None of us had any real work experience. So when you’re dealing with nuanced topics like Product Management, Strategy or Marketing, let me show you what a 26-year-old who’s just getting started in any of these roles, on a team with no experience to guide him, would learn by googling.

While working on an internal document on the progress that we’ve been making in moving towards continuous product discovery, I came across The Place of UX by Ryan Singer of Basecamp. A thing he wrote in the comments stood out to me in particular:

[W]hen we work on entirely new products … [it’s better to have] a small intensely collaborative pool who figures everything out together.

As I am currently working on a product that is more or less entirely new, this comment was immediately relevant to me. But initially, I took this comment as an advocacy for letting everybody on a small team working on a new product figure everything out. With the dual tracks of product discovery and product delivery on a product team now accepted knowledge, at least to my understanding, this sounded a lot like running a single-track team. But let’s back it up a bit.