Ryan Singer - Shape Up - How Basecamp Does Product Management

Welcome back for the last session of today. What a day it has been! So many interesting sessions and everything is coming to an end, isn't it? Even this crisis will come to an end, hopefully very quickly. But today we have something special at the end of this event. Basecamp is a company that has been very interesting to me because they have this ability of producing very simple products that are used by a lot of people and we are actually using this product Basecamp and a few others and it's quite interesting to see how they are doing this. So we have with us Ryan Singer who has been for 16 years at Basecamp Today he's focusing on strategy and he also has a book called Shape Up, Stop Running in Circles and Ship Work That Matters, which is available online for free. So it's actually quite interesting to have Ryan with us. Welcome Ryan, you have the stage. Hey, thanks for having me. It's nice to be here. I'd like to talk today a little bit about Shape Up. but I won't just step through everything that's in the book because you can read that for yourself. So the book is actually online at basecamp.com slash shapeup. And the subject is how do we actually go about doing product development and what are the different phases that we go through? to design something, to go from having just an idea about maybe what we should do next to in the end actually shipping something which is a meaningful improvement, which is a meaningful change that gets us where we want to go. And this is something that we have been working on for a very long time. In the introduction, you heard I've been at Basecamp before. Actually, I think now As of July, 17 years I've been there. And I learned a lot of the tricks and the practices that we use for doing product development from Jason and David, the two founders. And for a long time, we were doing very well as a very small team. First three, four people, then five people. And we had a way of going about... making decisions and scheduling projects and kind of keeping ourselves focused that we could do with each other, but we didn't know how to explain to other people. And this came to our attention after we started to grow, because when you're small, you know, everybody spends a lot of time with each other. There's a lot of exchange between the small group. And things get passed on naturally, right? But then once you start to get a little bit bigger, I mean, once we were, I mean, I think more than 10 years, 12, 14 years into the growth of the company, we reached a point where we had brought on a few more designers and programmers. And actually, it wasn't so easy anymore to explain what we were doing. This was a task that I kind of set for myself to try and actually explain more clearly how it is that we were working. And I was in a good position to do this because I started off as a designer. So I understood the front end part of the work. And then I also learned programming. So I also understood the back end. And then I moved into a strategy role, which is actually bringing these two things together to understand what are we trying to do? What's technically possible? and what's valuable for the customer and how do we bring these things together to design a project. And after some years had gone by of trying to articulate, explain, spell out the way that we had been working for so many years, we actually reached a point where we were quite successful with this internally. We were able to now teach the new people who were coming into the company our way of working and we had a good kind of balance with this and it was successful. And then one day Jason said to me, he said, look, it seems like we've managed to figure this out internally. Now you should go write a book to explain it to other companies. And I thought, okay, this is, sounds like a good idea. And usually Jason has this special ability. He can kind of, you know, feel which what's going on in the world and what is the right timing for things. And so I trusted his intuition about that. But I had no idea how to begin. And especially I had no idea kind of how to make this. Why would this be important to other people? And why should they care about our development process? And why does it matter? Right. And so actually, rather than first writing the book, I held a workshop. And it was a one day workshop. And I invited a small set of people who were leading product. in their companies sometimes it was the founder and sometimes it was uh someone who is in more of a product management role or a senior design role um and uh i talked to them for a day about how we did product and in the end i interviewed everybody who came and and and asked them a lot of questions about what was happening in their company what were they struggling with and actually why were they trying to learn to do things in a different way and what i discovered was that There were two big reasons why people wanted to change the way that they were doing product development and the processes that they used inside of their teams. The first one was that they had reached a point where they remembered in the very beginning of the company that they could come up with an idea, quickly build it, and then release it, and then move on and do something else. But somehow things changed. And now it seemed like projects would go on and on and on and take much too long. And there wasn't a clear ending in sight. And there wasn't this feeling of just like taking on the work and doing it and finishing it and releasing it and moving on to the next thing. So this question of how long it takes to deliver was a problem. Things were taking too long. The other problem that was coming up was a lot of people who were in a leadership position working on a product. actually felt that they didn't have very much time to think about what they should do next. As people working on a product, we often know that we should be somehow having a vision or we should have a strategy. We should somehow be ahead of the teams to plan what is important and what we should work on next. But very often what happens is we're spending so much time. in meetings and trying to deal with small details and scheduling things that we actually don't have any of this space to think and be strategic and focus on the direction we want to go in. So this is also something that people were struggling with. And actually this process that we devised that we call ShapeUp is meant to solve both of these. And indeed for us and for quite a few companies now, it is solving both of these. And how? I'd like to give you a few of the key points so that you have a feeling for what's important. And then from having these few key points and some intuition, then you can go to the book and you can fill in all the details. So the first kind of really big point is actually how we think about scheduling and how we think about time. Very often in most software companies today, you'll see that there's some kind of structure where people work in sprints like maybe two weeks at a time. And what happens is there's a process of sort of saying, okay, what's the next thing that we need to do to ship? And then lining up some work and then working two weeks. And then two weeks goes by and the sprint is over. And then the question is, okay, well, what do we need to do next? And then another two weeks goes by. And then what do we have to do next? And another two weeks and another two weeks. And there's actually no clear ending point. And also what's happening is there's usually some design concept of what should be built. And then we say, we ask the programmers and the technical people, can you please give an estimate for how long this will take? So we actually aren't working this way. We're working in a very different way. So rather than making an estimate, which turns out to be wrong, right? And then we spend more time and more time. And rather than scheduling these small bites of two weeks and two weeks and two weeks, what we do instead is we set a very hard deadline. We set a finish line where we say, we actually only allow ourselves six weeks. And at the end of the six weeks, we have to be finished. Something has to ship. We have to be done. And we're not going to just keep extending and extending and extending. And in order to do this, we don't actually estimate the work. So we don't design the work and then create an estimate and then from there make some schedule. Instead, actually, we do the opposite. We start with the time that we want to spend strategically. We ask ourselves, What is a valuable, meaningful amount of time to spend on this work so that when this time is over, we can look at each other and say, this was a good idea. This was time well spent. I'm happy that we spent this time on this project and now we'll do something else. And instead of an estimate, we call this the appetite. So the appetite is how much time we want to spend. And so we define for ourselves, given the value of this project, what's it worth? maybe for some small improvement, it's only worth two weeks. And if it takes longer than two weeks, we wouldn't want to do it. And then for some bigger piece of functionality or a new feature or a new improvement, it's worth six weeks. And we say, if this takes six weeks and at the end of six weeks, we'll be happy, then this is what we'll spend. So we start with this time box and then given the amount of time, then the design comes second. So we say, what could we design? What could we come up with that fits into this box, which is totally different? It's completely opposite process. And this is what's sometimes called by some of the old agile people, you know, the original agile folks. And like, for example, Kent Beck and his work in extreme programming, they talk about fixed time variable scope. And this is what we're doing. So we start with a time box. And then the question is, can we come up with something that's doable within this period of time? And this work that we do is what we call shaping. We don't actually design high fidelity mockups. We don't create pixel perfect designs. We don't create wireframes. If we try to specify every small detail. of what needs to be there in the project. And then we also try to give a hard deadline. And we say it must be finished before this date, otherwise it's canceled. We really make a very hard deadline. We call this the circuit breaker. This is something you can see in detail in the book. Basically, we cannot have a fixed deadline and at the same time specify every detail. Because when it comes time to actually implement all of those small details, there will be surprises. Either we won't like the real results when we see it actually in code, we'll say, ah, it's not quite what I thought it was going to be now that I'm really clicking through it. But even more often, there are often technical problems that we couldn't foresee. You know, there is what we call opacity. There's an inability to see through. all of the different details in the code that we're going to have to handle in advance. We can't see it from the beginning. So instead, we specify the work at the right level of abstraction. If we only specify the work in the level of words, if we say, let's go build a dashboard, right? And then we schedule six weeks to build the dashboard. Nobody knows what a dashboard is. So what happens is the teams have to spend all kinds of time doing so-called discovery, which actually means they don't know what to do. And if the teams don't know what to do, we cannot have a clear expectation that they're going to succeed. And we cannot have an expectation about what we are going to actually ship and get out of the end of this six-week time. On the other hand, if we go in the other extreme, and rather than being too abstract and just saying, build a dashboard, if we actually draw every small detail down to the pixel perfect, then there's no room for the teams to make adjustments to the scope. As they learn what is easy to do and what's difficult to do, and as all kinds of unexpected details come up, unexpected problems come up, edge cases come up, all kinds of things that nobody could anticipate, when all of this unexpected discovered work appears, in the middle of the cycle there won't be any chance to react to that because everything has already been frozen or let's say uh etched in stone from the beginning of the project so what we do is we shape the work at a middle level of abstraction and i can actually give you a short example of what that looks like uh if if we look at my uh web browser here and uh you know maybe uh the host can can can jump in and tell me if there's some problem if you don't see it or something like that um i i'll give you an example of what this level of work looks like so first we often use a strategy which is called something called breadboarding this is where we can actually define what should happen so this is doing design work about what should happen in the project but there's no wireframe there's no drawings There's no colors, there's no fonts, there's no question of what's on the left or the right or what's above or below. Instead, we're focusing on what's really important, the actual idea and the pieces of functionality that need to be there, the connections between these pieces of functionality and the affordances, the UI elements, the pieces of the interface that are going to be exposed that need to be there that are going to enable this to happen. So here we have a kind of shorthand where we can say on the invoice screen, there's going to be a new affordance to turn on the auto pay, which is like a recurring payment. And then on the setup auto pay, we'll have the possibility to enter credit card fields. We want to have the logo of the financial institution and then we'll submit. And when we submit, we'll go to a confirm screen, which will provide a thank you message. Anybody who sees this very short description of the work understands the idea. And we can even have technical conversations about what is the right thing to do. So maybe we start to have some questions about, oh, maybe there should also be a possibility to pay the balance that's already there. Or maybe we start to say, oh, actually, let's change this. And in addition to credit card fields, let's have an ACH field so we can, let's say, do a bank transfer instead of a credit card payment. These are the types of conversations that we start to have. But notice how we can have these conversations without lots of small design decisions about what goes on the top and what goes on the bottom and should there be a sidebar or not, the types of things that you see in a wireframe. Sometimes we do need to have a kind of visual idea of what the work is. And in that case, then we use what we call a fat marker sketch. So this is where we are talking through an idea for a feature, but we force ourselves to be very, very rough. so that we cannot get too far into the details. And then this allows the ones who are doing the actual work to decide on all of those details when they get into it. So here's one last example. If we look at, here's an example of a design that we came up with for a calendar. And here we have actually some very important decisions that affect the scope of the project. We have two months side by side. A dot indicates if there's an event happening inside of that day. And if you click on that day, then you see an agenda view that shows you the events that appeared as dots here, right? And this was as far as we went in terms of specifying the work up front. But then inside of the six-week cycle, the team worked out all kinds of small details for how to actually spell this out. Okay. I'm going to switch back. That's it. For the host, you can turn off the screen sharing. That's all I wanted to share with you there. So this is the level of fidelity, the level of concreteness that we use in the shaping process. And then something very important. When we begin the six-week cycle, we do this shaping before. And then once we get to a solution that we think looks like a good idea. And it not only looks like a good idea, but we actually understand the moving parts and the different pieces of the solution. And we can also ask ourselves, are there any major technical unknowns? Are there any design unknowns? Are there things here that need to be solved that might not be solvable or that the teams might get stuck on, right? And we can address all of these things until we get to a point where we have a piece of work. that it feels like it's very clear direction and also low risk. Once we get to this point, then we can do what we call making a bet. And a bet is where we schedule this work for six weeks and only this work. So the teams are going to build this and nothing else. They're not going to be interrupted and asked to do something else. So this means that the leadership, when we really talk about product leadership, It means that the ones who actually can control people's time. So really at the executive level, say, this is what's important. This piece of work is what we want to build next. And we are going to dedicate the time. We're going to take the risk to do only this for the next, let's say, six weeks. And if at the end of the six weeks, this doesn't ship, we have what we call the circuit breaker, which means the project is actually canceled. no automatic extensions. This creates a kind of healthy pressure where we give the teams a pressure that they have to find a way to execute this project that was shaped within the time that they have. So the designers and the programmers are working together and they're managing themselves. It's a self-managing team. We're combining pressure that makes them make decisions and trade-offs. but then at the same time because they're self-managing they have freedom to decide for themselves when should they talk to each other when do they need to be alone to to do the design of the programming work and how will they coordinate with each other to uh to integrate and get this work done this gives us two big wonderful things the first thing we get is we actually get to successfully ship our projects uh reliably because we shaped it more clearly in the beginning, so we have set clearer expectations. And then we've given the teams the room to make their own decisions and to make adjustments to the details as surprises come up. And they have this firm deadline that at the end of the six weeks, they really have to be finished because we're not going to extend the project. All of this together creates very good conditions for the team to successfully make decisions, make trade-offs, cut things from the scope that are unnecessary, and actually ship at the end of the six weeks. This solves the problem of projects that never end or projects that take too long. And it gets us back to a point where we have a healthy rhythm of shipping, shipping, shipping, six weeks at a time. So we have six weeks, two weeks break, cool down, and then six weeks again. And you'll see the details in the book. The other thing that we get out of this is once the teams have clearer direction because of the shaping, and when the teams are managing themselves, instead of having some kind of a product manager trying to tell them, what are you doing today? And what are you doing tomorrow? And are you working on the right things? When we don't need any of this micromanaging anymore, what happens is we can give the team the work. We give them the time box. they have the six weeks, and then because they are managing themselves inside of this time, and they have all of the clear boundaries that they need and the control that they need to be successful, it means that those of us who are working on a leadership level or on a more of a product management level can step away during the six weeks, and we can actually think about something else. If we're not in a meeting every two weeks to try and decide what the next sprint is, If we're not having a daily stand-up, which we don't need with the teams to check on how they're doing, if we don't need to constantly schedule who is working on what, then this space opens up and this time opens up where we can actually start to think about what is next. So this opens up the possibility for us to do the work that we need to, let's say, talk to customers. right, to do interviews to understand the demand better, or to look at data about how the product is being used and do some modeling to actually understand what's happening there, or to have some strategic conversations with the other leadership about what's important and where do we want to go next in terms of sort of what, you know, our vision. It takes time to understand the market. It takes work. to actually do the research and come up with a meaningfully true model of what customers are trying to do and who they are and what situations they are in when they shop for us. What are our actual competitors based on not just looking at what we think our product category is from a supply side, but actually getting into the demand side of learning. When people start to look and shop for our product, what other alternatives do they consider? What do they switch to when they start using us? And when they leave us, who do they start to use instead and why? This type of work takes time. And when we can dedicate that time, because the teams are able to build and execute without us hovering over them, this means that our ability to work strategically goes much deeper. And we also need this time to turn this modeling, this questioning, this researching, all of this work that we do to understand the business and understand the market, we also need to turn this into new projects to build. And so this high-level design work that we call shaping, it happens outside of the cycle. And it requires some dedicated time from someone who has some senior design expertise. And it requires some input from the technical experts. And then it also requires that we take the work that we shape and we take it to what we call the betting table. And we have a conversation with the leadership, not with everybody in the company, some big, big meeting about what should we do next, a very small meeting with the people who actually run the company to say, of these different projects that we have shaped, which one is important? Which one is valuable? What do we want to dedicate our time to? And then we really become very powerful in our ability to, in a focused way, steer the company and steer the product in the direction that we want it to go. So this opens up, I think, for us some new questions about, I think, the title of the conference is product leadership, right? This raises questions for us about what does it mean to do product leadership and what does it mean to lead? It doesn't mean that we sit there looking at a calendar and a schedule every day. It doesn't mean that we are moving things around on some Kanban every day, trying to fit together. Oh, the programmer is free tomorrow, but the design is waiting for the programmer and basically trying to manage everyone's time. No, it means that we should be managing the work. Instead of thinking about time, we should be thinking about what work is meaningful. And so it means that the role of a product manager should shift from managing the people's time and what are they all doing to creating the conditions for the people to manage themselves. And so our focus on management should actually be reduced. The need for the product manager, actually at Basecamp, we don't even have product managers because the teams manage themselves. And then the responsibility of the product leadership, it shifts to these two other things, shaping and bedding. We have to do the high-level design work to outline what is the next project so the teams don't have to do discovery. but we actually are specifying the important things of what they're going to do next. That's the shaping. And this means that the product manager actually needs to have some expertise. It's not just project management, but it's actually high-level design. And then we also have this bedding work, which is working together with the stakeholders, with the people who actually are owning the resources and making the decisions about how we spend time. at a high level in the business and making decisions together about which project happens next and being more deliberate about how we spend our time okay so that's my 30 minutes and uh those are kind of the big ideas and uh the big things i wanted to share with you uh and uh you know you can go to the book uh basecamp.com shape up to see all the details and to learn more about this and i think we have time for a few questions there i am so this was very interesting uh I'm glad that you mentioned the X-Team programming because it sounds very inspired by X-Team programming actually. We were very inspired by all of Kent Beck's work and Martin Fowler and that scene, absolutely. Yeah, that idea of having kind of a time box where you do everything and you deliver and that comes from there. One thing that's interesting for me is, so what happens And how often happens that you go through the six weeks and you deliver something that you decide to drop or you say that's not actually useful? It happens from time to time, but actually it's very rare. So I think it's good to separate two different types of problems here. One problem is they built exactly what we shaped, but then in the end we decided it's not what we want, right? versus we shaped it but they didn't manage to build, they didn't succeed in building it. They ran out of time or something went wrong, right? Actually, I think from the perspective of most software companies, most software companies are not able to shape something and then ship it in the amount of time that they said they would. Usually the projects take much longer or they have all kinds of problems along the way that they didn't expect. Actually, I see this being able to ship what you shaped as a big victory. Because if you have this ability to repeatedly decide I want to do it and then do it, it means now that if you don't like what you got in the end, it just means that this is a feedback onto the shaping process. And it means, okay, we need to think more clearly about what it is that we want. But we've actually solved this problem of being able to ship. And so this is – when we're working on a completely new product and we don't know what we want, we do often go through some cycles where we build something and then throw it away. But nobody perceives this as a failure because this is in the very early stage of a new product. However, when we have a product that's already released and we come up with an improvement, we are very often – quite clear about why we want this improvement and we shape it and then we look at it very clearly and we take the bet quite seriously. We don't want to spend this six weeks on it unless it's actually valuable, you know? And so for us, it's really 90% or more of the case that we ship exactly what it is that we spent the time on. Sometimes the form and the details of it will change in the course of the six weeks because the teams have this flexibility. to make these small adjustments. But the vast majority of the time, these projects do ship. And then when we don't, it's usually because we got lazy and then we didn't actually shape it very well. We ran out of time and we thought, oh, we'll just figure it out as we go. And then, of course, it doesn't work. So we had to learn this lesson a few times. We still make this mistake sometimes. And then also sometimes there can be a performance issue where you have some programmer or designer and actually... There's some problem in their work that prevented the project from shipping. And then we have to do some performance work with some individuals in order to figure out how to prevent that from happening again. But the important thing is this time box, it creates those feedback loops. If we can always just keep adding more and more time, then we never have to face the fact that something was going wrong. And this is very, very helpful for us. Yes, it's a great discipline, but I also wonder how you manage to keep this because it's very tempting once you build two thirds of something and say, oh, we just need another week, we just need another week. But I guess this is in the discipline of the company to avoid that, right? Well, it's actually, I think, in the structure of the process, because if you take an undisciplined person, But you give them the freedom to make trade-offs and you give them a very firm deadline. They actually have to make choices. This becomes their job to make choices. And today, for most people who are doing programming, no one is telling them it's your job to make choices. Everyone is telling them it's your job to do the ticket and to finish it in the time that you estimate. which is very different you know we're giving people more latitude but we're giving them the responsibility and saying you need to make judgments and this is part of your uh your work now this is you actually spend time on on making these decisions uh one last question from me because before we move to there are two questions positive How do you deal with the graphical design? Do developers already know how to? Do they have kind of the guidelines for design? Or does it happen that they build a feature and it doesn't quite fit the existing design? How does this work? Yeah. So I showed an example of the level of design we do in the shaping. When we have that level of understanding going into the project, already... From day one, the programmers can see that there's some modeling that they have to do. Like, ah, okay, we're going to need some screen that's going to have some button for this and some field for that. They don't know what the actual design is, but they have enough information about the actual structure, the network, the relationships between the moving parts, that they can already begin to look into the existing code and start to prototype some. you know, database schema or model or controller or whatever it is that they need to start to figure out how to wire this together. At the same time that the programmer for the first few days is looking at these early questions, the designer is actually providing a high fidelity design for some small piece. So they can say for this specific screen, now here is the design for this. And then rather than providing all of the design at once, and then doing all of the programming afterward, we have like some of the foundation is there of the basic modeling, and then a small piece of high fidelity design is there, and then the programmers can plug this design into this early wiring, right? And then also the designers, they don't actually have to provide every perfect detail at one time. They can give something that's a little bit closer to a wireframe to the programmers who can then plug this in. And then they can actually say, ah, you know, I have a better idea for the copywriting. And then a week later, provide different copywriting and have this changed, right? It doesn't all have to happen at once. So what we see is a kind of gradual weaving together of the design and the programming throughout the six weeks rather than all of the design at once and then the programmers just implement it. Yeah. All right, so let's move to the two questions. What are your current challenges with this model of product management and how are you considering to change it if you are from Maria? So for us, we actually don't have any challenges. This is a solved problem. We've been working now, I mean, we've been working using different pieces of this method for some of them go all the way back to 17 years. And even the more kind of novel aspects, for example, the hill chart is a new piece of this method. But even that we've been using for years now. So actually for us, this is totally a settled matter. The thing that I'm struggling with, where I'm learning a lot, is how this method applies to people who have slightly different problems than we do. So for people who have different difficulties because of legacy code, technical debt or people who have different relationships with vendors or different dependencies on third parties for their projects there's a lot of areas where it's unclear kind of where the edge of the standard shape-up practice that I've described in the book is and how to adapt it for these different situations so this is the main area for me right now is actually I have a lot of exchange with other teams who are in slightly different environments because I'm actually very confident that the basic principles are general but the specific practices and and need to be spelled out to help people in different situations so this is something I'm really enjoying but also it's a big challenge right so I'm learning a lot with that as people try to apply the book to their to their own companies Yeah, I'm familiar with these challenges. We do a lot of transformations in organizations, digital transformations or moving towards agility. I'm curious to actually read the book and compare notes. That would be very interesting. Second question. Do you consider this model compatible with the increased scope demanded post-start by a client? Absolutely. We have the exact same problems with clients as we do with ourselves. We would like to make some kind of a commitment to each other that something will be done by a certain day. And then how do we actually fulfill that? If we promise the client every small detail that they ask for in the beginning, we'll never finish on time. And anyway, it won't be what we wanted in the end. And so this fixed time variable scope actually is the way. We have to find a way to agree upon the essential elements. but allow room for the details to change. And this is going to allow us to deliver work to the client on time. And if we can deliver work to the client on time that is closer to the spirit of what they need and not necessarily signing off on every small detail, it allows us to build a relationship of trust where over time we can arrive at what they want. through a few cycles one after the other. And it creates a situation where we all have lower risk and we actually have clearer expectations. But we have to work at a different level of abstraction in order to do that. We actually should be shaping the work together with the client and shape the expectations at the right level of abstraction and say, look, based on the reality of software development, this is how far I can promise you in terms of details. Right and then let's make a commitment that's long enough to get somewhere meaningful But short enough that it's not too big of a risk for either of us right and then we can come together at the end of the six weeks and say How happy are you with how we delivered on the on the things that we agreed were important and this can build a lot of trust and And now you have a good relationship into the future with this client One thing that I imagine can be difficult in this situation is you seem to have grown an intuition of what fits into six weeks, which is not easy to transfer usually to other people. So when you are talking about other teams or about clients, this may be a challenge. I don't know if you've noticed this. I actually, yeah, of course. But I don't think it's as much of a black art as people imagine. what we're doing actually is we're really cutting away the biggest unknowns and the highest risk. We're not trying to be perfect in our estimates. We never try to do this. What we do is we say, what are the things that we actually understand about the thing that we're building? If this is something that we have built in the past and we understand all of the relationships between the parts, then we can reasonably say that these three or four elements can be combined inside of a six-week box. And if we don't commit too far to all the little details, then we're quite sure we'll manage. It's like if you're cooking dinner, if you invite some guests over for dinner and you make some dinner, some meal that you've made before, you don't have to be worried that you won't manage to have the food ready when they arrive. But if you decide to make some exotic... you know, Indian dish that you never made before or cook some complicated cake or something and you never did it before, you might discover that you're having a lot of stress in the last moment because of this novelty, right? And then when it comes to these unknowns of something that we've never made before, the things that actually cause estimates to not be wrong by a little bit, but to really be wrong is interdependencies that we couldn't understand. either interdependencies between the new pieces that we're building or interdependencies in the code base that we already have. And there's actually quite a lot of, we could call it like science, it's not actually a black art, to looking at these interdependencies and then addressing these in the shaping work or removing them in the shaping work rather than just hoping that the teams will solve them. And this is what I address. in, I believe it's chapter five of the book on risks and rabbit holes. We talk quite a lot about this. This is something that we can manage very deliberately. Okay, Ryan, this has been excellent. Thanks a lot for participating and for giving this talk. You got very good feedback. Somebody is saying, Anka, thank you so much for this approach inside. A truly interesting perspective. Looking forward to reading more in your book. So for everybody, get the book is free. I can't wait to read it. I didn't actually know that there was another book coming from Basecamp. I tend to follow those. So it's very interesting. All right. I will now move to... Thanks a lot. Thank you. And I'd just like to say, if anyone has questions or would like to follow up with me, you can find me on Twitter at RJS. And then, you know, I'd like to hear some feedback or if you have some follow up questions, we can talk there. OK, thank you. All right. Thanks a lot.

This is a talk recorded for Product Leaders conference, on 7 July 2020. The descriptions below were valid at the point of recording.

About Ryan Singer

Ryan Singer has worked on all levels of the software stack, from UI design to back-end programming to strategy.

Through over 16 years at Basecamp he has designed features used by millions while also inventing the very processes their teams use to design, develop and ship the right things.

In his current role, he’s focused on strategy. That means understanding what Basecamp customers are trying to do so the team builds the right things and makes the product more coherent over time.

About Shape Up

Ryan will explain how Basecamp has been able to ship meaningful improvements and entire new products — repeatedly, and on schedule! — for over 16 years. He’ll draw on practices and principles from his book Shape Up: Stop Running in Circles and Ship Work that Matters. In particular, he’ll focus on what product leadership looks like at Basecamp and how they integrate design, technical and business capabilities at each phase of a project. 


Alex Bolboaca is a programmer, CTO, author, trainer and coach at Mozaic Works.

Mozaic Works provides high quality, customized training, coaching, and advice for companies who want to improve their effectiveness in the market, mainly through the use of modern leadership and technical practices. Check out our offer and ask us questions at https://mozaicworks.com.

Think. Design. Work Smart.