How We Work #1: "Expect to be Done"

Hi, I'm Ryan Singer. I do product strategy at Basecamp. This is the first in a series of informal videos where I want to walk through how it is that we work on the product at Basecamp. So how do we pick off the work that we're going to do? How do we actually budget it? How do we build it? And most importantly, how do we release what we wanted to release when we wanted to release it? So how do we kind of regularly build what we intended to build and ship it when we intended to ship it? This is something that we've turned into kind of an art form over the last 15 years. It's something that we've always paid a lot of attention to. And now we can look back and say that we really have a track record over all these years of repeatedly building new features and useful improvements to the product and then shipping, shipping, shipping all the time like that. So this is something that we've really worked out. And we have a lot of specific practices. that we've been able to spell out that allow us to do this. And that's kind of what's drawn out on this map here. So what I want to do over the course of these videos is take you through a lot of these ideas and show you kind of what specifically are we doing that enables us to regularly ship like this. In this video, I'm going to start off by kind of taking a tour of the main areas, and then we'll spend most of our time in the budgeting section. And then after you have a sense of the basic structure of how we work, then we can move on to talk about some of the very unique and different things that we're doing that specifically allow us to regularly build what we want to do and ship when we want to ship. So to start us off, let's go here in the upper right to the strategy section. So strategy is about what is it that we want to build. what is kind of the right thing to do for the product and what are the things that are important and not important and how do we make decisions about when's the right time to do things so this is all about like what should we do and Based on our understanding of what's meaningful and what matters then we're going to shape up specific projects So we're going to define the work and the main way that this happens is with what we call a pitch So a pitch is some idea about what to do, and it always has two parts. So there's going to be a problem in the pitch, and there's also going to be a solution. Now, if we don't have a problem, then we can't judge the value. So we have to have some understanding of the situation or the circumstance where this is going to be useful. And then at the same time, if we only have a problem and we don't have a solution, then we're not going to be able to evaluate this in terms of cost or time or effort or impact on the rest of the product or that sort of a thing. So there's got to be both there. And both the sort of strategy work and the pitching, these are things that are happening on an ongoing basis. So there's not kind of a special moment to do strategy or a special moment to make a pitch. These are happening all the time. And the default response whenever an idea comes up or a pitch is made is no. So we say here, no, maybe later. So the idea is, There's no backlog. There's no growing giant to-do list of things that we have to do. Everything that comes up is just an idea. And when it comes time for us to budget some work into a cycle, then we can consider the things that have come up. But other than that, there's no commitments. We are free, which is a good place to be. And actually, we're going to talk a little bit later about how that's a luxury. And it only happens because... of the discipline that we've taken to make sure that everything that we've built in the past is done, that we don't have half-finished work lying around, we don't have kind of, you know, debt lying around from things that we didn't finish. So we put ourselves consciously in the situation where we can say no and then choose from a clean slate. That's something we'll get into a little bit more later. So we've got a variety of ideas for what we can work on, and those are by default no, And then when it comes time to start a new cycle of work, then we're going to go into a budgeting process. So the way that we work is in six-week cycles. And now this is specific to the product teams. We have other teams that aren't working inside the cycle format. So we've got six-week cycles, and in between each six-week cycle is a two-week kind of a cool-down period. So that's time to sweep up any remaining things from the cycle, and it's also time for this budgeting process to happen where we can figure out what's going to go into the next cycle. And so that goes into a cycle plan. And the cycle plan is basically broken up into two categories. We have what we call big batch and small batch work. So at Basecamp, with the size we are, we have two product teams that can work in any cycle and a team is made up of a ui designer one or two programmers and and one or two qa people and then they're self-managed so there's no kind of dedicated management person who's part of that team and uh that's actually mentioned here as integrated teams so it's not just an engineering team it's it's all together so uh what's the big batch and small batch so big batch is a project in the cycle plan that is going to take one team the entire six weeks. And then small batch is a handful of projects that are all smaller, so maybe things that are one week, maybe maximum two weeks, and those are things that are kind of given to the other team as a bundle, and they're going to pick those off and work on those one by one. throughout the cycle. So this allows us to kind of make progress on one big thing like a new feature and it also allows us to make refinements to things that we did in the past or to maybe solve kind of a long-running deeper bug that might need like a week or longer to fix that kind of a thing. So smaller improvements. So that's big batch and small batch. And then these are given to, like I said, the two teams which are integrated. Now it's probably worth pointing out that that this integration isn't only happening at the level of a team, that also when the budgeting process happens and we're reviewing pitches, the group of people who are reviewing the pitches are also kind of an integration. So we've got somebody who represents engineering and we've got somebody who's looking at it from a product kind of UI, UX point of view. We've got a business point of view there in terms of if this is the right thing to be doing. All those are at the table when the budgeting happens so you might have heard of other companies where there's there's an engineering team engineering is picking off and building work and then that just kind of comes downstream to to design or to marketing and everybody they just kind of have to have to deal with what was made and figure out what to do with it so this is a different situation so uh everybody everybody from from all sides is kind of part of the decision and is is informed uh when this is happening so the work is getting budgeted into the cycle plan big batch small batch integrated teams and then it's time to to go into the cycle and and do the work so that takes us over here inside the cycle now there's a lot of interesting things that we're going to be able to to talk about here as we go forward but there's one essential point and this is the first of the big three kind of unique things that we do that we need to talk about first here uh and that's this this bold circle that says expect to be done so so for us done is a magic word it's a very it's almost like a sacred word around here um it's what enables like i said before it enables us to have that freedom to start from a clean slate every time a new cycle starts because we don't have leftover stuff hanging around and the the notion here is we're these are not sprints this is not just some kind of uh cycling incrementally to to keep biting off pieces of something no this is a piece of work that we expect to be able to finish in six weeks and the team has the understanding as they go through the whole as they go through the six weeks that they're going to have to make choices they're going to have to make trade-offs they're going to have to figure out how to actually get this thing done so the understanding is that when the end of the six weeks comes either this is going to ship Or if something goes wrong, it's not automatically going to get more time. There's no guarantee of, let's say, like an extension of the cycle. So this is very different from what you might be familiar with if you know about things like two-week sprints that some companies do, which in our point of view is just like a kind of madness to work two weeks at a time like that. So the team has an understanding that this needs to be done. If it doesn't happen, it doesn't happen. And the thing is that we've budgeted six weeks, let's say, for this project, and it might not be worth 12 weeks or more. It might not be worth eight weeks, right? So if it's worth six weeks, then it gets six weeks, and we're going to see what happens. That's basically a bet that we're making. There are some cases where a project can take longer than one cycle. So sometimes... There's deeper work or a new feature that just has too many moving parts, and we can't come up with a way to scope it down to one six-week project. So there are cases where we've had a project that took two cycles in a row. But even in that case, we scoped off the work in such a way that the work that was defined for this first cycle is expected to be done. And then at the end, when the next cycle starts, it's just the other parts of the work. that were kind of scoped off separately or they were orthogonal to the parts of the first. And then we're going to integrate and ship all that together at the end of the second cycle. So that's happened occasionally. But the main case is one feature, six weeks, and it's going to be done. Now, this is quite an expectation to say this is going to be completely finished and released to customers at the end of the six weeks. And if we weren't doing some other things differently, it might not be a fair thing to ask a team to do but there are a couple very important things that we're doing that enable the teams to actually do that and and plan to be finished at the end of the six weeks and we will start to get into those uh in the next video

Ryan Singer, Basecamp's head of Product Strategy, starts out a multi-part series by talking about how we decide what to work on every 6 weeks. From the strategy, to pitches, to project selection, to project budgeting, to integrated teams, to the expectation of completion by the end of the cycle, this video sets the foundation for what comes next.