Applying Jobs-to-Be-Done to User Onboarding, with Ryan Singer!

I recently had the pleasure of sitting down with Ryan Singer of 37signals to discuss how the Jobs-to-Be-Done concept can help your customers and business succeed, especially during the user onboarding process.

It was one of my favorite conversations in quite a while, and fortunately he was gracious enough to let me share it with you here - enjoy!


If you like this, you will be WAY into the book I'm writing on User Onboarding.
Sign up here to stay in the know!


(Don't worry, clicking submit won't refresh the page)


Jobs-to-Be-Done 101

Samuel Hulick:

Do you want to briefly touch on Jobs-to-Be-Done? I don't know if you're sick of giving the "Jobs-to-Be-Done 101" but I think the descriptions that I've seen from you have always been the best.

Ryan Singer:

It's totally interesting. The best way that I understand it right now is that what somebody is trying to do is independent - it's different than the thing that they use to do that.

If somebody is hungry and they have a small amount of time and they are in public, there's a certain amount of things that are going to do the job: Snickers bar, an apple, a protein bar, whatever. If somebody is at home and they've had a really long day and they were planning to cook but it turns out that they had to stay at work longer than they thought and now it's getting late and they're hungry, and now they're not only needing food quickly, but they also feel bad from having a long day and they just want to feel - they want some comfort. That's going to constrain the possible things that do the job.

The basic insight is that people are in a situation, and it's not the person - ok, here's one other thing before I say that… you can be 30 years old - so you've probably heard of personas?

Samuel Hulick:

Yup.

Ryan Singer:

You could be 30 years old and male and on one Friday night, you order pizza and on other Friday night, you go to an expensive Italian restaurant. Your attributes do not explain why one Friday you bought the pizza and the other Friday you bought the expensive Italian dinner.

Samuel Hulick:

Correlation is not causation.

Ryan Singer:

Yeah, and attributes are not causation. That's the key thing: attributes do not cause you to do things. It's your situation that you're in that triggers your causality.

When it's Friday night and it's cold out and you had a long week, pizza sounds like a great idea, but when it's Friday night and you're going out on a third date, pizza is not as appealing! There are very different forces in play and there are different aspects of the situation that are defining value for you.

Then the question becomes, when somebody is in a certain situation, what are they really trying to do and how do they define value relative to what they're trying to do? Somebody might be buying an iPhone and you can talk to them about why did they buy that iPhone. If you ask them what's good about the iPhone, they'll tell you about product attributes, like "I bought the iPhone because it's reliable" or "it has a great screen" or whatever… "I like all the apps."

If you actually look into the situation that led them, causally - remember, causality unfolds forward through time, so if you look through what are the steps that happened through time that led them from some situation to another situation to another situation where they ended up exchanging money with an iPhone in their hand, very rarely do the product attributes have anything to do with it.


Tipping the Emotional Dominos

Samuel Hulick:

Can you back up? What do you mean specifically by "unfolding through time"? That it's a compound effect, or like a chain reaction or…?

Ryan Singer:

It's about "how did you end up here?" "What happened that you're buying?" and it's because one domino is falling after the other, from the first moment where they noticed something is wrong or could be better, to passively looking around, like - you know - your car starts to make a scary sound and you've taken it to the mechanic six times and you don't want to take it to the mechanic a seventh time, because you feel like you're just pouring money into this old car and it's too long.

It starts to make that sound again. You're not quite ready to buy, but as you drive around, you're noticing other cars. You're like, "Hmm, how's the new Camry look, maybe it's time to get something nicer - maybe I should look at the Acura or the Audi." You go from a phase of passive looking to - something else happens like the sound gets worse, or you see a sale, or your neighbor buys a new car - something else happens. Then you get a little more serious about it. You think "maybe I really should." Then you start looking at the car magazine, or you search online, or you'll read the consumer reports, or you go to a dealer or whatever.

Then it's one domino after the other are tipping until finally you've been pushed so far that you're ready to go. The basic overall idea is that somebody is trying to make progress, and in order to make progress, they have to overcome different kinds of hurdles. And you have to create push, create pull, or remove anxiety, or remove the allegiance to the past - or remove the habit. How you do those things is the question.

Samuel Hulick:

I think that that really is a very convenient segue to the topic of onboarding, in the sense that people don't simply buy things, they're switching from their current behavior to the behavior that you're trying to get them to partake in. So, there's also that friction of having to actually make that switch, and how you can remove that anxiety and doubt that's coming into play, as well.

Ryan Singer:

That's really interesting to look through a Jobs-to-Be-Done lens, because then the question becomes "what can we do to help this person decide that this is the right tool for them?" That's a very different task for the designer than "how can I thoroughly explain the mechanisms of my products?" Explaining the mechanism of the product and explaining why you should use the product for your problem are not the same thing at all. It's much easier to just explain your mechanisms, so that's why we all do it!


Better People, by Design

Samuel Hulick:

As far as that duality goes, between onboarding as "helping people be better at using your product" versus onboarding as "helping people be better at what your product lets people do" - is that something that you've paid a lot of attention to, or have some thinking around on how to actually approach that as a design problem?

Ryan Singer:

I thought about it a lot, but I don't have anything I'm proud of to show you as an example of doing it right. I think that sometimes it can be a little bit of both. I can only point to the examples we have, which I don't think are so great yet. In Basecamp, when you sign up, we show you a sample project and I think that the sample project, it does a barebones job. It manages to show you what's possible. Much better than an empty account does. Because you get to see what it looks like with data and you get to imagine… you get to play that as a model and be like, "Okay, if that's what this thing does, how can I use that?" "This is what a to-do list looks like, what would I put in a to-do list?" It at least gives you that ability to reason about that, so I think that is helping with the shopping mode of onboarding, or the deciding mode.

Then in terms of mechanism, I think that we really try to do that - I think that making your mechanism clear, ideally, that is part of every single day of your design and it's not your onboarding process. I think that the better the interface design is, the less work you need to do in the onboarding process to explain the mechanism, because the mechanism is more or less self-explanatory as you go. So that's the ideal that we're always aiming at.

Then there are these cases where you need to say on a blank slate or whatever, "Hey you landed here. Your first step is to create this or that or invite people or whatever." That's where you are explaining some mechanism that isn't totally obvious, because you have to spell it out to people. But in general, I think a lot of explanation about mechanism is a smell.

There's one exception to that that I've become aware of, but it doesn't seem to apply to the tools that we have made so far, which is if you are making a sophisticated instrument for people to do something really complex with. If you're making somethings that's like a violin for people, then it's totally acceptable that you need years of training to learn the mechanism. Because the result that you get is massive. You get massive expressive power out of that.

I use a text editor called Vim and it took me quite a lot of energy, maybe 15 years ago, to learn how to use it. Now, it's an instrument to me and I get a lot of leverage out of that. It was not an easy step-by-step learning process, but it was worth it because of the amount of daily leverage I get. So I think that that is kind of an exception to what I said about trying to make the mechanism constantly clear.

If you're making something that is a daily work tool and people are going to have so much - here's where Jobs-to-Be-Done is useful again - they have so much push, but they have so much pull that they're going to endure a really steep learning curve. You need a lot of gas if you're going to climb over that curve, and where does that gas come from? It's the push or pull in their demand.

If they've got enough gas, then you can give them more work, but then it should pay off in terms of more expressive power or ease of use or faster results or whatever. Those are some different dimensions and contrasts that you can play with when you're deciding what's right for you.

Samuel Hulick:

And there's kind of a helpful analogy that I picked up awhile ago which is "tricycles vs. training wheels" where if you're crippling your product to make it easy to use and understandable, then it's only going to be about as useful as riding around on a tricycle. Whereas you can provide that bridge to that - nobody is going to just pick up a bike and be able to bike right away, but it's obviously a lot more rewarding in the long run.

One thing we keep coming back to, to me, is looking at "how much progress has this person made as a person?" Not necessarily even within the product, or things along those lines. Maybe at the end of the day or at the end of the trial process, for example, you could say, "We calculated that you saved 24.5 hours building reports that you otherwise wouldn't have." That's something that that person can then take to their boss and say, "Look at how much more proficient I am." It's an actual real-world value that you're generating. Not just proficiency within the software.

Ryan Singer:

Proficiency with software is never the goal, anyway. It's always something else. It's always "I want more time" or "I want to feel less anxiety because I don't have things under control" or "I want somebody to stop bothering me so that they can see that I'm doing my work." It's always something external, anyway. That external thing that is kind of a main driver is - I'm getting a little speculative here, but I think that that is really the Job. So if the Job is to make the boss happy, then it's not that you start thinking about somebody else. That is the Job for the person who's using the software. So I think it's just about - for me, I'm always just trying to make it simple so I can understand it. It's like, "Where does it hit the fan for this person? What is it that they're really trying to improve, or what they really need?" I just try to understand what really matters.

At the end of the day, this is all sort of playful analytical and theoretical ways to try to talk about what is important and what matters to somebody. It can get complicated, but at the other side, it's just like… it's all about being able to identify what matters and giving ourselves some way to think about that and to talk about it. If we know it matters to somebody, then that's what we focus on.


Cutting Down to What's Relevant

Samuel Hulick:

I noticed that you're also a fan of something that I've recently come across, which is Scientific Advertising.

Ryan Singer:

A phase.

Samuel Hulick:

That was a phase of yours?

Ryan Singer:

Yeah.

Samuel Hulick:

Have you cooled on it? Is that what you're saying?

Ryan Singer:

I had a phase where I was really curious about all of these classics advertising guys. What was his name, Claude Hopkins?

Samuel Hulick:

I think Claude W. Hopkins, something like that. [ed. note: It's actually Claude C. Hopkins]

Ryan Singer:

And Ogilvy and some of these sales letter guys. This kind of direct response, slightly skeezy, but they're smart about certain pragmatic things. I just had a phase where I got interested in that, but it was kind of a phase because it didn't stay with me, and I don't do most of my work on the marketing side of things. It's not an area that I spend a lot of time or interest.

I kind of got psyched about it for a bit because I thought one thing that really I remember from Scientific Advertising that stuck with me was he said, "When you write a headline, your headline should be calling out to a crowd of people and pointing at one man. So it's says 'Hey you!'." And I thought that was great. That, to me, really makes sense with everything else that we've been talking about. That it's about understanding a situation that somebody is in and calling out that situation. "Hey do you have this problem?" And then somebody says, "Yes I have this problem." And you say, "Well, then here I have a solution for you." Instead of a lot of tricks and gimmicks and stuff like that. So I liked that. Otherwise uh… maybe I'm just not an ad man [laughs]. I think that's possible.

Samuel Hulick:

What really appealed to me - and I'm only about half way through it myself - was time and time again, he comes back to basically saying "Clever wording won't save you, novel images won't save you," that basically you really need to cut down to the relevant value that people are looking for, and then tell them with some credibility that you can offer it.

Ryan Singer:

Yup. Exactly.


Being Honest, Playing It Straight

Samuel Hulick:

I think that can play into product design as equally as marketing or advertising as well.

Ryan Singer:

It's just doing things that make sense. All these things are about the same common sense point that we miss all the time which is just to drop the gimmicks and to stop trying to put on faces and stuff like that and to just find a place where there's some pain, or find a place where there's an opportunity to create some excitement, and do it and just show it people and just be straight about it. "Hey do you have this problem?" If people really have a problem, then you don't have to dress it up. They're already itching to solve it.

And if there really is an exciting opportunity that you can do something great, then do it and show how great it is and if it's great it will spread. I feel like a lot of this marketing stuff is about how to trick people instead of how to understand the strong forces that are already at play in the situation they're in and then just tapping those.

Somebody who's really frustrated who's been losing clients because they're too disorganized and he was a looking for a solution - they really care. And they're going to read three pages of copy if they think it's going to explain it. Because you understand that they really care and that they have a real problem and they're trying to solve it. So I think this thing - it all goes back to identifying with the forces that are present in real-life situations. Then the rest of the stuff all kind of falls out as a natural consequence of that.

When we really focus on real living, breathing situations, with anxiety and desire and fear and all that stuff. The situations we're in when we make decisions. The things that make our lives tick. It's not about personas and tricks and stuff like that, or design, styles or whatever. It's all about real situations and just things that people need. Especially when it comes to business tools.

Maybe selling entertainment or selling fashion is a whole different bag, but at least the experience I speak from is from making practical things for people who have problems that they're really motivated to solve. So it's a really fun world for me to be in, as somebody who just wants to be able to be honest and play it straight.


Making Them Awesome

Samuel Hulick:

Absolutely. There is a lot to be said about identifying - what is that burning need that someone has and then addressing it. I think it's also pretty fulfilling to say, "We have made this many more people this much better at what they wanted to be better it." Say you had a product offering that somebody says, "I'm losing clients because I'm too disorganized. I need to be better at organization." They find some software that "Hey! At the end of my trial period - or after using it for so long, I've evaluated it. Not only do I trust that this is going to tell me be more organized, but I already am more organized, based off of having used it. I can see the improvement in myself." And how much easier it is to sell to someone after they've gone through that transformation, as opposed to trying to sell someone based off of promises.

Ryan Singer:

Yeah that goes back to the Kathy Sierra thing. Do you know about Kathy Sierra?

Samuel Hulick:

Yeah, big time.

Ryan Singer:

She's fantastic. Her blog post had huge influence in us in 2002, 2003 I think. The heyday of that blog around then. That stuff was amazing. Her whole thing is that you want to make the user awesome, right? Make them awesome.

There's a situation where they feel like they suck or they feel like things could be better and we're just trying to get them there. I love that perspective. "Hey when you have this thing, you are going to feel like a superhero." Because you can do things that you couldn't do before, that other people can't do, that make things better. That's just awesome.

Samuel Hulick:

Yeah, and the sales just naturally following as a consequence of that.

Ryan Singer:

Totally.


What "Good" Looks Like

Samuel Hulick:

Going back. One of the very first things that we were talking about as far as the onboarding process as getting you "better at using the application" versus "better what the application lets you do" and you said that it is something that you thought a lot about. Were that to be a design problem that you were to take on right now, would you have a fresh perspective on that since the last time?

Ryan Singer:

I think a lot of people use a tool like Basecamp and they don't know what "good" looks like. They don't know what a well-running project looks like. And they don't know what a poorly-running project looks like. So they don't have a measuring stick that gives them contrast to figure out where they are.

If you don't know where you are, then you can't apply methods to get you somewhere else. So one thing I've been thinking about is, could we provide a way to say, "Here are good practices and here are bad practices. And this is what they look like so you can identify them." I think that's generally the idea of what I would really like to do or see is, how can we create contrast for people so they can develop a notion of better and worse and hot and cold in a few different dimensions that matter for their progress?

They're trying to get somewhere, and that place that they're trying to get, you could model that as being in some sort of an N-dimensional space. For each of those dimensions, how do you give them hotter and colder. I feel like that would be really meaningful to pursue that.

Samuel Hulick:

Well, I can't think of a better note to end on! Do you have anything that want to clarify or any questions for me or anything along those lines?

Ryan Singer:

That will do it! Thanks for setting this up. It was fun to chat.

Samuel Hulick:

It was phenomenal to get the opportunity to talk with you, and thank you for making so much time to do so.

Ryan Singer:

Yeah, my pleasure.


Thanks for making it all the way to the bottom of the page! Want to check out some first-run experience teardowns?