Clay Christensen: Hi, this is Clay Christensen, and I want to welcome you to a podcast series we call the Disruptive Voice. In this podcast, we explore the theories that are featured in our course here at HBS, Building and Sustaining a Successful Enterprise. In each episode, we'll talk to alumni of our course and others who are trying to put these theories to use in their lives and in their organizations. It's great fun to hear from them, and I hope that you find these conversations inspiring and useful. If you have an idea about a topic or a speaker that you'd like to hear more about, or if you'd like to comment on our work, please reach out to us here at the school.

Shaye Roseman: I'm Shaye Roseman, and you're listening to the Disruptive Voice. Here today to talk about Jobs and product development, I've got Ryan Singer and Bob Moesta.

Shaye Roseman: Ryan is the head of strategy at Basecamp, a project management software that helps teams collaborate and work more effectively. In his more than 15 years at the company, he's held a variety of roles at all levels of the software stack. He's also a prolific writer on product design and development at feltpresence.com, and also on Twitter.

Shaye Roseman: Bob Moesta's voice should be familiar to many listeners of our podcast by now. He's the co-creator of the Jobs-to-be-Done theory, and a co-founder of the Rewired Group. He's also on a short list of key influences that Brian has on his blog, along with our friend and colleague, Clay Christensen, who's made that list as well. So maybe to get started, Ryan and Bob, why don't you tell us a little bit about how you first met? I think it was around six years ago now.

Ryan Singer: Yeah, I was just digging into that. I think it was 2012. So maybe going on seven now. I actually heard Bob on a podcast. I heard him talking about something that just, I had been waiting to hear from somebody, somewhere. He was talking about design, and he was doing it in a way that wasn't just a bunch of made up opinions, or a kind of a, whatever the committee could agree on. There was some objectivity to it, and there was a sense that it was based on cause and effect, and actually understanding what's going on in the world. That was really exciting to me. So I heard that podcast, I thought, "Man, this is really in line with a lot of stuff that I've been thinking and chewing on over the years. We got in touch shortly afterward and we met for dinner. It was just like boom, boom. Everything clicked, and we had a lot to talk about.

Bob Moesta: For me, Ryan reached out. I think it was Horace's podcast, wasn't it?

Ryan Singer: Yeah.

Bob Moesta: Yeah. So, I was on Horace Dediu's podcast. Horace had just interviewed me around some of the stuff around Jobs. I'm not sure what I would say is what I was doing was objective, but it was less subjective. The aspect is when Ryan and I first met up, it was ... We're about 15 years apart, Ryan, in terms of age, or almost 20? But it's one of those things where we, I felt we were peers and it was like he had been wrestling with some of these issues and the moment we first met, it was like, "Well, I'm wrestling with this." I'm like, "Oh, I've wrestled with that. Let me tell you how I've wrestled with it. I still haven't solved it, but here's what I've done."

Bob Moesta: It was almost like two kids in a candy store, like at least somebody who's willing to wrestle with some of these issues. Because for the most part, a lot of people would come to me for help, but nobody was willing to be that intellectual wrestler around some of the issues. So that first dinner was, to be honest, it was one of those things. I will literally just go to Chicago to have dinner or spend the day with Ryan, to have those kinds of wrestlings. Most of it's about language. I don't think it's about what's right and wrong. It's more about better ways or different ways, and that kind of stuff. He's the first one who really was like a sparring partner for these kinds of topics and thinking and all that kind of stuff. It was really, really refreshing to finally meet him.

Shaye Roseman: So Ryan, when you say objective, and Bob, you say, less subjective, what do you mean by that? Less subjective than what?

Bob Moesta: First of all, let's go Yin and Yang. The reality is, is they're both two sides of the same coin. One is coming from the bottom, to me, and the other one's coming from the top. So to me it's, they mean the same thing, but they have different standards.

Ryan Singer: Yeah, what I mean by objective is that when it comes to doing design, there's so many opinions about what the product should be or what's the right way to do an interface or where the ... all the way down to, whether it's an aesthetic decision about where the buttons should go to a functional decision about how the process should work. A lot of times, it's just the folks in the room who are making the thing debating with each other about what they think they should do.

Ryan Singer: It's a little bit like people designing a sailboat and nobody knows what wind is. It's like everyone's talking about, "I think it should be taller. I think it should be beige. I think it should be white. I think it should be this shape or that shape." And there's no real test to say, "Yeah, but is it going to go? Is it going to work? Is it going to fit? Is it going to be the right thing?"

Ryan Singer: The secret to having a conversation that's not just about our opinions and our wishes and our intentions, but about what's actually going to work, is we need to have that, not just the supply side conversation, but we need to have the demand side conversation, about what are people actually trying to do. That demand side is like the wind that pushes the boat. We need to understand that in order to know how to capture it.

Bob Moesta: That's right. Just to add to that, it's this aspect of being able to unpack things down to causality. It's more about the action of something as opposed to the description of something. Most people would know who their customers are, but they wouldn't actually know what their customers were trying to do. Who they were wasn't necessarily connected to what they were trying to do, or the set was not.

Bob Moesta: A lot of times, this is where Ryan and I use the phrase unpacking, we're unpacking things down to action. I would say that's more objective. But the reality is, is that it's just less subjective. Because ultimately, they have to see it in the wild. And the way we do it, we're still pulling things from the past and doing interviews. I'll say, there's clunky things, that we can't get that real data yet. But now for example, at Basecamp, you can actually see behavior, because you know the Jobs. That, to me, is as objective as you can get, when you see what people are doing and you can say, "Oh, because they're doing this, this and this, they're in this Job."

Ryan Singer: Bob was talking about when he was in the home building business, and he was talking about designing condos for empty-nesters. One of the issues was what they said that they wanted didn't fit with their actual choices in the end. They were saying that they wanted a small dining, they didn't need a big dining room, because it was just going to be the two of them in the house now. But then when push came to shove, they had this old precious dining room table that had held all their family memories. When Bob redesigned the condo to have a space for a big dining room table, and actually used an old-fashioned dining room table in the model unit, this was a design decision that was based on understanding the fact that people were struggling to get rid of that table, and that they needed to bring the table with them when they moved. You needed to actually understand the situation to make that trade off about how to use the space in the floor plan.

Bob Moesta: That's right.

Ryan Singer: That's what I meant by more objective. It came from understanding the real circumstance that the customer or the user is going through, instead of just looking at a floor plan and trying to come up with what the best floor plan could be.

Bob Moesta: Right, and it goes back to, consumers have a very hard time articulating what they want. The case is, they don't know what they want. At the same time, they don't actually know the trade offs they're willing to make. Part of this is, is where and when you talk to people, and how you talk to people, that help you extract the value code. Then you can lay it onto other people. Part of this is, that objectivity is, and it only came from me in my very early days of just building a bunch of stuff that people said they wanted, but then they didn't buy.

Bob Moesta: You're like, "Okay, what am I doing wrong here?" You start to realize, it's the system that's wrong. Because I'm asking what they want. They don't actually know what's possible. I'm interpreting it. I only have this much time and this much money to build something. You'd end up making trade offs as an engineer. The reality is, is the rest of the world had no concept of trade offs. The design world had no set. Like, "We should make this as pretty as possible and make this as perfect as possible." Everybody else was trying to make everything perfect. But the reality is, nothing's perfect.

Shaye Roseman: Why do people find it hard to just tell you those things themselves? Why is it so hard for people to just say it outright?

Ryan Singer: People are in a situation struggling to make progress. If they knew what to do, they would have already created their own solution. They wouldn't need to go out and shop, or compare alternatives, or anything like that. The really deep thing for me about Jobs is the fact that it's a way to look at what we're trying to make as an empty space that we're going to fill in, instead of just throwing a bunch of solution ideas out there. What we're trying to get at is, not so much what the person needs or what they want, but the situation that they're in, and the way that they're struggling. If we understand what's not working for them, what they've already tried, and what it's like to be in their situation, then we can understand what's important. Then that creates requirements for us to design against.

Ryan Singer: If we get too much into the need language, then we all just start talking about solutions again. But if we talk more about what's not working and what ... like, how much time pressure are they under? What do they know and what do they not know? What kind of trade off are they going to make if they're presented with different options? That's going to create that negative space that we can start to all sit around together, and then figure out what's the right solution that actually fits into that situation.

Bob Moesta: No survey told IKEA to say, "Yeah, people want to assemble the furniture." Nobody wants to assemble the furniture. So it's the subtleties of knowing that if I can get you this furniture at this price, but you have to assemble it, that they're willing to make the trade off to do it, to be a multibillion dollar company. This is the subtleties of what we're talking about. In a lot of cases, not necessarily giving them what they want, but giving them parts of what they want, and understanding the [inaudible 00:11:10] that they'll actually overcome in order to make it happen.

Bob Moesta: Again, if I ask people, "How many of you would want to put the furniture together," I think nobody does. The reality is, is when you put it together, you actually, now it becomes yours, and it actually is more important than your life, than anywhere else.

Shaye Roseman: Right. I can think of several occasions on which I have personally put my own furniture together, because it was worth it to me in that instance.

Bob Moesta: It's worth it because of, usually I have to wait six weeks and this is going to sit empty. I can get something used on Craigslist, but I want something new. It just has to be good enough. The thing is, it's that aspect of knowing what good enough is.

Bob Moesta: I worked with a guy in Japan, his name is Dr. Kenechi Taguchi. He was always say, building the best thing in the world is actually really easy. Building a Mercedes, when precision is everything you have to do, it's like, "I take high quality components and I put them together, and I make high quality cars." He goes, "The hardest part is when you take low quality things and put them together and create high quality." His whole notion was something called robustness. The aspect here is, how do we actually think about being able to add value by taking things like particle board and Formica and laminate and putting it together to say like, "Wow, that looks like a great piece of furniture, and it functions for what it is, good enough." Good enough is really hard to create. To be honest, that's what the bulk of the market is.

Ryan Singer: The way that we think about this in the software world is, so we had a version of Basecamp that came out. We'd done three redesigns of the product, three generations of the product. When we did version three, we didn't include a visual calendar in it. We had a very simple agenda view, that just showed events that were part of a project in a list. We were hearing requests from people saying, "Can you please build a calendar into Basecamp? We need a calendar."

Ryan Singer: We could have easily spent a year building a great calendar, or we could have spent six months building a great calendar, maybe six months. But we have to look and say, "How much time is it worth for us to spend on this?" We knew from past versions that maybe 10% of our active customers were using calendar features, and there's a lot of other things that we could be spending our time on. If we have to spend six months or a year every time that we build out a feature request, we're never going to get to do anything that we actually want to do. We're just going to be doing really long reactive projects.

Ryan Singer: So what we need to figure out is, if we're only interested in spending, let's say six weeks building a calendar, which is the kind of project size that we feel comfortable with here, if we wanted to spend six weeks on that, we have to figure out how to build a 10th of a calendar, and then the question becomes what's the right tenth? If we just say, "Go build a calendar," there's no shape to that idea. That's just some words. If you give that to a team, how are they going to know when they're done? Even if they were lucky enough to include the right things in their definition of calendar, so that they were able to do the job, they're going to build so much other stuff, because everyone is going to use their own definition of what a good calendar is to figure out when to stop. Is it worth spending six months or a year?

Ryan Singer: This is what really happens so often in software companies, is that they have poorly shaped work, so work that doesn't have a clear definition of what it's supposed to do, what the boundaries are, what it is and what it's not. Then this goes to a team, and then the team has to interpret what success looks like. Then what you end up happening is, projects that have lots of scope creep, they go on and on and on. Because it could always be better, right? Then on top of it, the folks who are maybe doing the research or getting the requests or coming up with the ideas, they keep getting pulled into meetings, because everyone has to make decisions together about whether what they have is the right thing or not. Right?

Ryan Singer: So it's basically a massive waste, if you don't figure out what it is that you're actually trying to do before you commit the resources to going after it. What I'm going to do then is, I'm going to get on the phone with whoever wrote the request or Chase here at Basecamp does this a lot, we call it support sleuthing, and basically we get on the phone and we say ... we don't ask them, "Why do you want that?" We ask them, "When did you want that? What situation were you in, and what was happening to you when you had the idea that this wasn't working, and that you should write us about it." And we get the story.

Ryan Singer: Then based on that, we can create a problem definition, right? Then that problem definition gives us the thing to solve for, that we can come up with the right solution and judge the fit.

Bob Moesta: But Ryan, what do you mean by shaping the work?

Ryan Singer: Well, just to use the calendar example again, if we say, "Go build a calendar," there's no shape to that. That is just a big abstract statement that everyone is going to interpret themselves. And the teams are going to build out a lot of stuff that they don't need to build, and the project is going to take forever, and we're going to have a lot of constant debates about what it should be and what it shouldn't be. So we need to have a sense of, what's the actual problem from the demand side? What's going on? What's our appetite? How much time do we actually want to spend on this? What are the elements of the solution?

Ryan Singer: We can't just give a team a research project, right? Because then, we're going to be back in that same situation again. But if we can have some senior folks who understand both the technology of the system as it stands, and the design possibilities for coming up with something new, if you get those folks together, we can do the pre-work to come up with the basic elements of an idea that's viable within those constraints. So now we've got the problem, an appetite, the rough outline elements of a solution that we know is viable, based on experience, as being more senior people.

Ryan Singer: Then we also spell out, what are the things that we're not going to do? What are the rabbit holes that people might fall into, or the holes and the concepts that could make the project get delayed, or people could get stuck going in circles on? If we address all those things and we do that work, then that's what we call the shaping work, where we've done so much work on the project that we've removed a lot of risk. And we've also come up with a more specific idea that fits to the amount of time and resources we want to spend on this thing. That way, we can actually ship it, and the team can actually get the thing done in an amount of time that everybody feels is meaningful and valuable.

Bob Moesta: A lot of times you'll have a project that says, "We need to build a calendar." And it'll be like, "Oh, well how much money do we have? Okay, how much time do we have?" And they're not asking the right question. Because strategy is not coming in to say like, "Here's what's important for us to work on, and here's where it is, and what should we do?" So the other part is the conversations around trying to manage the trade offs between, "I've only got six weeks. It's going to take six months. How do I reshape the work to say what does progress look like for six weeks? Is this really something that's going to work?" Those are all conversations that you have to realize are very, very mature, and they're mature because they know. They're not mature because they don't know. Like you said, focus is scary when you don't know what to do.

Bob Moesta: So the notion here is that when everything is on the table, the fact is, you want to rule anything out, because you want to be successful. And the reality is, is this is where I think product managers are actually not shaping work clear enough. Because what they're doing is, they're giving teams, "Go build a calendar. And oh by the way, do it all in six weeks.". So they either do a crappy job, or they end up taking six months to do it, and all the administrative stuff to go with it. These are the things where these are very mature decisions that people are making between them, but they're done in plain view and in transparency, as opposed to politics.

Ryan Singer: Yeah.

Bob Moesta: You can look at this through the lens of the resource allocation process. If everybody in the whole company is supposed to know what's ... understand Jobs and understand what's important to the customer and stuff like that, I think one of the reasons that a lot of startups and software companies want everyone in the room to figure out what the job is and to learn Jobs is because they don't actually have a process for how to make decisions other than put everybody in the room.

Bob Moesta: The way that I see it is that I don't actually need anybody else at Basecamp to care about Jobs, really. All I need is a better input to the shaping process. And the fact that we have a clear process for how we define work, how we bet on the work, and then when we give the work to a team, that they have that bundle of problem and solution and appetite and so on. They have all the information that they need in order to execute well with the definition of the project.

Bob Moesta: So it's more about, how do I get the information that I need as an input to this process of defining the work, and less about immersing everybody in the whole company in it.

Shaye Roseman: Are you saying that Jobs is a process for getting you there?

Ryan Singer: Exactly. Jobs is a tool that I can reach for when I don't feel that I have the right inputs.

Bob Moesta: When it feels dark, I pull Jobs to help me turn on the light, so I can see the right information.

Ryan Singer: Exactly.

Shaye Roseman: That is a perfect note to leave our listeners on.

Bob Moesta: Well, thank you very much for the time.

Shaye Roseman: Thanks so much for joining me today.

Clay Christensen: Thank you for listening to us at Disruptive Voice. If you like our show and want to learn more, please visit us at our website, or leave us a review on iTunes. Until next time, good luck everybody.