In this episode of Jobs-to-be-Done Radio, Ryan Singer of 37signals (the company behind Basecamp) joins Bob Moesta and Chris Spiek to talk about how he discovered Jobs-to-be-Done and how he uses it to design better software. Ryan shares the story of finding JTBD through Clayton Christensen and Horace Dediu’s Critical Path podcast, then introduces his “domino” metaphor for explaining the customer timeline to people new to the framework.
Use the player above, then read on for the key takeaways and the complete transcript, organized by topic with short explainers of the core concepts. You will learn why situations (not attributes) cause purchases, how the timeline of a decision actually unfolds, why asking customers what they want produces endless feature lists, and how products like Basecamp and Campfire compete in a job category rather than a product category.
Key takeaways
- Situations cause purchases, not attributes. The same person wants pizza one night and a fancy Italian dinner another. What changes is the situation and the progress they are trying to make, not who they are.
- The domino metaphor makes the timeline come alive. Ryan reframes the JTBD timeline as a row of falling dominoes: the last one only falls because the ones in front of it fell first. Each step needs energy and pressure from the situation to tip into the next.
- Asking what customers want produces endless feature lists. Desire is bottomless, so customers say yes to every feature. Asking instead about past situations where they struggled reveals where they actually put their energy.
- Dimensionalizing turns vague answers into design decisions. “Easy to use” never tells you what to build. Trade-offs like private versus public communication, or speed versus formality, are dimensions where customers reveal real values through their choices.
- Software competes in a job category, not a product category. Basecamp’s communication job is also done by a meeting, a status phone call, a WebEx, an IM, or Campfire chat. Knowing the job keeps the product focused.
- Bad prototypes are a useful mirror. Customers struggle to say what they want, but they can tell you what they would not pick. The contrast reveals what to build.
How Ryan Singer discovered Jobs-to-be-Done
Announcer: Welcome to the latest edition of Jobs to Be Done Radio, where we discuss how to apply the Jobs to Be Done framework to understand why consumers switch from one product to another and ultimately how to get more customers to switch to your product. And here are your hosts.
Chris: Welcome back. So I’m Chris Spiek. I’m here as always with my partner Bob Moesta.
Bob: Hey, Chris.
Chris: And today we’re also joined by a very special guest, Ryan Singer from 37signals. How you doing, Ryan?
Ryan: Hey, guys.
Chris: So, I want to go through a few quick things we just announced the next Switch Workshop will be coming up in New York City in midtown Manhattan on Friday, May 17th. So if you’re interested in attending and seeing a full day of live Jobs to be Done interviews and really getting into how you apply what you hear on the radio show, it’s a great thing to attend. Tickets usually go pretty quickly, usually within a couple of days, so if you’re thinking about attending hop onto JobstobeDone.org and you can see the link there to go buy tickets.
I’m excited to be in New York; we’re going to be at DG in Midtown, which is a great venue.
Bob: We get to see Ruffi; Matt Ruffi’s awesome.
Chris: One of our friends running the show over there, so that’ll be good. The other thing I wanted to mention is we still have the wine project going, so if you haven’t taken the survey around the jobs that wine is hired to do hop onto JobstobeDone.org and do that.
Also, if you are a practitioner of Jobs to be Done and you want to practice some interviews in the wine space we’ll set you up with consumers that you can talk to about the stories of shopping and buying.
So, rumor has it Ryan you might be joining us in New York; no guarantees yet.
Ryan: I like how you’re putting a little extra pressure on me, there.
Chris: It’s out in the open now, Ryan.
Bob: If you can’t make it you can’t make it, I know. But I know you were trying, at least that’s what I heard.
Ryan: It would be nice.
Bob: Okay.
Chris: Very cool. So we’ve got a lot we want to cover here today with you. So, Ryan, I think where we’ll start is talk to us a little bit about how you discovered Jobs to be Done and this whole switching behavior thing.
Ryan: Well, I’ve been a fan of Clayton Christensen’s work for a long time. And there’s this section, there’s a little bit of Jobs to be Done in innovator solution.
Chris: Yeah.
Ryan: And eventually, oh, that’s what it was; it was Horace Dediu’s Critical Path podcast. He had an interview with Bob on there, and Bob gave all this detail behind the stories that Clay just mentions briefly, and it was like opening the door into the treasury, where there was like all these jewels where before there was just something promising, like an interesting idea, and then all of a sudden Bob was telling all these stories and really digging into detail. And I was really fascinated by it.
When I was doing a lot of web design and starting to make software it was around early 2000, and the term usability was becoming a big trend at that time. It was like everything was about usability. And I was 100% into that, but I always felt frustrated because it’s like what does it mean. On the one hand it had something to do with actually paying attention to the human side of things, and at the same time it was just like, well, if your product was good it was usable, and if it wasn’t good it wasn’t usable, and it kind of wasn’t really differentiated from other dimensions of performance.
And one of the things that I started to really hear in the stuff about Jobs to be Done is that it’s possible to have a more precise understanding of what a person is trying to do, and if you look at things in terms of what people are trying to do, then finally I felt like, I always knew that personas were BS, but I never had a good way to argue them down. And I don’t remember if it was in that podcast or later that Bob told the example of what’s the persona that wants the pizza versus what’s the persona that wants the expensive Italian restaurant. They’re the same person on different nights. And then, how do they choose; it’s not because of who they are, it’s because of what they’re trying to accomplish. It’s because of the situation they are in. It just started to open my mind.
And so, I’ve been really excited to work with you guys because it’s like every time I feel lucky that we have the occasional dinner and time with the drink together we get to dig into all this stuff. And every time we talk I just have this feeling like there’s so much stuff that you guys have thought through and it’s really unique. And what I’ve been trying to do is digest it and unpack it and figure out how to apply it as a set of really clearly defined techniques.
Concept · The basics
Situations, not attributes, cause the choice
Ryan’s pizza-versus-Italian-restaurant example is the heart of Jobs-to-be-Done. The same person makes opposite choices on different nights, so the cause cannot be who they are. It is the situation they are in and the progress they are trying to make. That is why personas built on attributes fall apart, and why a job is the unit of analysis.
Bob: Well I have to say I appreciate so much you taking the time when we worked together to just slow us down. To be honest with you very few people force us to slow down with, what do you mean by that, and to be honest, I remember one time we were interviewing people and you literally just like in a matter of a minute I did like three different things, and you, what did you just do? I’m like, I have no idea. And then slowing it down you actually uncovered these little kind of interview techniques that I just actually never even thought of before–that were techniques. So it’s very cool, and we appreciate that. The relationship’s awesome to be honest.
Ryan: It’s been really interesting because you guys have been doing these Switch Workshops, and we’ve been helping to make it happen by doing it in the space here at 37.
Bob: Yep.
Ryan: It’s just so fascinating, because I’m seeing how the two of you get up in front of the group and you kind of blow everybody’s mind open. Because everybody’s so used to talking about the product, what are the features of the product, what are the benefits of the product, why is the product great? And you do this kind of 180 degree thing where it’s like, what does the world look like through the eyes of the buyer, and that’s a huge mental shift.
The other thing that’s a big 180 is everybody is used to thinking in terms of . . . how do you say it? Like, what does somebody want. And when somebody says, what do you want, they ask it as if what you want is timeless and forever.
Bob: Yeah.
Ryan: Like I was born with 20 wants and I just, this is what I want for my life, right.
Bob: Right.
Ryan: And I always think about it from when Bob and me first met and you told me that you have a background in electrical engineering, so that you’re instinct is always to think in terms of like current flowing–that it’s always flowing from point A to point B. And this is the other big 180; people don’t just have a constant desire, or attributes, but they actually are constantly changing situations, and the changing situations that they are in gives them different kinds of progress that they want to make.
So it’s like, I want the pizza because I had a hard day, and I want to relax and kind of reward myself instead of cooking dinner. Or, I want the fancy Italian dinner because I want to express my gratitude or my love, or I want to impress, or whatever it might be, that there’s always a process that’s going through time from point A to point B where you’re based in a specific situation, and you’re trying to get somewhere else.
“people don’t just have a constant desire, or attributes, but they actually are constantly changing situations, and the changing situations that they are in gives them different kinds of progress that they want to make.”Ryan Singer
Ryan: So what I’m seeing is that you guys are blowing open everybody’s mind with this kind of big reversal, and then getting into the interview techniques. And then what I’m seeing is that you guys are so much experience with doing the interviews, and this is what Bob mentioned, that I’m trying to slow you down and say, wait a minute. How did you get to that? How did you get that answer out of there? How did you know what to ask? How did you know that there was something missing in this story? And this has been really interesting in these workshops lately to start to get better at finding these things, and learning how to teach those things.
The domino metaphor: making the JTBD timeline come alive
Bob: Yeah. Well, you have a really good analogy. I think you and Chris talked about it earlier today, was the domino factor, right. Could you tell a little bit about what that is?
Ryan: Yeah, I mean, you guys have this, you talk about the timeline.
Bob: Yeah.
Ryan: And the timeline, a quick summary of the timeline is that people don’t just wake up one morning and go the store because they had a dream or something; or you don’t wake up with an empty whiskey bottle in your hand at the front door, or something like that. Maybe some people do.
Bob: I’ve got to say, sometimes we do.
Ryan: But this is not an explanation for how people end up buying things. They go through some kind of process that unfolds through time, and you guys have this timeline with a few kind of key events that if somebody doesn’t have the first thought, if there’s not some moment where somebody first gets the idea, the process never kicks off. They might have the first thoughts, so let’s say a friend gets a new car, and they think, oh, maybe I want a new car.
Bob: Right.
Ryan: But then they forget about it again. But something happened that kicked the whole thing off, and then now they have the idea so whenever they’re on the road and they see a cool car they kind of like, oh, maybe that. I like that. Oh, I wouldn’t have that. But they’re not actually shopping; it’s just kind of floating around in their mind a bit. And this could go on for a really long time, and they might never make a purchase or do anything. But something happens that kicks it into higher gear where let’s say the car that was always just working fine, all of a sudden they have to replace the transmission.
Bob: Yep.
Ryan: And then it’s like, oh, maybe I really do want to get a new car. And then they actually go to some dealerships, or they start getting the consumer reports, or whatever; they start really actively looking, turning it into a shopping project instead of just an idle concern.
And then there comes a point where it’s time to decide, right, and it’s possible you could get all the car books and go to the dealers and still not do anything. There’s got to be something happening, so maybe it’s your friends from out of town are going to be visiting, and you would love to actually impress them with a new car in your driveway. Wouldn’t that be nice? Right?
Bob: Yeah.
Ryan: And now you have time pressure, and then, ah, wouldn’t I love to have that car before, what is it, May 15th or whatever. Right? And then you make the decision, you buy the car, and what we get into is how can we understand what actually drove the purchase, and why did you buy it? So the interview uncovers that story, but the real story is in these tipping moments. What is it that pushed you over the edge? And this is where the domino metaphor comes in, and if you just think of it like a timeline, it sounds like something maybe a little bit lifeless or static; something that somebody kind of goes through, like a timeline of a tadpole turning into a frog, or whatever, like it just happens naturally.
Bob: Yep.
Ryan: And I was trying to explain it the other day and I thought of it like dominoes where if the last domino fell that means that there had to be four dominoes in front of it before it fell.
Bob: That’s right.
Ryan: And if the first domino doesn’t fall, the last one doesn’t fall either. Each one of these things, you have to make it from one step to the next and something has to keep pushing you or pulling you through; there’s got to be some energy invested and there’s got to be some pressures from the situation that really makes it happen.
“And if the first domino doesn’t fall, the last one doesn’t fall either.”Ryan Singer
Concept · The timeline
First thought, passive looking, active looking, decision
Ryan’s dominoes are a vivid retelling of the Jobs-to-be-Done timeline. A purchase is not a single moment. It is a chain of events that starts with a first thought, drifts through passive looking, tips into active looking when something changes, and finally reaches a decision under pressure. Find the moments that tipped each domino and you understand what actually drove the purchase.
Ryan: And I think this kind of imagining the one domino falling onto the next is a nice way to think about what you guys always say causality–that things don’t happen without a reason, which is like such a fundamental truth. But we don’t really reflect on it; we usually think that somebody’s attributes makes them do something, like you like pizza, and therefore you buy pizza.
Bob: Right.
Ryan: But that’s not causal, that’s just attributes. It’s more like, what pushed that domino over so that it hit the next one? And it’s a moment in time; it happened on Thursday at 7:00 p.m. or, right?
Bob: Yeah.
Ryan: And this is something I’m trying to focus on because I’m finding that when people do the interview process sometimes they don’t really know what they’re trying to get out of the interview. They know that it’s interesting, that everything coming from it is somehow unexpected, and it’s giving them this fresh angle. But how do you really know that you have the full story? You’ve got it when you’ve got the first thought going from passive looking to actively shopping to getting clearer about what is valuable to you and what’s not, making a decision and then actually getting into the store or clicking the button or whatever it is to purchase. All these things have to actually happen at a certain time.
Bob: Yep. It’s that causality. And again, you’re never going to get all of it, but the notion is that to be honest we’re never really looking for it in that way. So to me, getting 60%, 70%, 80% of the causality helps you understand how to connect the dots, especially if you have multiple interviews around the same kind of thing. You realize that there are four or five different triggers; there aren’t 100, and there are not . . . when people are actively looking they’re doing maybe not all the same things, but there are only four different patterns of how they look. And so, it helps you now start to understand how to help people to go through the process faster, or differently, or make them shape it up sooner, or help them through that process.
Using the timeline inside the Switch interview
Chris: I think it’s a good tool. I like what you said earlier, Ryan, when we were talking around . . . I think we do a good job of teaching people how to understand the tip of that last domino, right. It’s like really explore the buying moment and get to the cause of why they bought that exact product and that exact moment as opposed to any other product, or any other moment, probably more importantly. But I think the domino metaphor is really useful when somebody who is actively in an interview, and is trying to play back the story in their head really quickly to say, do I have the whole thing.
I also think it’s useful post interview to say, let’s actually think about these domino moments and let’s have a quick discussion around what we think caused one of these to tip, to really understand the cause. I think that’s a cool device that we can use. That’s very cool.
Concept · The Switch interview
Reconstructing the real story of a purchase
The domino moments only become visible through the interview. A Switch interview rebuilds the timeline of a real purchase, from first thought through first use, so you can hear the push and pull in the customer’s own words and pinpoint exactly what tipped each domino. It is the raw material that everything else in the method is built on.
There is a catalog of actual interviews along with analysis available here.
From interviews to better software: focus over feature lists
Bob: So how does this help you design better software? What are you getting out of these kinds of interviews, or this kind of thinking that you haven’t had before or that has enabled you to do something different in how you design the product?
Ryan: Well, if you look at most software out there, let’s say business software, there’s a big tendency to throw everything in the kitchen sink in. And you have a lot of software that does a ton of stuff, with a ton of features everywhere, and it’s hard to use it. It’s confusing, and it’s not focused. And whenever I see a piece of software that has problems it’s usually because there’s not a clear focus on what the purpose is, or what is really most important about it. Let me give you an example. On 37signals we make Basecamp.
Bob: Yep.
Ryan: And Basecamp is a project management tool. But what the heck is project management? Project management could be anything. It could be, let’s say, take Microsoft Project as an example; you’re doing a complicated timelines, tracking dependencies of tasks, and planning out maybe months and months into the future with precision about when different phases are going to be complete. Right? You’re like, controlling and managing and planning a complicated process.
Bob: Yep.
Ryan: That’s one kind of project management. Another kind of project management is like, we need to have all of our materials in the same place, like the designer and the customer researcher and the programmer all need to have the same asset somewhere. And then you get more into like a SharePoint type solution, or Dropbox, where it’s all about putting material together into one place.
And with Basecamp we always decided that communication was the important thing; that we wanted to enable people to say, here’s what’s new about the project, or here’s the new thing for review, or what do you think about this, or what happens next, a place to have conversations back and forth. And because we knew that communication was the thing about project management that was important to us it allowed us to keep the product really focused and not get lost in, oh no, there’s a new, or somebody made a new to-do manager, and teams are using it now. Is it going to take over? Or, Dropbox has millions of users, do we need to get nervous because Basecamp’s file sharing isn’t as good.
The thing that really appeals to me about the Jobs to be Done thinking is that different people value different things because they’re trying to make progress in different ways; and what is the kind of progress that we want to help them make?
Bob: Yep.
Ryan: And if we know that we really want to help people to communicate and we’re not interested so much in helping them do like say long-term planning, then that informs our product decisions so that we can attack the problem that we want to attack instead of just adding more and more features.
Bob: Right.
Ryan: There’s this thing that I see all the time, and this is kind of what I wanted to say in the beginning, with the way that people usually approach business software, especially if they’re getting hired to do it on a client service basis. They’re so afraid of doing the wrong thing, or they don’t know clearly what is important, so they kind of cast a net where they don’t know where the value is, so they build 100 features and then throw those 100 features at the customer and hope that they stick onto one of them.
Bob: Yep.
Ryan: You know? And the question is, how do you figure out which of those features is actually the important thing? And that’s where the Jobs to be Done tools come in. One thing is that if we just talk to the customer about what software they want, they want everything because they don’t ever want to be lacking something.
Bob: Right.
Ryan: And they don’t really experience the development cost of having a lot of features; to them software doesn’t have a mass or a dimension really. The interface does, but people have this impression that software could just have . . . there’s no end to the number of things it could do because it’s kind of not so tangible, so it’s hard to see. So if you ask customers, do you want this feature? They’ll say yes. You ask, do you want this feature, too? And they’ll say, of course. How about this one? Yes, sounds great. Right?
Chris: That’s right. They never say no.
Ryan: Exactly, but then if you build all of that stuff, you’re over your deadline because you built all the stuff you didn’t need to build, they’re not even using it. And then on top of the fact these features that they don’t use they compete for space and for attention on the surfaces of the interface.
Bob: Right. That’s right.
Ryan: So you’re basically compromising the utility of the product in order to hedge against the risks that you didn’t know what to build. It really hits the fan in the user experience in the end, because the interface is so cluttered with stuff because you didn’t know what to focus on.
Why asking what customers want fails: struggle reveals real demand
Ryan: So the Jobs to be Done thing is like, instead of asking people what they want, because they’re always going to tell you more things; desire is endless.
Bob: Right.
Ryan: There’s no end; there’s simply no end; it’s bottomless. But if you ask them about past situations where they struggled to address a problem, then they’re going to tell you about what they tried. And when they tell you what they tried that’s where they put their energy in, because we all have a certain number of hours in the day, and if we tried and tried and tried to get Microsoft Project to work, or if we . . . And then we talk about how we succeeded and how we failed, this reveals our real values from the demand side.
“But if you ask them about past situations where they struggled to address a problem, then they’re going to tell you about what they tried.”Ryan Singer
Bob: Yep.
Ryan: Because we put our energy into, we thought that there was a solution there, and we thought that it fit our situation. So this is where the interviews are relevant, because we get to dig into what’s really important to people.
Concept · The struggling moment
Struggle is where real demand shows up
Asking customers what they want produces a bottomless wish list, because desire is endless. Asking instead about a past situation where they struggled changes everything. People will tell you what they actually tried, and where they spent their limited time and energy. That is where real demand lives, and where the seed of a new product is hiding.
Dimensionalizing: turning vague answers into design decisions
Ryan: And then the other part that’s key is, okay, you’ve got the interview; what do you actually do with it? And this is something that I’m looking forward to hearing more from you guys in terms of workshops and podcasts. It’s what you call dimensionalizing, which is where we say, it doesn’t help me if somebody says easy to use, because there’s never a time when easy to use is a bad thing. Right?
Bob: Right.
Ryan: So, that doesn’t tell me, if I need to make a decision about what to do, that doesn’t inform my decision, because the answer is always just more, more, and more.
Bob: Right.
Ryan: But let’s say I’m working on Basecamp features set, and I need to decide how important is private communication versus on the record communication. Now this is a dimension where people can actually show through their actions and through their decisions whether they value that private communication or they’re really “hiring the product” in order to share on a broader basis within the team.
Bob: Yep.
Ryan: So, building up these dimensions of is private more important or is public more important? When is one more important versus the other? What about speed of response time versus a formality, like I want to do 140 character message, because I can get a quick status report versus I need to look good so I’m only going to publish a 10-page report? You know, these are . . .
Bob: So to me, this is the notion of prototyping to learn, which is you want to create really different effects, or you want to have the spectrum of what people can do and enable them to say, yeah, I would pick Twitter to do that, but I would never pick Twitter to do this. Or I’d pick Twitter to do that, but I would never send an email. Well, why wouldn’t you send an email? Well, because . . . And so, most people are showing people prototypes that are so like in a minutia of difference . . .
Ryan: They are totally the same.
Bob: They think they’re really different, but the consumer can’t differentiate them, and what you find is that what you’re trying to do is use those prototypes as a mirror to understand why they wouldn’t . . . it’s the contrast to know why they wouldn’t pick something that helps you understand what to pick. Because sometimes they don’t know what to pick, but by telling you what they wouldn’t pick it helps you actually build the contrast of what’s there.
So it’s the negative side of the world, and so many people don’t go to consumers with bad things because they’re afraid. And the reality is the bad things actually help communicate what the consumer means, because they can’t tell you what they want, but they can tell you what they don’t want.
Chris: So, if we were to map, and I might even draw something up and put this in the show notes, but like we would want to know, what were the factors around a situation where they chose either Twitter or email, and then, were they at home or were they at the office. Were they on their computer or were they on their phone? If we did a bunch of interviews could we build that spectrum, and then could we build ranges around what they valued about each one when they picked them.
So I pick Twitter because the text was short, and it was public. I picked email because the text was long and it was private. It’s like you can begin to pull out what you’re talking about, Ryan, those design dimensions to say, okay, I see where the prototype fits the situation. And knowing what I know about my product I can start to design toward one of those situations.
There are no new jobs: competing in a job category
Ryan: And the other thing that’s been really good for me is this quote from, who was it, maybe one of you guys. “There are no new jobs.” And this is really healthy when you work in the software business, because everybody thinks it’s a new world every day, and it’s not. And actually it’s not.
Chris: Yeah.
Ryan: Actually it’s not.
Bob: Think about it being additive.
Chris: The problem with software is that as much as people’s demands are endless we think that their time is endless, so it’s like you hear the whole free app story. It’s like people are going to download and use it and it’s free, but we don’t have endless time to just consume these things. Right? We’re not additive; we have to stop doing something to start doing another thing.
Bob: So, we’re going to go see Clay in the next couple of weeks. Ryan, when we’re there make sure that we ask Clay to talk about that there are no new jobs. He has a great story around the chariot, and communication.
Chris: Absolutely. He links it all the way out to kind of how email is basically doing the same job that the chariot did. He’s thought that through really well.
Ryan: It’s really healthy because you get so sucked into thinking that you compete in a products category, but you don’t. You compete in a job category, so like, Basecamp, if we only thought that we competed with other software tools it’d be a total eco-chamber. But we’re not competing with software tools in many cases, instead of Basecamp, you’re going to hire a meeting, or you’re going to hire a status phone call, or you’re going to hire a WebEx or an IM, or Campfire chat. And it’s because you have different jobs that come up in the course of doing a project, where it’s like, I need a question answered, but I don’t know who to ask.
“You compete in a job category, so like, Basecamp, if we only thought that we competed with other software tools it’d be a total eco-chamber.”Ryan Singer
Small hires: the jobs Campfire gets hired to do
Chris: Yep.
Ryan: So, how do you solve that? If you don’t have . . . we have this tool called Campfire that is a little bit of a secret, because not that many people use it compared to the scale of Basecamp. And we wouldn’t be able to run our business without it. And I’ve been thinking lately a lot about, why is it that it’s like that. How come it’s still secret? Right? How come people haven’t figured it out? So I’ve been trying to figure out when do we hire Campfire and for what?
And I noticed that Campfire is kind of like a chat room where the whole company is sitting in there. And we also have rooms for everybody that’s on a project team. And if I have a question about a product I could just go into Campfire and I don’t know who has the answer, but I can say, anybody know what happened with this change in the billing software? And whoever knows could just pipe in. Now that job didn’t appear because I have Campfire; I have that job not matter what.
Chris: Right.
Ryan: But what would I have used if I didn’t have Campfire? I would not have gotten a response by email to that.
Chris: I don’t think I can let you off the hook on this, Ryan. Have you interviewed your existing customer base? Have you gone and done some interviews around it?
Ryan: No, I have not.
Bob: So we’ve actually been working with some clients around this and it gets back to expert location. What you find is there are certain people in the organization who know about those things, or they know who knows. And so, what you find is you send an email or you stop somebody in the hall and say, hey, whatever happened to that? I don’t know, but you should talk to Joe, because Joe will know. And so there are these people, so there’s this expert location . . .
Ryan: So, totally, yeah. And you could hire basically that same thing; I’m going to hire the network to solve this problem.
Chris: Yeah.
Ryan: And you could hire the network, but hiring the network is slower on another dimension that you might care about. So one dimension of a problem or the situation that defines a job is like, I don’t know who to ask.
Chris: Right.
Ryan: I have a problem and I don’t know who to ask. But another dimension is how urgent is it.
Bob: Right.
Ryan: And if it’s urgent I don’t have time to hire the network, because then I have to do the whole telephone game versus if I have a tool like Campfire I can outperform the network job candidate.
Chris: Wow.
Ryan: Because I can get an instant response. And this is the thing; one of the things that’s really exciting to me about what I’ve been learning from you guys is that having that vocabulary to describe that.
Bob: Yeah, so we were at Bose a while ago and the interesting thing is that they have a policy that competes with it my opinion. The policy is there’s no food or drink allowed at your desk. And the purpose is mainly to make sure that everybody goes to the cafeteria, which then promotes the interaction with other people about problems and what you’re doing and what you’re working on. And so their whole thing is their policy actually promotes the network. To me, Campfire competes with that policy.
Ryan: Totally. Yeah, with the policy itself, yeah, it does.
Bob: So that’s what I’m saying. Again, people don’t understand what you’re really competing with in a place like Bose might not need a Campfire, but somebody who doesn’t have that policy can either hire the policy or they can implement Campfire. Right? So, it’s very cool.
Concept · The Four Forces of Progress
Situation and urgency change which solution wins
Ryan’s Campfire example shows the forces at work. The same job, getting a question answered, can be hired out to email, to the network of colleagues, or to a chat tool. Which one wins depends on the push of the situation: when the question is urgent, the friction of the network loses to the pull of Campfire’s instant response. Map the situation and you can predict the switch.
Disruption, the low end, and where customers can name the problem
Chris: I’m glad you brought up the communication focus of Basecamp, because I think when you throw something out there like, and there are situations where Microsoft Project is good, right. But when you throw something out there like Microsoft Project or you throw out the complex project management solution, do you realize that without that focus and without that understanding of the situation that the users are in when they’re drawing upon it, you need to be good at every feature and every thing in every situation. Right?
So if you’re just competing at that bar you need to develop, like you said, it’s a crowded space, and you’re competing against every feature and you need to be . . . and really I think what we’ve learned about software is that even with nearly unlimited resources it’s impossible to be excellent at everything, if you’re just going to lop feature after feature into a product.
Bob: But that get’s back to Clay’s whole point around disruption. Right? You don’t even see the fact that a simpler, less performing product can actually fit in the category, and so you become blind and all you do is compete with everybody. So the pack moves ahead and creates this whole void in the market for low end simple disruption that’s very fragmented, that for the most part the big companies can’t see. And so to me it gets back to what we’ve been taught; that pursuit of profit that makes us go up market that misses the opportunities that are at the low end of the market that might not be as value added, but they might be bigger.
Ryan: It’s tricky, too, because up market customer, they actually know very precisely where they’re not satisfied by the current performance.
Bob: That’s right.
Ryan: And the low end customer doesn’t know what’s not working for them, because they haven’t struggled with it enough.
Bob: That’s right.
Ryan: Or the choices aren’t there; the choice side isn’t clearly defined. So it’s so much easier to take a product up market because you have customers who are already paying you who tell you exactly what’s wrong.
Bob: Yep, love it; it’s dangerous. So if you’re up for it we’d love to have you on again, and these are great. There aren’t many people we can have these kinds of deep conversations with, so we appreciate you coming on today.
Ryan: Guys, it’s always a blast.
Bob: Yeah, and we’ll see you with the second, but . . .
Chris: I hope to have you out in New York. Jason’s going to dial into the Switch Conference in New York City on the 17th, and kind of kick us off and talk about how Jobs and the Switching process has impacted you guys at 37signals. But it would be great to have you join in person as well. So we’ll see if that can happen.
Ryan: And if folks haven’t seen my online they can follow me on Twitter at RJS, and my blog is at FeltPresence.com where I talk quite a bit about product design and try to apply these ideas.
Bob: I think one of the podcasts I want to do later is one that we talked about the structure of work, because I just think it’s relevant to jobs because at some point as you look at the work you’ve got to see the problems and from the problems you know where the technical issues are and how to use Jobs to help sequence work, because it’s very good.
Chris: And once you get the fuel from the Jobs research how do you actually move this forward and structure everything going forward.
Ryan: Great blog.
Chris: Thanks for mentioning both those things, Ryan, and I’ll put links in the show notes for everybody at JobstobeDone.org, so they can get to your blog and actually that article that you wrote about structuring the work, because that’s very important.
Ryan: Cool.
Chris: Thanks for being on, Ryan, talk to you soon.
Ryan: Thanks guys.
Bob: See you. Bye.