39. Shaping the Work: Design and Development Through the Lens of Jobs Theory

Hi, this is Clay Christiansen 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 typ 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.

I'm Shea 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 Mesta. 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, feltpresence.com and also on Twitter. Bob Mesta'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.

Yeah, I was just digging into that. I think it was 2012, so maybe, maybe going on seven now. And I actually heard Bob on a podcast. I heard him talking about something that just I had been kind of 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, you know, whatever the committee could agree on. There was some kind of like 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 and I thought, man, this is really in line with a lot of stuff that I've been thinking and chewing on over the years. And we got in touch shortly afterward and we met for dinner. It was Just like. It was just like, boom, boom. Like, everything clicked, and we had a lot to talk about.

So for me, Ryan kind of reached out. I think it was Horace's podcast, wasn't it?

Yeah, yeah.

So it was on Horse Deduce Podcast, and we were. And Horse had just kind of interviewed me around some of the stuff around jobs. And what I would say is. I'm not sure what I would say is what we were. What I was doing was objective, but it was less subjective. And so 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, like, I. I felt we were peers, and it was like he had been wrestling with some of these issues, and kind of the moment we first kind of met, it was like, well, I'm wrestling with this. I'm like, oh, I've wrestled with that. Here's. Let me tell you how I've wrestled it. I still haven't solved it, but here's what I've done. And so it was almost like, you know, two kids in a candy store, kind of like, at least somebody willing to. Who's willing to wrestle with some of these issues, like, because it's like, for the most part, a lot of people would come to me for help, but nobody was willing to be that intellectual kind of wrestler around some of the issues. So that first dinner was, you know, to be honest, is one of those things. I will literally just go to Chicago to have dinner or spend the day with Ryan to kind of have those kind of wrestling. And 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. And he's kind of the first one who. Who really was like, a sparring partner for these kinds of topics and thinking and all that kind of stuff. So that's. It was, like, really, really refreshing to finally meet him.

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

So, first of all, let's go. Let's go. Yin and yang. And so the reality 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.

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 kind of where the. All the way down to whether it's an aesthetic decision about where the button 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. And it's kind of like. 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 kind of 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? And the sort of 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. And we need to understand that in order to know how to capture it.

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. And who they were wasn't necessarily connected to what they were trying to do or the set was not. And so a lot of times this is where, you know, Ryan and I use the phrase unpacking. We're unpacking things down to action. And so I would say that's. That's more. 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 kind of pulling things from the past and doing interviews. And I'll say there's clunky things that we can't get that real data yet.

But the.

But now, for example, in basecamp, you can actually see behavior because, you know, the jobs. And so it's actually, you know, 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.

So Bob was talking about when he was in the home building business and he was talking about designing condos for empty nesters. And one of the issues was what they said that they wanted didn't fit with their actual choices in the end. So they were saying that they wanted the 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. And when Bob redesigned the condo to have space for a big dining room table and actually used an old kind of, you know, old fashioned dining room table, that, that in the model unit, this was something that, 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 and the floor plan, you know, and that's, that, 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 kind of looking at a floor plan and trying to come up with what the best floor plan could be. Right.

And it goes back to. Consumers have a very hard time articulating what they want and the cases. They don't know what they want and at the same time they don't actually know the trade offs they're willing to make. And so part of this is where and when you talk to people and how you talk to people that help you extract the value code so then you can lay it onto other people. And so 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. And you're like, okay, what am I doing wrong here? And 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. And you really make, you'd end up making trade offs as an engineer. And the reality is the rest of the world had no concept of trade offs. Like 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.

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?

People are in a situation struggling to make progress, and 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 kind of throwing a bunch of solution ideas out there. And 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. So if we understand kind of what's not working for them, what they've already tried, and kind of what it's like to be in their situation, then we can understand what's important and then that kind of creates requirements for us to design against. So if we get too much into the need language, then we all kind of just start talking about solutions again. But if we talk more about what's not working and 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.

No survey told IKEA to say, yeah, people want to assemble the furniture, nobody wants to assemble the furniture. And 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 multi billion dollar company like this is the subtleties of what we're talking about. In a lot of cases, it's not necessarily giving them what they want, but giving them parts of what they want and understanding the things that they'll actually overcome in order to make it happen. And so again, if I ask people, like how many people want to put their furniture together, I think nobody does. And the reality is when you put it together, you actually now it becomes yours. And it actually is more important in your life than anywhere else.

Right. And I have, 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.

And 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's like it just has to feel, it just has to be good enough. And so the thing is, it's that aspect of knowing what good enough is. So I work with a guy in Japan, his name, Dr. Kenichi Taguchi, and he would always say, like, building the best thing in the world is actually really easy. So 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 kind of cars. He goes, the hardest part is when you take low quality things and put them together and create high quality. And so his whole notion was called something called robustness. And 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. And to be honest, that's the bulk.

Of the market is the way that we think about this in the software world is. So we had a version of Basecamp that came out. We've done three kind of redesigns of the product, three generations of the product. And when we did version three, we didn't include a visual calendar in it. We had a very simple kind of agenda view that just showed events that were part of a project in a list. And we were hearing requests from people saying, can you please build a calendar into Basecamp? We need a calendar. And 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. And 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, kind of reactive projects. So what we need to figure out is if we're only interested in spending, let's say, like six weeks, or building a calendar, which is like 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 tenth of a calendar. And then the question becomes, what's the right tenth? If we just say, go build a calendar, that there's no shape to that idea. That's just some words. And if you give that to a team, I mean, how are they going to know when they're done? So 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? And this is what really happens so often in software companies is that they have poorly shaped work. So work that doesn't have a kind of clear definition of what it's supposed to do, what the boundaries are, what it is and what it's not. And then this goes to a team, and then the team has to. Has to interpret what success looks like. So then what you end up happening is projects that have lots of scope creep, that go on and on and on, because it could always be better, right? And 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 have make decisions together about whether what they have is the right thing or not. Right? 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. So 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 asked 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? We get the story, and then based on that, we can create a problem definition. Then that problem definition gives us the thing to solve for that we can come up with the right solution and judge the Fed.

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

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? 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 sort of 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 and appetite, the rough outline elements of a solution that we know is viable based on experience as being more senior people. And 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 sort of the holes in the concept that could make the project get delayed or people could get stuck going in circles on. Right. And if we address all those things and we kind of 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. And that way we can actually ship it and the team can actually get the thing done in the amount of time that everybody feels is meaningful and valuable.

So a lot of times you'll have a project that says we need to build a calendar and we'll be like, oh, how much money do we have? Okay, how much time do we have? And they're not asking kind of the right question because strategy's 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? And 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. And 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 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. And 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. And these are things where these are very mature decisions that people are making between. But they're done in plain view and in transparency as opposed to kind of politics.

Yeah, you can also look at this. You can look at this sort of 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 kind of 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. 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. So it's more about like, how do I get the information that I need as an input to this process of defining the work and less about kind of immersing everybody in the whole company in it.

And are you saying that Jobs is a process for getting you there?

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

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

Exactly.

That is a perfect note to leave our listeners on.

Well, thank you very much for the.

Time thanks so much for joining me today.

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.