# Ryan Singer - Shape Up (Highlights)  ## Metadata **Review**:: [readwise.io](https://readwise.io/bookreview/38913846) **Source**:: #from/readwise #from/weread **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[Ryan Singer]] **Full Title**:: Shape Up **Category**:: #books #readwise/books **Category Icon**:: 📚 **Highlighted**:: [[2024-03-22]] **Created**:: [[2024-03-22]] ## Highlights ### Introduction - This book is a guide to how we do product development at Basecamp. (Page 11) ^696268971 - First, we work in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. (Page 14) ^696268972 - Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (Page 14) ^696268973 - Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (Page 15) ^696268974 - Third, we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (Page 15) ^696268975 ### Shaping #### Principles of Shaping - Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. The work isn’t specified down to individual tasks, but the overall solution is spelled out. (Page 25) ^696268978 - Lastly, shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. (Page 25) ^696268979 - Shaping is primarily design work. The shaped concept is an interaction design viewed from the user’s perspective. It defines what the feature does, how it works, and where it fits into existing flows. (Page 26) ^696268980 - It’s also strategic work. Setting the appetite and coming up with a solution requires you to be critical about the problem. What are we trying to solve? Why does it matter? What counts as success? Which customers are affected? What is the cost of doing this instead of something else? (Page 26) ^696268981 - For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. (Page 26) ^696268982 - Once we think we’ve shaped it enough to potentially bet on, we package it with a formal write-up called a pitch. The pitch summarizes the problem, constraints, solution, rabbit holes, and limitations. (Page 27) ^696268983 #### Set Boundaries - Sometimes an idea gets us excited right away. In that case we need to temper the excitement by checking whether this is really something we’re going to be able to invest time in or not. (Page 28) ^696268985 - We call this the appetite. You can think of the appetite as a time budget for a standard team size. (Page 29) ^696268986 - This principle, called “fixed time, variable scope,” is key to successfully defining and shipping projects. (Page 30) ^696268987 - There’s no absolute definition of “the best” solution. The best is relative to your constraints. Without a time limit, there’s always a better version. (Page 30) ^696268988 - Our default response to any idea that comes up should be: “Interesting. Maybe some day.” In other words, a very soft “no” that leaves all our options open. We don’t put it in a backlog. We give it space so we can learn whether it’s really important and what it might entail. (Page 31) ^696268989 - Instead of asking her why she wants a calendar and what it should look like, we asked her when she wanted a calendar. What was she doing when the thought occurred to ask for it? (Page 32) ^696268990 #### Find the Elements - To stay on the right level of detail and capture our thoughts as they come, we work by hand using a couple of prototyping techniques: breadboarding and fat marker sketches. (Page 36) ^696268992 - We’ll use words for everything instead of pictures. The important things are the components we’re identifying and their connections. They allow us to play out an idea and judge if the sequence of actions serves the use case we’re trying to solve. (Page 37) ^696268993  - A fat marker sketch is a sketch made with such broad strokes that adding detail is difficult or impossible. We originally did this with larger tipped Sharpie markers on paper. Today we also do it on iPads with the pen size set to a large diameter (Page 42) ^696268994 - The next step is to do some stress-testing and de-risking. We want to check for holes and challenges that could hinder the project from shipping within the fixed time appetite that we have in mind for it (Page 47) ^696268995 #### Risks and Rabbit Holes - One way to analyze the solution is to walk through a use case in slow motion. Given the solution we sketched, how exactly would a user get from the starting point to the end? Slowing down and playing it out can reveal gaps or missing pieces that we need to design. (Page 50) ^696268997 - Beware the simple question: “Is this possible?” In software, everything is possible but nothing is free. We want to find out if it’s possible within the appetite we’re shaping for. Instead of asking “is it possible to do X?” ask “is X possible in 6-weeks?” That’s a very different question. (Page 55) ^696268998 #### Write the Pitch - There are five ingredients that we always want to include in a pitch (Page 58) ^696269000 Problem, Appetite, Solution, Risks (Rabbit holes), No-gos. - It’s critical to always present both a problem and a solution together. It sounds like an obvious point but it’s surprising how often teams, our own included, jump to a solution with the assumption that it’s obvious why it’s a good idea to build this thing (Page 58) ^696269001 - Fat marker sketches can be very effective in a pitch; you just need to take more care to label them cleanly. (Page 62) ^696269002 - We prefer asynchronous communication by default and escalate to real-time only when necessary. This gives everyone the maximum amount of time under their own control for doing real work. That means the first step for presenting a pitch is posting the write-up with all the ingredients above somewhere that stakeholders can read it on their own time. (Page 67) ^696269003 ### Betting #### Bets, Not Backlogs - Backlogs are big time wasters too. The time spent constantly reviewing, grooming and organizing old ideas prevents everyone from moving forward on the timely projects that really matter right now. (Page 72) ^696269006 - At the betting table, they look at pitches from the last six weeks — or any pitches that somebody purposefully revived and lobbied for again. (Page 73) ^696269007 - If we decide to bet on a pitch, it goes into the next cycle to build. If we don’t, we let it go. There’s nothing we need to track or hold on to. (Page 73) ^696269008 - This approach spreads out the responsibility for prioritizing and tracking what to do and makes it manageable. People from different departments can advocate for whatever they think is important and use whatever method works for them to track those things—or not (Page 74) ^696269009 - It’s easy to overvalue ideas. The truth is, ideas are cheap. They come up all the time and accumulate into big piles. (Page 74) ^696269010 #### The Betting Table - Therefore, after each six-week cycle, we schedule two weeks for cool-down. This is a period with no scheduled work where we can breathe, meet as needed, and consider what to do next. (Page 76) ^696269012 - During cool-down, programmers and designers on project teams are free to work on whatever they want. After working hard to ship their six-week projects, they enjoy having time that’s under their control. They use it to fix bugs, explore new ideas, or try out new technical possibilities. (Page 76) ^696269013 - Second, bets are commitments. If we bet six weeks, then we commit to giving the team the entire six weeks to work exclusively on that thing with no interruptions. (Page 79) ^696269014 - Teams have to ship the work within the amount of time that we bet. If they don’t finish, by default the project doesn’t get an extension. (Page 80) ^696269015 - Second, if a project doesn’t finish in the six weeks, it means we did something wrong in the shaping. Instead of investing more time in a bad approach, the circuit breaker pushes us to reframe the problem. We can use the shaping track on the next six weeks to come up with a new or better solution that avoids whatever rabbit hole we fell into on the first try. Then we’ll review the new pitch at the betting table to see if it really changes our odds of success before dedicating another six weeks to it (Page 81) ^696269016 - Once a year—usually around the holidays—we’ll dedicate a whole cycle to fixing bugs. We call it a “bug smash.” (Page 82) ^696269017 #### Place Your Bets - On an existing product, all of the existing code and design that isn’t going to change defines a kind of empty space that the new feature will fit into. Shaping and building is like crafting a piece of furniture for a house that is already built. (Page 84) ^696269019 - We’ve noticed three phases of work when we build a new product from scratch. (Page 84) ^696269020 R&D, Production, Cleanup - Instead of betting on a well-shaped pitch, we mainly bet the time on spiking some key pieces of the new product idea. (Page 85) ^696269021 R&D mode adjustment 1 - Rather than delegating to a separate build team, our senior people make up the team. (Page 85) ^696269022 R&D mode adjustment 2 - Lastly, we don’t expect to ship anything at the end of an R&D cycle. The aim is to spike, not to ship. (Page 86) ^696269023 R&D mode adjustment 3 - Since we aren’t shipping to customers at the end of each cycle, we maintain the option to remove features from the final cut before launch. (Page 87) ^696269024 In Production mode - Sometimes we need to see all the features working as a whole to judge what we can live without and what might require deeper consideration before shipping it to customers. (Page 88) ^696269025 It's also a necessary cooldown. - How the people at the table judge problems depends on their perspective, role, and knowledge. For example, a problem might impact a small segment of customers but put a disproportionate burden on support. Depending on your exposure to support and which aspect of the business you’re focused on, you may weigh that differently. (Page 90) ^696269026 - Sometimes saying “no” to the time commitment is really saying no to something else. Maybe there’s something about the solution or the technical implementation they don’t like. Asking “How would you feel if we could do it in two weeks?” can uncover that it’s not so much about the time. The CTO might answer, “I don’t want to introduce another dependency into that area of the app.” (Page 91) ^696269027 ### Building #### Hand Over Responsibility - Splitting the project into tasks up front is like putting the pitch through a paper shredder. Everybody just gets disconnected pieces. We want the project to stay “whole” through the entire process so we never lose sight of the bigger picture. (Page 96) ^696269030 - Instead, we trust the team to take on the entire project and work within the boundaries of the pitch. The team is going to define their own tasks and their own approach to the work. (Page 96) ^696269031 - The designers and programmers doing the real work are in the best position to make changes and adjustments or spot missing pieces. (Page 97) ^696269032 - That also means any testing and QA needs to happen within the cycle. The team will accommodate that by scoping off the most essential aspects of the project, finishing them early, and coordinating with QA. (More on that later.) (Page 98) ^696269033 - It’s important for managers to respect this phase. Teams can’t just dive into a code base and start building new functionality immediately. They have to acquaint themselves with the relevant code, think through the pitch, and go down some short dead ends to find a starting point. (Page 101) ^696269034 - Generally speaking, if the silence doesn’t start to break after three days, that’s a reasonable time to step in and see what’s going on. (Page 101) ^696269035 - Teams discover tasks by doing real work. (Page 101) ^696269036 #### Get One Piece Done - It’s important at this early phase that they don’t create a master plan of parts that should come together in the 11th hour. If the team completes a lot of tasks but there’s no “one thing” to click on and try out, it’s hard to feel progress. (Page 103) ^696269038 - What we want instead is to pick off one slice of the project to integrate. Then when that’s done, the team has something tangible that they’ve proven to work (or not work and reconsider). (Page 104) ^696269039  - Because the important moving parts were already defined in the shaping process, programmers don’t need to sit idle waiting for design when the project starts. There’s enough direction in the pitch for them to start working on back-end problems from the start. (Page 107) ^696269040 - Second, it should be small. If the first piece of work isn’t small enough, there isn’t much benefit to carving it off from the rest. (Page 112) ^696269041 - Third, it should be novel. If two parts of the project are both core and small, prefer the thing that you’ve never done before. (Page 112) ^696269042 #### Map The Scopes - Instead, they should create lists based on the structure of the project—the things that can be worked on and finished independently of each other. (Page 114) ^696269044 - We call these integrated slices of the project scopes. We break the overall scope (singular) of the project into separate scopes (plural) that can be finished independently of each other. (Page 114) ^696269045 - As the team starts doing real work on the project they learn how the tasks are related and what the structure of the project is really like. Then they become able to factor the project into scopes. This is like dividing the map of the project into separate territories. (Page 115) ^696269046 - Scope mapping isn’t planning. You need to walk the territory before you can draw the map. (Page 122) ^696269047 - The scopes need to be discovered by doing the real work and seeing how things connect and don’t connect. (Page 122) ^696269048 - Conversations about the project become more flowing because the scopes give you the right language. (Page 123) ^696269049 - When new tasks come up, you know where to put them. The scopes act like buckets that you can easily lob new tasks into. (Page 123) ^696269050 - For both back-end and front-end icebergs, we always question them before accepting them as a fact. Is the complexity really necessary and irreducible? Do we need that fancy UI? Is there a different way to build that back-end process so it has fewer interdependencies with the rest of the system? (Page 126) ^696269051 - There are almost always a couple things that don’t fit into a scope. We allow ourselves a “Chowder” list for loose tasks that don’t fit anywhere. But we always keep a skeptical eye on it. If it gets longer than three to five items, something is fishy and there’s probably a scope to be drawn somewhere. (Page 126) ^696269052 - A good way to deal with all those improvements is to record them as tasks on the scope but mark them with a ~ in front. This allows everyone on the team to constantly sort out the must-haves from the nice-to-haves. (Page 126) ^696269053 #### Show Progress - If we tried to judge at t 2how far along the project is, we’d be misled. From an outsider’s perspective, there’s no way to know whether the number of outstanding tasks will go down or up. To know that, you’d need more context on the work inside the scope to understand what it means that those particular tasks are done and whether others might still be coming. (Page 128) ^696269055 - Recognizing this, we came up with a way to see the status of the project without counting tasks and without numerical estimates. We do that by shifting the focus from what’s done or not done to what’s unknown and what’s solved. (Page 129) ^696269056 - The scopes give us the language for the project (“Locate,” “Reply”) and the hill describes the status of each scope (“uphill,” “downhill”). (Page 133) ^696269057 - It’s good to think of the first third uphill as “I’ve thought about this,” the second third as “I’ve validated my approach,” and the final third to the top as “I’m far enough with what I’ve built that I don’t believe there are other unknowns.” (Page 139) ^696269058 - It’s better to get a few critical scopes over the top early in the project and leave the screw-tightening for later. (Page 140) ^696269059 - Effective teams sequence their problem solving in the same way. They choose the most important problems first with the most (Page 140) unknowns, get them to the top of the hill, and leave the things that are the most routine or least worrisome for last. (Page 141) ^696269060 #### Decide When to Stop - Instead of comparing up against the ideal, compare down to baseline—the current reality for customers. How do customers solve this problem today, without this feature? What’s the frustrating workaround that this feature eliminates? How much longer should customers put up with something that doesn’t work or wait for a solution because we aren’t sure if design A might be better than design B? (Page 143) ^696269062 - Nice-to-haves can linger on a scope after it’s considered done. They’re marked with a tilde (~) in front. (Page 146) ^696269063 - QA can limit their attention to edge cases because the designers and programmers take responsibility for the basic quality of their work. (Page 147) ^696269064 - Therefore we think of QA as a level-up, not a gate or a check-point that all work must go through. We’re much better off with QA than without it. But we don’t depend on QA to ship quality features that work as they should. (Page 148) ^696269065 - The team can ship without waiting for a code review. There’s no formal check-point. But code review makes things better, so if there’s time and it makes sense, someone senior may look at the code and give feedback. It’s more about taking advantage of a teaching opportunity than creating a step in our process that must happen every time. (Page 148) ^696269066 #### Move On - It’s important to stay cool and avoid knee-jerk reactions. Give it a few days and allow it to die down. Be firm and remember why you made the change in the first place and who the change is helping. (Page 150) ^696269068 #### Conclusion - • Shaped versus unshaped work • Setting appetites instead of estimates • Designing at the right level of abstraction • Concepting with breadboards and fat marker sketches • Making bets with a capped downside (the circuit breaker) and honoring them with uninterrupted time • Choosing the right cycle length (six weeks) • A cool-down period between cycles • Breaking projects apart into scopes • Downhill versus uphill work and communicating about unknowns • Scope hammering to separate must-haves from nice-to-haves (Page 152) ^696269070 #keypoints