Shaping in a Nutshell

Hey everybody, I'm really glad that you are here and interested in talking about product development. Most people don't wake up in the morning and think like today I want to change the way that we do our work process. There has to be something that's happening in your team or in your situation that kind of makes this relevant for you. And there's usually three reasons that make people become interested in it. The first case is where everything is actually basically fine at the company, but you're starting to hire you're starting to grow and you're looking forward thinking this isn't going to be sustainable i'm not going to be the person who's going to be making the decisions in all the different teams i can't multiply myself and be everywhere so how are we going to make progress on multiple fronts at the same time another case is where well that moment passed and everyone was too busy just holding on while the company was growing to reconsider the way that they work And then all of a sudden you look around and you say, do you remember when we used to actually finish things? What happened here? Why is it taking so long for us to ship? And why is it so hard to understand where we are? And here we also start to see a disconnect between product and engineering. where product is saying look i thought that we agreed i thought that we understood each other why isn't it done yet and engineering is saying you don't understand how it really works it's more complicated than you think and the question is like how do we get back to like it was in the early days when it was harmonious and we were getting things done and we were excited about finishing things and regularly shipping The third case is where you're not actually in the management role and you're more of an individual contributor, but you're looking around and you're saying, there's got to be a better way. And you're looking to start to build some skills, some language and some understanding so that at a minimum, you might be able to improve some things in your area. And then longer term, you might be able to bring a new way of working into a future role. So in all three cases, the question is the same. What to do differently? And if you go and you check out the offerings on the shelf, you see the same things, right? You see Scrum, you see the Kanban board, you see the meetings every day with lots of people. And if you check those things out and decided that those things aren't the solution for you, well, then what do you do? Well, over 17 years, while I was a member of the core team at Basecamp, we came up with a new way of working that solved these problems for us. And I got to check it out from a lot of different vantage points, working from the standpoint of a UI designer, doing programming, doing product management, and making strategy decisions, all these different levels. Then I was able to actually formalize this into a framework that other companies can use. And in 2019, this was published as a book called ShapeUp, which brings us to this video. What I want to do here is give you a high-level picture of the most important ideas in ShapeUp so that you can decide. this is going to be a good option for you and you can decide if it's something that you want to go deeper into or not so let's get into it so I like to start off with a simple picture that everybody can relate to you know in order for a group of people to work together they need to be able to understand each other even though they all play different roles and everybody can understand a house Software is like building a house. You can't just show up to the building site with a bunch of tools and people and raw materials and expect a beautiful, well-organized house to appear out of this. You need to have a plan. But at the same time, building software is not at all like building a house. Everybody has seen countless houses, and we know what a house should be and what a house should do, so you can plan a house completely upfront. With software, there's a big element of the unknown. Usually when we're building software, we're making something that didn't exactly exist before. And so we have a theory of how people are going to use it. But then when we actually get it into people's hands, we can be surprised by how differently they use it or that they don't even use it at all. So how do we deal with this? planning if we plan the big thing up front six months a year long then it takes a really long time to find out that we didn't build the right thing and if we just try to build two weeks at a time each piece is too small we never get anything meaningful done and it's really hard to see where the finish line is and when we can actually stop a good way to deal with this is to think about defining smaller projects where we have an entire piece of something that works that we can ship and that we can try out that's not the whole house and it's also not just an incremental piece where we're hoping that eventually it'll turn into something that we can try a good rule of thumb is to think about planning projects in a time box of around six weeks it's six weeks is kind of a magic number it's long enough to get something meaningful finished really finished and shipped and out into the real world and it's still short enough that we retain the flexibility that we want to change course afterward and to not be stuck in a big long plan. This brings us to one of the big key ideas of ShapeUp, which is how we relate to time boxes and how we think about planning time. Most companies deal with the question of planning time by making estimates, and estimates are a famously difficult subject because they always turn out to be wrong. Of course, this is understandable, especially with technical work. what we imagine we have to do and then what we find out we really have to do when we get our hands dirty are two different things and then when the work takes longer than we thought it would it creates tensions in the team right because the project keeps dragging and everyone's saying why now whenever we make an estimate we're doing something very simple we're taking a piece of work that we think we have to do and then we're attaching a number to it and we're saying like it's going to take this long to do this piece of work We can actually flip this around and think about it in a completely different way and here we talk about appetite instead of estimates So the question of an appetite isn't how long do I think it's going to take to do this piece of work? The question is how much time do we want to spend and this is a totally different question This is a strategic question about the value of the thing that we're going to do and the urgency we have and the other things that are going on in the business that we're going to have to do next. When we have an appetite and we say, you know, this thing is worth six weeks of time or this thing is actually, you know, kind of a small thing that we need to satisfy some customers with. We only really want to spend two or three weeks on it. When we make that kind of a decision, then we open up a relationship with the technical people where we become partners in solving how to get something done inside of that time box. Let's say we want to go out to dinner tonight. We can say, we want steak dinner, and whatever it costs, that's what it's going to take. Or we can say, well, this is how much we have. What are our options? Where would we like to go? With an estimate, the scope is fixed. We say this is what we're going to do and the time becomes variable because it takes as long as it takes in the end. With an appetite, we turn this around and we say that the time is going to be fixed and the scope of what we do inside of that time is going to be variable so that we don't go outside of the fixed time box. This is possible because there are different degrees to which we can do things. If we say that we want a boat, we could have a rowboat or a speedboat or a yacht. And of course, as the designers, as the programmers, as the people who make things, we always want to make yachts. The business might have a different idea. So how do we square these two things? That's what shaping is all about. Shaping is where we make the trade-offs and find out different possibilities for what we can build that still fits within the amount of time that the business has decided they want to spend. Let's look at what happens inside of the shaping phase. The shaping phase is where the technical knowledge of what is possible and the design knowledge of what's going to work for the user come together with the constraints of the appetite that we talked about and if we look at the overall timeline of the product development process this is happening before a commitment is made to actually schedule a project and go have people start building something because we have to actually understand is there something that we can do that's going to work inside of the time that we're willing to spend when we do the shaping there are two aspects to this the first one is a question of scope what is in and what is out and the second one is a question of how much detail to define up front and how many things to leave for the team to solve later so let's start off by looking at this question of scope i like using the example of a calendar for this because everyone understands how complicated a calendar can be There's a month view, week view, day view, dragging things around with high-tech interactions. There's invitations. There's so much stuff there. Once Basecamp's customers were asking for a calendar feature, and it was only a small number of customers, and it wasn't like a main part of the product. And so Basecamp didn't want to spend more than six weeks on it. So this raised a difficult question. In six weeks, you could probably only build one-tenth of a calendar. So which tenth? To answer this question, we took a close look at the customers who were asking. In all the cases, they were using the agenda view that Basecamp already had that showed a list of all the upcoming events. And what was missing for these people were the empty spaces. Then we said, ah, it's so simple. All we have to show is a month view with dots for the days that have events. Now, it could have been different. Maybe what the customers were missing was a way to deal with overlapping schedules. then we might have chosen to build something like a doodle tool. This shows that choosing the scope when we're shaping is not just a question of small, medium, and large. It's actually about making different trade-offs and choosing the different pieces of functionality that are in and out. The second aspect of shaping is the amount of detail that's in the shaped concept. Sometimes we call it latitude. How much is spelled out and how much is left open for the team to decide later. Now here we often see two extremes. There's the extreme of undershaping and overshaping. Undershaping is where there aren't enough detail about how to actually solve the problem. And this often looks like a wish list or like a magic wand. An example of this is, teachers should be able to easily see all student assessments in one place. Now that's a good start for defining a product concept, but when that goes into the time box, the team is going to have to figure out what does that actually mean. Where does this screen fit in? How does it connect to other screens? There's a whole lot of unknowns that have to get solved. And that means that the work is actually going to stall inside of that time box. And the team isn't going to have a fair chance to use the whole six weeks that they're given to actually build something. The other extreme is overshaping. Overshaped work looks like a completely detailed specification. And it often takes the form of the beautiful monster. The giant figma file. with 30 different screens in beautiful colors and styles down to the finest detail. And of course, this is nice to look at and it gives us a feeling of certainty that now we know what to go build. But this certainty is an illusion. When the work goes over to the programmers, they often discover that the time it takes to build out all of these details is beyond the time that they have. Then the programmers have to chop the project up into pieces, which is frustrating for everybody. The designer doesn't get to see their vision created, and the programmers make choices about what to put in and what to leave out. And those choices don't always match the intent of the designers and the business people. The other problem with this certainty is we get stuck with the first idea. Anytime something goes into a hard line drawing, it becomes sacred. For some reason, people find it very difficult to let go of that and make changes later. Between over-shaped and under-shaped, there's shaped work. And what does that look like? Well, we explain in words the broad idea of the project, the main elements, and how they fit together to form the solution. And we often add some rough sketches that show the key relationships. This gives the team the understanding of what we're trying to do without boxing them in. They still have room to make creative decisions and deal with the unexpected problems that arise during the time box. When the work is defined at the right level of latitude, we can give the team autonomy over the project. And this brings us to the third key idea. When we talk about the team having autonomy over the project, the first thing that we need is a team. So here the team is a small group, maybe two to three people, who stick together for the duration of the time box. So that whole four, five, six weeks, they're working just with each other to build out this shaped work. We can also have those people in mind during the shaping. because different people in the company have different skills and different specialties, and the more that we can make it a good fit, the more likely the project will be successful. The second thing is the project. And here we do something unusual. We actually assign the project as a whole, and we don't break it down into individual tasks first. If we shred the project into separate tasks, this doesn't work. First of all, nobody can actually forecast all of the tasks in the beginning that need to get done. You find those out by actually doing the real work. the second thing is if we make people responsible for tasks then they might check off their individual tasks but nobody is really focused on how all the tasks come together every step of the way to achieve the outcome and this outcome is exactly what we want we don't just want some tasks finished here and there we want to get to a shipped completed project at the end of the time that we set and this is what we want to make the team responsible for now It's not fair for us to make the team responsible for that outcome if we keep pulling them away and asking them to work on other things. It's not enough to tell the people doing the programming, please stay focused on this thing. It's actually a business decision higher up to say, this is the thing that's important and we're not going to bring other work to these people right now. That's how we protect their focus. Okay, but things come up, right? Like what to do about the urgent bug that comes up or the different things that appear. here we can distinguish between two types of work there's the planned strategic work that you decide that you want to do as a business and then there's that unplanned reactive work that comes up from a stakeholder or a customer or a system that suddenly went on fire or whatever it is right and the way to deal with this is to have dedicated capacity for one kind of work versus the other you can either do this as a rotation where people are taking turns doing reactive versus planned work, or you can have dedicated teams depending on the situation at your company. When we have the team and they have the project as a whole that they're responsible for, and they have the real autonomy and focus of being uninterrupted to work on just that, we can have a very different work culture. Here, the team doesn't need to participate in rituals like daily stand-ups or meetings where they're giving a lot of status on things. they are together in the same context, in an unbroken continuity for those weeks together. So they can meet and self-manage in whatever rhythm makes sense for the problems they're solving and the work that they're doing. This focus and autonomy, together with strategically setting appetites and shaping the work, brings us into a new situation where we can make progress on multiple fronts in parallel. and we can get back to that energized feeling where we are regularly shipping things that really matter. So that's shaping in a nutshell. You might just want to take some inspiration from that and bring it back to your company. Or you might think that this is actually a change that you want to make and it's something that you want to adopt. There you have a couple options depending on the way that your company is structured. When I first wrote ShapeUp, I was describing exactly how we work at Basecamp. And Basecamp has some distinctive characteristics. It's a small company that's self-funded, mostly senior people, and there's a very high ratio of designers to programmers. They're very evenly matched. If your company matches that description, you can probably lift a lot out directly from the book and apply it. If your company doesn't exactly match that description, like if you have many more junior programmers, if you have different product and engineering functions that are managed separately, or maybe you have a different ratio of programmers to designers. There are going to be a lot of things to work out in order to adapt it. For those companies, I made a course called Shaping in Real Life. And there, I get into all the details of how to figure out who shapes, how to make time for shaping, how to actually run a shaping session and teach people to participate, how to deal with people who have very different skill levels. how to package shaped work into a form that you can give to a different team, and how to deal with all the different disconnects that can come up between product and engineering. To get into all of that and more, I look forward to seeing you at the course.

A short introduction for people curious about Shape Up. It covers the key principles from the book in under twenty minutes.

00:00 Why people start questioning their process
02:53 Planning software: Comparison to building a house
04:00 Long plans vs. sprints vs. ~6 week time boxes
05:05 Key Idea #1: Estimate vs. Appetite
08:00 Key Idea #2: Shaping
08:57 Shaping: Defining the scope
10:17 Shaping: Latitude
13:03 Key Idea #3: Team Autonomy
16:22 Next steps

▶︎ For the "Shaping in Real Life" course, go to: http://feltpresence.com/srl

Get the book: http://basecamp.com/shapeup

Written and illustrated by Ryan Singer
Filmed, produced, and designed by Katya Singer

© 2022 Ryan Singer