Shape Up with Ryan Singer of Basecamp

Hey everyone, and welcome to Bright and Early, the podcast for people building early stage startups. I'm your host, Brian Ray. I talk to entrepreneurs, product people, designers, and marketing pros to learn what works, what doesn't, and why, giving you at least one thing to apply to your business first thing tomorrow. My guest today is Ryan Singer. Ryan is head of product strategy at Basecamp. where he has designed features used by millions and invented processes used by their team to design, develop, and ship the right things. He shares many of those processes in his new book, Shape Up, and we'll be discussing that today. Ryan, welcome to Bright and Early. Hey there, happy to be here. It's my pleasure. I was telling you before we hit record, I've been following your work for... Well over a decade and so this is this is quite a treat to have you on so so thanks so much sure thing So I want to talk about shape up. This is only gonna be like 45 minute interview, but there's a solid 20 hours worth of questions and conversation that I would love to ask you about but the first thing is I do want to I want to hear a little bit about your experience You've been at at base camp for 16. Is it 16 years? Yeah, it's been 16 years now. Mm-hmm. So and if I have my history right you started off doing ui design when the company was still a design agency right so what was what was that like in the in the early days it was awesome i mean i learned so much um at every stage of of the company's growth so far when i first came in i was just a really big fan of jason's work um 37 signals at that time really stood out from the crowd because in the early web design scene A lot of the design was sort of a very dense graphic design kind of packed into a little box in the middle of the screen. And a lot of images that were stitched together so that you could click on one part of the image and it would be a button, but the rest would be sort of the background around the button, this kind of a thing. And there was a lot of people doing interesting work in that style, but you'd go to 37Signal's website at the time and it was just text. And it was just about the statements that they were making, the values that they had, the opinions they had. And it was much more about how things work instead of how they look, even though they also looked really sharp. But it was a much more sort of usability-focused, functionality-focused, clarity-focused style. At the time, I don't know who's been around long enough to remember, but I was a big fan of useit.com, Jacob Nielsen's site. He was one of the early proponents of usability when that term meant a lot more at that time because of the context we were in. The web was so graphic and all over the place and so immature. that to have somebody trying to say, hey, things should make sense, things should be clear, that was actually new. Now it's so seeped into the culture of web design that it's quite normal to see beautiful and really usable, well-thought-out sites, but that wasn't so much the case at the time. I was really admiring Jason's work there, and then when I saw that he was looking to hire somebody, I... I reached out and tried to get the job and it turned out that we were very like-minded, but he was also ahead of me in a lot of ways. I learned a ton from working under him on a variety of short projects before we started doing Basecamp. Were you in Chicago already? Yeah, I was in Chicago at that time. Okay, got it. It's interesting talking about the state of web design in the early 2000s and in the mid 90s and whatever when the concept that a web browser would be able to display an image was just such a revolution. And that was that was so great. It was such an improvement. It matured to the point where it started to affect usability. Right. Are there things that you see now in web design, given your experience, that technologically huge advancement. Great that we can do that, but that are being overused and are actually starting to negatively affect. what people like us do for a living? I'm not sure I would say. I'm sure there's things that we could point out that are problems with web design today. But the main thing for me, just because of where I come from, when I look at the web today, I'm just blown away. I'm just blown away. The level of graphic design, the level of technical engineering, it's just incredible. Every corner you turn when you look at a really properly professionally produced site It's just incredible the amount of skill and expertise that's that's been integrated together to do that and it's so far ahead of Stuff that I was doing when I was learning you know years ago and and I didn't I didn't stay In the field of you know, what's the new HTML CSS technique? I didn't stay there my interests kept moving I moved from being interested in web design to web UI plus programming to product to strategy and then occasionally dipping back again. For people who have actually stayed in the weeds of what's technically possible and how to do things better, we have a marketing designer named Adam for example and Adam's work is I mean, it's not only 10x, it's like 100x better than what I could do if I were tasked with the same thing because he has so much more skill down in the details of all that type of work. Yeah, that's really fascinating. Well, I want to talk about ShapeUp because it has predictably, I think it's fair to say, made quite a splash in design development circles that we run in. So congratulations. is a fantastic work. But so yeah, of course. So for listeners who maybe haven't read it just yet, can you give just the quick gist, like the key idea that you were hoping to share in writing it? Yeah. Shape Up is born out of our, you know, 15 plus years of trial and error, figuring out how to do product development for Basecamp. And the book is sort of two things in one. On the one hand, It's a handful of specific practices that we use. So these are sort of the phases of the work that we go through to go from raw idea to something that we can schedule to something that's getting built to something that ships. But at the same time, and actually more importantly, the book is also spelling out what we think are some basic facts about the universe. What do you mean by that? Whether or not you work in exactly six weeks like we talk about in the book, or whether or not you write a pitch with the five points that we recommend to include in the pitch when you're presenting a possible project to bet resources on, for example. The underlying key points are about truths about work that you can't get around. If you want to make an omelet, an omelet starts with raw eggs. And there's a million ways to make an omelet, but that's just a fact, right? And in the same way, work that a team builds, projects that teams take on, they start with raw ideas. They start with unshaped, hey, maybe we should do that. Hey, the CEO had this idea in the shower yesterday. Customers are requesting this. We got this feature request from sales. These inputs come in and they're not actually... ready to bet on until we do something more to them to clarify what they are, to define what they are and what they're not, to set bounds and expectations on them so that if we are to delegate that work to a couple people to go execute, that we know what they're executing, they know what they're executing, and everybody has some confidence that we're really going to release. more or less what we wanted at the end of a time period that we scheduled for it. We don't just get that by magic. We've seen different extremes of how to deal with that over time. There's been the sort of waterfall extreme of let's specify every little detail of what this thing needs to be upfront, which is too concrete and that doesn't work because you don't know all the details upfront of how to really put it together. down to the tiniest detail. So that blows up in your face and all the things you think you had to do turn out to be different than what you really have to do once you get your hands dirty, right? That's another fact of the universe. We don't know upfront when we're working with something that is a novel problem that we haven't exactly solved before and there's interdependencies in the problem that we can't quite see in advance, there's going to be surprises, right? So we can't over-specify the solution upfront. Then on the other hand, there's the other extreme of what agile turned into, which is we don't know anything. Let's just let the team figure it out and hope for the best and then just swing at it two weeks at a time and eventually we'll figure something out. And that's not strategic. It's true that you don't really know in advance, so it's good to give more room to change course. But at the same time, if you're making an investment, you have to know what you're investing in and what you're pursuing and why you're doing this instead of something else and what you're going to get out of that investment. So if we just say, hey, go build this feature and figure out what it really is by sprinting at it or whatever, then we're being too abstract. We're being too fuzzy about what it is. So this word shaping refers to the work that we do. on a raw idea to reduce our risk and increase our clarity by setting boundaries around it and figuring out kind of what the key points of the solution are while still leaving enough latitude inside of it for the team to work out the details. So it's a level of roughness and a level of abstraction where we are getting clear about what the work is and we're thinking harder about what the work is before we get to the point of doing real design and doing, you know, real programming. And then the outcome of shaping is that we have some work that we could potentially bet on. So now we have some work that we have better odds of success. And especially when we, when we talk about betting, we have this notion of, of this applies to both the shaping and the betting process. We have what we call an appetite. So an estimate is where you start with a design and then you say, how long is it going to take to do that? Right? So you start with a design and then you get to a number. An appetite is where you flip that around. You start with a number and then you go to a design. So you say, how much time is this worth to us strategically? So there might be something that comes up that's worth doing, but it's only worth two weeks of everybody's time. It's not worth an eight week project. In that case, if you can declare that upfront, then you're setting some boundaries on the design process and you're creating a situation where people who are downstream from that, who are going to do the work, are going to have to make trade-offs in order to get that thing done, different trade-offs than they would make otherwise. What I mean by trade-offs is a steak might be better than a hot dog. in terms of a quality meal, right? But if you only have five minutes, if you only have five minutes, a hot dog is better than a steak, right? So the constraints totally change the definition of value and what's good and what's bad, right? So the outcome of the shaping process is that we have a potential bet that fits within the appetite for what we think this thing is strategically worth. And now we can look at this potential bet and say, Do we have the right people around? Is this the right time? Is this something that we want to do or not? Have we shaped it sufficiently to remove enough of the risks that we can manage? You can never eliminate all of the risk, but have we done our best to improve our odds so that when we make the bet that we're successful? And then that really comes into how is betting different than planning? And how is it different than just sort of scheduling time and pecking away at something, one sprint after another? When you make a bet, a bet has a capped downside. If you say, I'm going to bet $100 that this thing happens, the most you lose is $100, right? And that's the logic of the whole thing, right? We want to have the exact same logic apply to our scheduling and our resource allocation. So if we say this particular feature or this particular improvement is worth six weeks of a team's time, and that team is, let's say, a designer and two programmers, we're making that up front as this is how much we're willing to commit to get this outcome. If that thing starts to get out of control or it turns out to be more complicated than you thought or something goes sideways on the project, that doesn't mean that that project starts to become worth more. Right? So it doesn't make sense to automatically increase your cost and increase your commitment just because it got harder. The fact that it got harder and the cost got higher doesn't change the value at all. So we have this thing we call the circuit breaker. Right. And that means that if a team for some reason doesn't successfully ship and deploy that piece of work that was shaped and bet on for that period of time. then by default, it's canceled. By default, it's just over. And it didn't happen. As opposed to the traditional default, which is to extend more time to it. Just throwing bad money after bad money after bad money. Right. And that's, or in this case, I guess throwing bad time after bad time. And what we want to do instead is we want to say, look, we shaped this to get very clear about what we were doing and what we're not doing. And also, by the way, when we give work to a team, we leave them alone. So another aspect of betting is that when you make a bet, you honor it. Yes. Right? And so if you bet that these people are going to work on this thing for six weeks, then you leave them alone. You don't pull them away to do something else. You don't interrupt them and say, hey, just this one thing, you know, because not only do you lose the time that you pulled them away for, you lose the momentum that they had built up and you lose the time it takes them to spin up that momentum again. Yeah. And future belief that that commitment will be honored and that they know when they start to work on something. Great point. The credibility too. Credibility. Yeah. Absolutely. So instead we say, look, we did everything we could do to create the best conditions for success. We left the team alone. And at the end of the six weeks, something didn't go the way we thought it was going to. So now the solution is, drop the project, do something else in the next six weeks that we have better confidence in. And then if we still think that thing, if we really wish that, you know, that thing had happened, even though we didn't get it done in the amount of time, then we can have a new conversation, a new betting conversation about, well, actually it would be worth it if we could give it more time. But then before we make that commitment, we should reshape that work because something was wrong. Something was off. We have to be able to debug that. That's where we get into part three of the book where we have the different practices for how a team can be successful when you leave them alone and you give them more autonomy and you task them with self-managing the execution. Here, the number one difference is that we don't give the team tasks. I talk a little bit in the book about the paper shredder. So the traditional approach in scrum teams and stuff like that is that somebody turns the work into tasks and those tasks or stories or cards or whatever, it gets slotted into some kind of a sprint. And then the team is basically pecking away at a queue of things they're supposed to do. And this is sort of the code monkey grunt work type of a scenario. It's not good for morale and it's not good for successfully completing the project because you put the project through a paper shredder. Now you have to hope that all the little strands glue together again and make sense in the end. But you didn't have the full information in the beginning as we talked about. What we're doing instead of that is we're giving the team, instead of giving them tasks, we give them the whole project. They discover the tasks and capture the tasks and track the tasks because they're the ones who actually have their hands down in the system and they have the hood open and they're figuring out what's connected to what and what's actually going to work. And then the final piece there is that in order to talk about progress and to talk about whether we're on the right track or not, we don't look at what's complete and what's incomplete. We look at what's known and what's unknown because it's the unknowns that sink a project. If you have something that's unknown and it's just taking a little longer than you thought, but there's nothing unsolved about it, it's just labor, then no problem. You stay up a little later or you throw an extra day at it or you give it an extra week and everything's fine. If there's something that comes up in the project that doesn't actually have a clear solution or people don't know how to do it, now you're in a completely different risk regime. Now it could be six weeks before they solve it. It could be another 12 weeks before they solve it. It could be unsolvable. It could require ripping up some other foundation somewhere else because of some... interdependency that's supposed to be external to what's being changed in the project. We introduced the language of uphill versus downhill work using this metaphor of the hill chart. Uphill where you can't see where the top is until you get there. You're trying to figure out how do I do this? What's the right approach? How does this fit together? Then for a given piece of work, you reach that point where you're standing at the top of the hill and now you can see down the other side. and that feeling of being able to see down the other side, it's a little bit like, you know, that point when you're assembling the Ikea furniture and there's, you look down and there's like six pieces of wood around and there's exactly eight holes in there and you look in your hand and there's eight screws in your hand and you're like, okay, I know I'm going to be okay. You know what I mean? But you, in the early phases of the project, it's not like that. It's much more unclear. unclear where things are going to go and how things are going to fit together. There are boards everywhere and piles of screws all over the place. Yeah. Yeah. You don't even know where to start. Right. Yeah. I love that metaphor. So I just want to summarize that the phases of your approach, of your process are shaping, bedding, and building. And you all at Basecamp, you go into some detail in the book, but let's just keep it simple here. basically there are six week cycles and then a two week cool down and it carries on in that way. And so, and you go into each of those stages in depth in the book and it's described at a perfect level of detail. I wanna ask you about appetite, which you mentioned just a bit ago, that the way that you all A key differentiator in your process is that during shaping, you determine the appetite first, as opposed to, as you said, starting with the design and then arriving at an estimate. So I think a reasonable critique is that it seems like that could result in delivering less than what the customer really needs. It doesn't matter, Ryan, if you don't have the appetite, if you don't feel like spending three weeks on it, that's what it will take. And so if I don't like the color of my house, I just can't paint a third of it and then call it done because that's what I have the appetite for. So how do you balance, I think, the rational description that you gave for this is why we start with an appetite instead of a design. How do you balance that against, well, sometimes it is going to take that long whether we like it or not. You all talk about that. Yeah, that's a really good question. The difference is at the end of the day, You can't ever really escape estimation because you have to be able to say, is this whatever we came up with? Even let's say in the case where we start purely with an appetite of how much time do we want to spend? And then we come up with some sort of a design for that. We still need to be able to estimate what we designed to see if it's feasible inside of the appetite. So there's no way to get away from estimation. The question, so it's not about estimation is bad. It's about where do we sequence the estimation in our process? So if we start with a design and then we estimate, then the design gets fixed in the beginning. But the thing is that that one design is not the only way to go about solving the problem in the universe. Yes. Right? So the important thing is we want to put ourselves in a situation. where we are able to find more latitude in the design. So I use the example in the book of building a calendar. And the calendar is a good example because I just saw a tweet yesterday about some new calendar app. And this calendar app was talking about how it is the very, very best for figuring out where overlap is between two people's schedules. So it was basically saying, You don't have to email each other anymore to determine who's free when and where the overlap is. That alone is an entire product trying to solve that problem. Now there could be another calendar where it's all about I want to have the best month grid view on an iPad and I want to have the best high fidelity dragging interactions for how I can move something from one day to another. Totally different space. totally different problem set. Now, if we ask ourselves, what is a good calendar? Then a good calendar is all of those things. But then we say, well, strategically, are we a calendar company or not? And when we get asked to build a calendar in Basecamp, we knew from the past that a certain percentage of customers ever used the event and scheduling features that we had in past versions. We had some understanding about what we think is driving people to use Basecamp, what problems it's particularly good at solving, et cetera, et cetera. And based on that, we were saying to ourselves, we don't want to spend six months again building a calendar because we had done that in the past on a prior version of Basecamp. And we believed, this comes back to your question, we believed that it wasn't possible to build a calendar that was any good in under six months. So this is a case where we're looking, the customer is saying, I want a calendar. We're kind of putting an estimate on that and saying, well, I don't think I can do that in less than six months. And then we're looking at our appetite and we're saying, we don't want to spend six months. So we just didn't do it. We just kept not doing it. Then the question kept coming from customers. And so It just kind of bothered me. I didn't feel great about the fact that we weren't doing anything about it. So I wanted to dig in a little bit deeper. And so a couple of us, Chase from our support team helped with this, did some interviews with customers. And what we discovered was that, as is often the case, when they said, we want a calendar, they didn't mean give me a completely full featured alternative to Google Calendar or Apple Calendar or whatever. This isn't what they were asking for. Once we better understood what they were asking for, we had a much more narrow definition of what progress would look like in the circumstance that they were in. And then we were able to say, hmm, you know, there might actually be a smaller version of this. And if we could do this in six weeks instead of six months, we would actually feel good about spending that time. That's an investment we're okay with, right? So then the question became, is there actually a solution in that period of time? And we found one. We found something that we thought was good enough. If you compare it objectively to other calendars by some sort of objective standard, then no, it's not nearly as good as other calendars. But if you compare it to the baseline of what customers had before and what specifically they were struggling with, I think we brought people to a place where they were better off. And we see that in the form of fewer complaints and fewer requests on the subject. Yeah. And I mean, it's well understood and recognized that constraints, having more constraints often leads to a more creative solution anyway. Totally. Yeah. Totally. That's interesting. Okay. That's pretty good. And there will be things that come up where you cannot imagine any other version of the thing and it costs what it costs. You know, that does happen. But that's the exception. Yeah. Most of the things that we do in product development. are where we get to decide what we're going to build and we make the trade-offs and we should be more conscious about what trade-offs we're making and what is really important to this thing and what's not necessary and what's valuable and where we want to spend our time. It just comes back to being more deliberate about what we spend time on. This whole thing about agile is that decision-making got pushed down from leadership to the team. And this is unhealthy. Leadership wants to say yes to everything and then they just push it down to the teams and then the teams are supposed to sprint on it and figure it all out. And what we want to do is we want to take more responsibility at a leadership level for what we're betting on and what we think is strategically valuable. And then we can put the team in a better situation to be successful because they're not constantly crammed with having to build everything and get it done yesterday. That's, yeah. It's a really big thing. Yeah, okay. Man, there's so much other stuff I want to ask about, but I want to follow up on that because a lot of people would say that pushing, or not pushing, allowing that decision-making to go down to the team has actually been a good thing, that that's democratic, inclusive, I feel like I'm part of the company mission, et cetera. And so to take that away and... bring it back up to leadership and say that leadership is going to make those determinations, that might feel like taking away some purpose or autonomy at the developer level. I think this comes from a misunderstanding of how hard development is. It is so hard to make anything work. Making it work is hard. And the programmer's job is is mainly to make it work. And making it work is just really, really difficult and it requires a lot of judgment. So if you are giving the team little fine-grained tasks to do and it's all grunt work because they're just pulling tickets off of a queue, then that is way too far on the end of not enough autonomy. And that's happening in a lot of companies today because of Scrum. If you go the other way and you say everybody on the team needs to be involved in the decision about what's important to the customer and they all need to understand the customer, that's wrong too. Because the team is already tasked with a huge job, which is make it work and figure out how to make it work well and make it make sense. So it's leadership's job to be strategic. It's leadership's job to steer the company and figure out what's worth doing next. And if you have more respect, for how difficult development is and all the little design decisions that have to be made then Then you give the team room to solve all of the all of the sort of they're not even small, but they're the the local the local Decisions that need to be made when you fill in the shape work You give them the boundaries of what to do and what not to do is so like with the calendar. It's less about availability overlap And it's less about high fidelity interaction. And it's more about being able to identify an open space to schedule a resource. Right. Yeah. And I want to follow up on something there too, is respect for how difficult development is for sure. And then respect in the other direction as well. Respect for how difficult leadership is. Exactly. How difficult those decisions are. It takes time and work to figure out what to do. Yes. And this is the thing where Shaping is such an important idea because it means that figuring out what the work is, is work. So if somebody is spending time figuring out what the work is, that's extremely valuable. And today, so many people who are designers or product managers or product owners or whatever, who are supposed to be figuring out what the next feature looks like or whatever, they feel like if they're not building the actual wireframe, or they're not building the view, then they're not doing real work. But the thing is, if you skip the work of shaping, then all of your real work is going to produce waste because you haven't thought enough about what's actually the right thing to do. So leadership, we need to value how hard it is also to work out the concept and talk to customers. and look at what's going on competitively and figure out what is the right thing to do now versus later in the year or maybe never. So that stuff takes time and effort. It's not just arbitrary that you're the boss and therefore you stick your finger in the air and feel the way the wind is blowing and then make a decision today. And I think the more that we frame this in terms of different kinds of work, the more that we can have respect for each other, for the skill set that we bring, and the more that we can set up tracks. in terms of our careers. If I'm a designer and I feel a little bit frustrated, you know, moving this to the left and moving this up down and moving it below, and I feel like, you know, figuring out the proportion and making it look right is not totally satisfying and I'm more curious about is this the right thing to be building? I could start to think of myself as aspiring to do shaping. Now that I have a word for that and some place to learn about that, I can say, oh, what is shaping? Shaping is where I integrate more understanding of business strategy and I integrate a little more knowledge of what's technically feasible and I bring those together and design it at a different level of abstraction. Now if somebody wants to go down that path, they have an option. If somebody doesn't feel like that's where they want to go and they're like, you know what? I actually really enjoy solving that CSS puzzle. and figuring out how to get this thing to render properly and wow look it all plugs together and it all works it's so beautiful then that person can go deeper into that role and we can have mutual respect for the fact that we're doing different kinds of work hey friends this is a good time to pause and let you know that bright and early is brought to you by transistor.fm transistor offers you professional podcast hosting and analytics they host this podcast, and I've said it before, y'all, it just could not be any easier. And if you're listening to this interview with Ryan Singer, chances are pretty good that you have heard of DHH, David Heinemar Hansen, who recently mentioned on Twitter that they are moving the Rework podcast over to... Transistor, the plan is to move to Transistor, says DHH. I feel pretty confident that MI Justin, that's Justin Jackson, and crew are not going to sell out to listener-targeted advertisement schemes. So that's just one reason. If you are thinking about starting a podcast, look no further than Transistor.fm. And if you decide to spin up a podcast with them, let them know that Brian sent you. I want to ask a specific question about something you share in the book. You share this antidote of a time that Basecamp missed a rabbit hole in the shaping process. And none of you were able to find a suitable six-week design solution. And so you abandoned it. How often does that still happen for your team? I'm kind of curious about an acceptable... failure rate for teams who are just starting to implement this to be like, are we still learning? Stuff happens or whoa, we are fully busted and we got to figure this is well out of the range of acceptable. That's a good question. If I just think back right now over the last few years, I only have two projects that come to mind where that happened. Okay. Wow. So that's fairly rare. We are quite well practiced in all of this, you know, so I'm not saying that that should be the standard to measure oneself by. I think the bigger question is, are we more often shipping things that we bet on? Because all it takes, honestly, I've seen this in companies who have been early adopters of ShapeUp. All it takes is one project where Six weeks go by and the thing ships and everyone is really proud of it. And the designers and programmers were more engaged than in the past because they had more latitude and it was shaped so everybody knew kind of how to focus their energy together. Like one of those projects will reset everybody's expectations about what success feels like. You finish one of those projects and you're like, man, that was awesome. And what you want to do is is reproduce that success again. And so from time to time, you're gonna have the next one and then you're gonna flub something. And it's like, oh, we missed that or we didn't understand that or we kind of rushed and we didn't totally shape that, right? And then it doesn't quite go off as well and you're like, oh, well, what did we do? What can we do better next time? Because you only, here's the thing, software companies are wasting so much time and burning so many hours building the wrong things. and dealing with technical debt and all kinds of things that come from working in a way that isn't working, that if once in a while, you know, a six-week project doesn't quite work and you either are on the downhill and you invest another two, three weeks and then you get through it or you identify a major rabbit hole in it and you table it and you do something else and then that next thing ships in six weeks. I mean, think about it, you know. You had a little bit of a rocky six weeks, you take a cool down, you pick off something that's better shaped and then six weeks again, you have this huge success where everybody's like, wow, man, we finished it and we're proud of it and we did it, that was great. I just want to emphasize kind of how big the successes are and then because you have the language and the ability to articulate sort of what went wrong. You can look back at a project that doesn't go right. You can say, was it because of the constraints that we created? Or was it because of the performance of the team that was working within those constraints? Now we can start to untangle the problems when we're doing the troubleshooting to figure out what actually went wrong here. Did we miss something in the concept? Or was there something that we expected the team to execute that turns out that they didn't? did we schedule the wrong person or is there a performance issue we have to figure out or did we just make a bad bet, right? And now you can go back and that feedback loop doesn't just loop back on the same team who kind of had a big committee meeting to figure out what to do and now it's everybody's fault and nobody's fault. Now we can say, that was a shaping issue. Who shaped this? Or that was a betting issue. Who decided that these were the people who were going to do the work on this? Or that was an execution issue. Like what happened with this programming decision, right? And now these times where we get into trouble, they can feel more productive. Yeah, absolutely. So I want to ask a question about bedding and how that works. So just real quickly, like after something has been shaped, it's taken to the bedding table where the shaper... pitches, describes the problem and the solution, and do we want to work on this, etc. You have this line in the book that is basically, what if the pitch was great, but the timing wasn't right? Well, anyone who wants to advocate for it simply tracks it independently and then lobbies for it again six weeks later. That makes perfect sense. That has the feeling of something that just works on a well-functioning team. Like when you say they simply track it independently. That just works on a well-functioning team but would require processes and politics in low-trust teams. Rather, that's my assumption. What are your thoughts? That's an excellent question, and I actually think it's the opposite. Let me say why. When you have a centralized backlog, what happens is somebody... Somebody who is in a position in the company to make bets, so somebody who owns resources, looks at that backlog and they see a menu of possibilities. Maybe we'll do this, maybe we'll do that, maybe we'll do the other thing. Everybody else in the company who's not in a betting position looks at that backlog and sees failure because to them, all of this stuff is supposed to happen. And they haven't done it yet. And it hasn't gotten done. And we suck. Like, how are we ever going to do all this stuff? And look at all the stuff that we haven't gotten done. And not only that, it creates a credibility drain and it creates bad politics. Because what happens is when people can't agree about what to do, what do they say? Put it on the backlog. So everybody learns. that putting it on the backlog actually means we couldn't agree and it means it'll probably never happen. But at the same time, it's on there. So we sort of feel like we're supposed to do it and everybody feels squeezed and uncomfortable and bad about looking at this thing. So actually having a public centralized backlog that everybody can see creates all these bad feelings versus having a private list that a person who's in a position to, to who's responsible to, to, to lobby for a project or who is in a position to actually commit the resources. That's just a useful asset to them. You know, maybe I could do this, maybe I could do that. But when you have a private list, you don't need to have these stupid grooming meetings where everyone is wasting hours, having a debate about how to prioritize stuff. You know, it's a completely different dynamic. So what we want is if. If we've got two or three people, let's say, in a very small company who are sort of responsible for figuring out what to do next, let's say, those people can have some sticky notes on their desk. They could have some stuff scribbled on their whiteboard in their office. They could have a notepad. They could have a little to-do list in their own to-do list app of their choosing. And they don't have to have a grooming meeting. All they do is just scratch something down that they think comes back to the top of their mind like, oh, maybe that next. Then if somebody does some shaping work and pitches a project and then brings it to the betting table like you mentioned and for some reason it's not the right time to do it, that person can keep that at the top of their list of like, okay, I'm going to wait for the right moment and then I'm going to try again. Then when that happens, that work is being held on to somehow by the person who actually cares in a way that doesn't create any sort of a bad feeling among the rest of the company that like, why haven't we done this yet? Because they haven't even heard about it yet, probably, you know, and then, and then when the time does is right, they bring that to the table instead of other things. So it's almost like an automatic, it's like you get grooming for free by decentralizing it because everybody just makes, brings their own top priority to the table. Then when it comes to the table, it's not something on a cue that you're trying to read back what the description of it was. It's something that's in context. There's a person there who's standing for the idea and who has been thinking about it to represent it. It's a completely different dynamic. This is actually the dynamic where you can have more trust because if somebody says, hey, I think we should do X, instead of saying, okay, put it on the backlog, you say, Oh, let's talk about that. I don't really understand that. Or yeah, yeah, we've talked about that in the past. Let's see, maybe one day. And you don't write it down. And by not writing it down in a public place, you don't make a false commitment to anybody. It's more trustworthy to not follow through on a suggestion. It's more trustworthy if you're not actually going to commit to do it, to just write it down on your personal notepad instead of putting it on the wall. Yeah, that's interesting. Yeah. We only have a few minutes left, so I want to ask a question. If you have any advice or tips for very small teams or who are trying to implement ShapeUp because they may be the ones who are doing both the shaping and the bedding and the building because you have these different six-week processes. How would myself and my co-founder both have a six-week process of shaping, getting the pitch ready, pitching it to ourselves, and then betting and building? That's a great question because like you said in the beginning, everybody does everything. It's only when you reach a certain scale that you actually put a formal process into place. I would even say that even the six-week cycle might not be a good idea. when you're just three people starting off. I would say throw away everything that is a sort of a strict process in the book and instead look at the facts of the universe. So shaped work has a different outcome than unshaped work. Making deliberate bets on things gives you more strategic clarity than just kind of chasing after every request that comes up. Looking at what's known and unknown will help you to make better sequencing decisions and manage risk better than looking at what's complete and incomplete. So these are just facts about how things are. If you internalize these facts, then what you can do is you can say, well, before we bet on this work, how do we feel? Do we feel like we know what it is? You say, oh, no, we don't really know. Well, let's not go in blind. and then have this thing and then not be clear what it is once we start, right? So let's shape this a little bit. So then what you do is you just alternate. You take a little break from building something and you spend a little time shaping something, right? And then when something's shaped and you say, okay, this is good enough to go. And it might be more appropriate, you know, for a tiny startup team of three people or something to work without cycles at all and just set arbitrary fixed time boxes and say, our appetite for this thing is three weeks. Yeah. And we shaped it to three weeks and we're going to work on this thing for three weeks and then we're going to go shape something else. Yeah. Yeah. So the small batches and the big batches you talk about in the book, two weeks and six weeks, small teams don't make that a dogma. The value of that is those are numbers that help you set an appetite that you then agree to. A circuit breaker switches in to keep you from continue to like sunk cost fallacy and throwing bad money or bad. time after bad yep but the prescription of two weeks and six weeks as the cycles you think set that aside if you need to if that's what works for your team definitely okay and i'm so glad that you asked that because this um the you know i'm in the lucky position that that when i get invited onto podcasts like this i get these really great questions and then i get to discover things that are missing in the book so so you know i i'm I'm absolutely going to go back to the book and add something about how the different practices are scale dependent, but how the facts are not. If you're a team of three, then six weeks, two weeks isn't necessarily true, but shaping versus unshaped will still give you a good or a bad outcome regardless of how you schedule that in and how you distribute that responsibility among the team. And we're also seeing, I'm seeing companies actually who are on the other end who are really, really, really big, who have hundreds and hundreds of people on the development team in a bigger organization of thousands and they're using ShapeUp and they have similar questions. I mean, different questions, but of the same type in the way that it's saying, hey, I think that this all makes sense, but at my scale, what about XYZ? And they're solving those things as well. So there's definitely something that I want to figure out how to articulate about when you're, it's actually not that complicated. It's just a question of, you know, it's hard when you write a book because you make this big push and you get the thing out and then you say, okay, well. Fortunately, because it's still on the web and it's digital, I can say, all right, I'm going to open the hood again and get in there and make this improvement. I think it'd be worthwhile. I really appreciate the chance to improvise and work out these answers by talking to people and then having these questions and so on. Great. Well, well, thanks for, thanks for coming on. My guest today has been Ryan Singer. You can follow him on Twitter. He is RJS. You can read shape up at basecamp.com slash shape up. And he blogs at feltpresence.com. Ryan, thanks so much for coming on the show. It's great to talk to you. Maybe by the time your listeners read it, it'll have a new section in it about what to do when you're a team of three. Let's see. Good to meet you. All right. Take care. Hey, y'all. I've got a little bit of unexpected bonus content here. As Ryan and I were hanging up and I was thanking him for the call, I mentioned that I had read this book with a friend of mine who runs an agency. And being a contractor myself, my friend and I, we each find ourselves in situations where we are helping our clients build something brand new, starting from nothing and going to something. process works for that sort of for that sort of project and and I asked specifically it does it doesn't seem like you could build base camp 3 with the shape-up process described in the book and and so Ryan just kind of start began to answer that question and I tapped record because he was mentioning yeah this this process won't work exactly as it's described to build something brand new. And so you don't miss much of what he was saying at the beginning. Where it's about to pick up is he's describing how it is just a little bit different as you get things started. So here is that answer. Instead of having shape and then bet and then build, you make a bet for a period of time that we're just going to go explore trying to get a few main features somehow cobbled together. You don't actually shape it. other than a really rough idea of what you want to do. And then the people, the person who you schedule into that time box is mixing in a very blurry, messy way shaping and building. They're going to shape what they're going to do for three days and then they're going to try it and it's not going to work and they're going to shape something else and they're going to try it. So it's going to be shaping and building are going to be totally integrated inside of that exploratory time box. And then as they build, The main method is always saying like done means deployed like get the whole thing Build it to the point that you can ship it and all the way down top to bottom and then move on And but if you're in this R&D mode, you actually want to build everything halfway You want to build it just enough that you can tell that it's all gonna hang together Like you want to build it to the top of the hill Yeah, you want to exactly exactly you want to get more or less to the top of the hill on each main tentpole piece of the product like in order for the product to be what it is It sort of has to do this that and this right Yeah You want to sort of get to the point where you're more or less over the hill on like The data model for this and where that belongs in the interface and how do you navigate to that? And then you reach a point where it's all like sort of shoddy But you're like, you know what this holds together and I know what goes where yeah, then now you have a sort of like really rough map And now you can make bets and shape things to give to other people. Cause you can be like, look, this, this belongs over here. Go build this out. Yeah. Oh yeah, totally. So that's, that's the shift. And I tried to describe that in, um, in that appendix, um, more or less what I just said. And, uh, so if you're trying to build like a base camp three, then, um, what we did was we had, and we're doing it right now with another new product. We've gone through this a few times. Um, we have a sort of the, the, the super team. You know of the most senior people, you have like a designer and a programmer who are super, super senior and they're sort of skunk work style doing this exploratory work where they're trying to figure out like how the main parts hang together. Then as soon as the architecture gets settled, then the ground is firm and now you can go to send other teams in by doing shape, that build. So the difference in giving them the whole Ikea box with no manual and hey, there's two boards and eight screws in there. Exactly. Yep. Yep, totally. And there's still a lot of unknown, but that unknown is more bounded. It's not like everything is unknown. It's like, well, we kind of know it belongs over here and it's more or less using this approach. You know what I mean? And we trust that if we give the team, if we task the team with solving this, like they'll come up with something that works and we're not going to have to scrap it halfway through. Okie dokie. Let's do some closing thoughts here. I thought it was most interesting. Just how Ryan continued to refer back to these basic facts of the universe or basic facts about work or that sort of term that he kept referring back to. Some of those being, you know, things begin as raw ideas. There are going to be some surprises along the way when you try to turn those raw ideas into a usable thing. You don't want to overspec it up front. Some boundaries are required. The process of going from raw idea to something worth betting on, that's a skill. That's work. And, you know, yeah, striking that balance between free-for-all, no-process kids soccer and soul-crushing JIRA user stories. is what they call shaping, like that process of finding the balance. I just thought, I just think it's interesting the way he just continued to refer back to that and the idea to throw away things that are, throw away everything that's a strict process. That the, how did he put that? The practices themselves are scale-dependent, like six-week cycle, two-week cool-down. Those specifics are scale-dependent, but the basic facts about work are not scale-dependent. They are facts. I thought that was pretty fascinating. I just like that line, constraints change the definition of value, of good and bad. kind of referring to some jobs to be done language there around, you know, hot dog and steak are both really good meals to have for dinner, depending upon what your constraints are. That's just a great approach, I think, to keep in mind with all of product design. And that... philosophy is behind why they begin with an appetite and not with a design. And to allow the design, they do not allow the design to determine the time investment required. It's just a fascinating thing. Also, yeah, the notion of bets, making bets with a circuit breaker, that establishes a floor. If you are disciplined, then you cannot lose any more than you place in a single bet. That is so, it's definitely easier said than done, but it makes so much common sense, like how many projects need to go over time and over budget. before we adopt the idea of, hey, look, we are just no longer going to continue to fall victim to sunk costs and one more week. We just need one more week. If you can be disciplined about it, then this idea of betting and under no circumstances do you go over the bet just makes complete sense. And if it... If you get to the end of the timeline and you haven't shipped something and there's no way, well, then the circuit breaker trips and you take the remaining work back to the betting table. And if it's worth investing in, then it continues to move forward. No doubt. Lots of nuances in there. But as a general approach, as a general philosophy, just absolutely makes sense. I, you know, in preparing for this interview, just kind of doing like a little bit of scouring around Twitter and seeing what people were saying about Shape Up or commenting to Ryan, like what were people taking issue with or having some, you know, questions outside of just the mechanics of where do you fit in bugs, which they've, you know, added. That happens at the cool down period. Not just that, but, you know, some other notions about... You know, who does the shaping, who do the shapers answer to, what happens if, you know, consistently like bets are being made and people's preferences are being overlooked, you know, et cetera, et cetera. Just those kinds of things. Those were the bits that were kind of behind a couple of my questions around like this feels, the process that you're describing here feels like it works with a high trust, high talent team. And maybe it doesn't work so well with others. And that's definitely like the pattern that I continue to pick up on the more I was like digging around and finding, you know, what were the bad reviews. Most of them have this like a scent of seeking too much certainty, too much process. And those things, in my opinion, are bad for morale. Or at least, I should say, bad for morale among teams that value creativity over predictability. So both of those are good things. Creativity and predictability are both values. But given an even overstatement, I would value creativity over predictability. Some people, some teams would value predictability even over creativity. And neither of those are bad or good. That's just where do you value two very good things. And so I think something I've been kind of wondering about or saying as I've been talking to other folks about the book, most people who read shape up and then think this would never work for us. they are probably right because it requires a certain type of team where leadership trusts design and development at a high level, and that trust is returned upward similarly, where things will fail, decisions, leadership will make decisions that other folks may disagree with. But if you trust that everybody is doing their best and, you know, and assuming goodwill in every direction, this sort of thing will work and will probably be more fulfilling professionally than strict processes, tasks, checklists, and the paper shredder, as this is referred to in the book. I think... This question about are we shipping things that we bet on being the primary question that you should be asking yourself along the way, that made a ton of sense to me because when the answer is no, like are we shipping things that we bet on? No, on a regular basis at least. that is when you can start to dig into, okay, well, is that because we're not very good at shaping? We need to work on that process. Is it that we're betting on the wrong things? Or are we shaping and betting things appropriately, but we have some issues in our build and our development, design and development process that we need to refine? It feels like to me that that is a good, you know. qualitative measure of a qualitative question that teams can be asking themselves. And so I think finally, the last thing I want to say or the last thought that I had is just around the idea of backlogs. Because I just keep seeing this pop up all over the place, the idea of deleting your backlog, forget about it. Backlogs are bad. They're bad for morale. They make people feel terrible. I think, I guess my opinion here is, yeah, if you and your team are in a position where you just want to highlight the backlog and delete it and move on, cool. If you're in a leadership position and that is not something that your team can do, I think it's at least worth saying out loud and agreeing as a group that the backlog is not a guilt log. This is our way. taking the pressure off of ourselves to store this stuff in our brain like we think that that is that's equally bad that's tiring and so we don't want anyone to be looking at the backlog feeling bad about yourself because you haven't gotten to all of this yet because we haven't shipped it that's not what this is about this is a place where we are cataloging ideas that we are receiving internally and externally because it's hard to remember things And so this is just our way of getting it out. So yeah, that's my short rant on the deleting your backlog issue. I would love to hear what you think about this. about this interview. If you have any thoughts, you can find me on Twitter. I am B-R-H-E-A. That is B as in bulbous, R as in rhombus, H as in hexagon, E as in equilateral, and A as in... angle if you are a founder or executive at a startup and you need some help designing developing or even maybe shaping your product you can feel free to reach out to me at brian at brianray.com or hit me up on twitter i would love to chat and see if there's a way that we can work together If you are listening to this podcast and it adds some value to your week, please just scroll down on your little podcast app there and leave a five-star rating and review. It really helps people to find the show. And as always, thank you so much for listening, and I'll talk to you next week.

Listen in as Ryan Singer and I chat about his new book, “Shape Up”.

Bright & Early
Episode 19
October 2, 2019

★ Episode details: https://share.transistor.fm/s/90c660ca
★ Additional episodes: https://brianrhea.com