Shape Up by Basecamp
Shape Up is a great new book by Basecamp team. These guys know a lot about effective product management! Feel free to use as a short version.
1. Example
2. Vocabulary
2.1. The appetite
2.1.1. You can think of the appetite as a time budget for a standard team size. We usually set the appetite in two sizes:
2.1.2. * Small Batch: This is a project that a team of one designer and one or two programmers can build in one or two weeks. We batch these together into a six week cycle (more on that later).
2.1.3. * Big Batch: This project takes the same-size team a full six-weeks.
2.1.4. An appetite is completely different from an estimate. Estimates start with a design and end with a number. Appetites start with a number and end with a design. We use the appetite as a creative constraint on the design process.
2.2. Breadboarding
2.2.1. We borrow a concept from electrical engineering to help us design at the right level of abstraction.
2.2.2. 1. Places: These are things you can navigate to, like screens, dialogs, or menus that pop up.
2.2.3. 2. Affordances: These are things the user can act on, like buttons and fields. We consider interface copy to be an affordance, too. Reading it is an act that gives the user information for subsequent actions.
2.2.4. 3. Connection lines: These show how the affordances take the user from place to place.
2.3. Fat marker sketches
2.3.1. 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.
2.3.1.1. Example
2.4. Icebergs
2.4.1. Front/Back
2.5. Integrate one slice
2.5.1. We can think of projects in two layers: front-end and back-end, design and code. While technically speaking there are more layers than this, these two are the primary integration challenge in most projects.
2.5.1.1. 1
2.5.1.2. 2
2.5.1.3. 3
2.6. Scope hammering
2.6.1. People often talk about “cutting” scope. We use an even stronger word—hammering—to reflect the power and force it takes to repeatedly bang the scope so it fits in the time box.
2.6.2. Questions
2.6.2.1. Is this a “must-have” for the new feature?
2.6.2.2. Could we ship without this?
2.6.2.3. What happens if we don’t do this?
2.6.2.4. Is this a new problem or a pre-existing one that customers already live with?
2.6.2.5. How likely is this case or condition to occur?
2.6.2.6. When this case occurs, which customers see it? Is it core—used by everyone—or more of an edge case?
2.6.2.7. What’s the actual impact of this case or condition in the event it does happen?
2.6.2.8. When something doesn’t work well for a particular use case, how aligned is that use case with our intended audience?
3. Great Ideas!
3.1. Our default response to any idea that comes up should be: “Interesting. Maybe some day.”
3.1.1. 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. It’s important to keep a cool manner and a bit of a poker face. We don’t want to shut down an idea that we don’t understand. New information might come in tomorrow that makes us see it differently. On the other hand, showing too much enthusiasm right away can set expectations that this thing is going to happen.
3.2. No backlogs!
3.2.1. Backlogs are a big weight we don’t need to carry. Dozens and eventually hundreds of tasks pile up that we all know we’ll never have time for. The growing pile gives us a feeling like we’re always behind even though we’re not. Just because somebody thought some idea was important a quarter ago doesn’t mean we need to keep looking at it again and again. 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.
3.3. to-do lists actually grow as the team makes progress!
3.4. Six-weeks cycles
3.4.1. 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. The majority of our new features are built and released in one six-week cycle.
3.5. Important ideas come back!
3.5.1. It’s easy to overvalue ideas. The truth is, ideas are cheap. They come up all the time and accumulate into big piles.
3.5.2. Really important ideas will come back to you. When’s the last time you forgot a really great, inspiring idea? And if it’s not that interesting—maybe a bug that customers are running into from time to time—it’ll come back to your attention when a customer complains again or a new customer hits it. If you hear it once and never again, maybe it wasn’t really a problem. And if you keep hearing about it, you’ll be motivated to shape a solution and pitch betting time on it in the next cycle.
3.6. Mark nice-to-haves with ~
3.6.1. New tasks constantly come up as you get deeper into a problem. You’ll find code that could be cleaned up, edge cases to address, and improvements to existing functionality. 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.
3.7. Work is like a hill
3.7.1. Example
3.8. Scope grows like grass
3.8.1. Scope grows naturally. Scope creep isn’t the fault of bad clients, bad managers, or bad programmers. Projects are opaque at the macro scale. You can’t see all the little micro-details of a project until you get down into the work. Then you discover not only complexities you didn’t anticipate, but all kinds of things that could be fixed or made better than they are.
3.8.2. Every project is full of scope we don’t need. Every part of a product doesn’t need to be equally prominent, equally fast, and equally polished. Every use case isn’t equally common, equally critical, or equally aligned with the market we’re trying to sell to.
3.8.3. This is how it is. Rather than trying to stop scope from growing, give teams the tools, authority, and responsibility to constantly cut it down.
3.9. 1 QA!
3.9.1. At Basecamp’s current size (millions of users and about a dozen people on the product team), we have one QA person. They come in toward the end of the cycle and hunt for edge cases outside the core functionality.
3.9.2. For years we didn’t have a QA role. Then after our user base grew to a certain size, we saw that small edge cases began to impact hundreds or thousands of users in absolute numbers. Adding the extra QA step helped us improve the experience for those users and reduce the disproportional burden they would create for support.
3.10. Let the storm pass
3.10.1. The feedback can be especially intense if the feature you shipped changes existing workflows. A small minority of customers might overreact and say things like “You ruined it! Change it back!”
3.10.2. 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.
3.10.3. Feedback needs to be shaped
4. What the book about?
4.1. Shaped versus unshaped work
4.2. Setting appetites instead of estimates
4.3. Designing at the right level of abstraction
4.4. Concepting with breadboards and fat marker sketches
4.5. Making bets with a capped downside (the circuit breaker) and honoring them with uninterrupted time
4.6. Choosing the right cycle length (six weeks)
4.7. A cool-down period between cycles
4.8. Breaking projects apart into scopes
4.9. Downhill versus uphill work and communicating about unknowns
4.10. Scope hammering to separate must-haves from nice-to-haves
5. Shape the work
5.1. Why?
5.1.1. When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes.
5.1.2. Wireframes are too concrete! No space for designer, too much details
5.1.3. Words are too abstract! When a project is defined in a few words, nobody knows what it means.
5.1.4. Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work.
5.1.4.1. Example
5.2. How?
5.2.1. Set boundaries
5.2.1.1. First we figure out how much time the raw idea is worth and how to define the problem. This gives us the basic boundaries to shape into.
5.2.1.1.1. Set the appetite
5.2.2. Rough out the elements
5.2.2.1. Then comes the creative work of sketching a solution. We do this at a higher level of abstraction than wireframes in order to move fast and explore a wide enough range of possibilities. The output of this step is an idea that solves the problem within the appetite but without all the fine details worked out.
5.2.3. Address risks and rabbit holes
5.2.3.1. Once we think we have a solution, we take a hard look at it to find holes or unanswered questions that could trip up the team. We amend the solution, cut things out of it, or specify details at certain tricky spots to prevent the team from getting stuck or wasting time.
5.2.3.1.1. rabbit holes
5.2.4. Write the pitch
5.2.4.1. 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. The pitch goes to the betting table for consideration. If the project gets chosen, the pitch can be re-used at kick-off to explain the project to the team.
5.2.4.1.1. The pitch content
6. Responsibility
6.1. give full responsibility to a small integrated team of designers and programmers. When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously.
6.2. Assign projects, not tasks
6.2.1. 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.
6.3. Done means deployed
6.3.1. At the end of the cycle, the team will deploy their work.
6.4. The way to really figure out what needs to be done is to start doing real work
6.4.1. That doesn’t mean the teams start by building just anything. They need to pick something meaningful to build first.
6.5. Programmers don’t need to wait
6.5.1. 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.
7. Target a specific risk
7.1. the risk of not shipping on time. This book is about the risk of getting stuck, the risk of getting bogged down with last quarter’s work, wasting time on unexpected problems, and not being free to do what you want to do tomorrow.
7.2. We reduce risk in the shaping process by solving open questions before we commit the project to a time box.
7.3. And lastly we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat.
8. Decide when to stop
8.1. Compare to baseline
8.1.1. 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?
8.1.2. Make scope cuts by comparing down to baseline instead of up to some perfect ideal
8.2. Limits motivate trade-offs
8.2.1. Recall that the six-week bet has a circuit breaker—if the work doesn’t get done, the project doesn’t happen.
8.3. Cutting scope isn’t lowering quality
8.3.1. Making choices makes the product better. It makes the product better at some things instead of others.
8.4. When to extend a project
8.4.1. In very rare cases, we’ll extend a project that runs past its deadline by a couple weeks.
8.4.2. the outstanding tasks must be true must-haves that withstood every attempt to scope hammer them.
8.4.3. the outstanding work must be all downhill. No unsolved problems; no open questions.
8.4.4. Even if the conditions are met to consider extending the project, we still prefer to be disciplined and enforce the appetite for most projects.