“Shape Up” by Ryan Singer - Book Summary
This is my summary of ‘Shape Up’ by Ryan Singer. My notes are informal and tailored to my own interests at the time of reading. They mostly contain quotes from the book as well as some of my own thoughts. I enjoyed this book and would recommend you read it yourself (check it out here).
The 4 steps of shaping work
The conversation about building a feature always starts with a “raw idea” , like “customers are asking for group notifications.” Before we all go down the rabbit hole discussing ways we can solve it, we should first set some broad terms on the discussion to make it productive.
Raw idea --- (shaping) ---> Pitch
Summary of the shaping process:
1/ (PM) Set boundaries. 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.
2/ (Designer + PM + Tech lead) Rough out the elements of the solution. 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.
3/ (Designer + PM + Tech lead) Address risks and rabbit holes. 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.
4/ (PM) Write the pitch. Once we think we’ve shaped it enough to potentially bet on, we package it with a formal write-up called a “pitch” [what I call discovery document]. 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.
Step 1: Set boundaries:
1/ Set the appetite.
The conversations we have are going to be entirely different if people think we’re talking about a small improvement or a major redesign. We need to explicitly define how much of our time and attention the subject (raw idea) deserves; that’s called “appetite.”
We usually set the appetite in two sizes:
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).
Big Batch : This project takes the same-size team a full six-weeks.
In rare cases where the scope is so big that a six-week project isn’t conceivable, we’ll try to hammer it down by narrowing the problem definition. If we still can’t shrink the scope, we’ll break off a meaningful part of the project that we can shape to a six-week appetite.
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. We call it “fixed time, variable scope.”
The amount of time we set for our appetite is going to lead us to different solutions. We could model a whole set of database columns in the fancy version, or just provide a flat textarea in the simple version. We could redesign the main landing page to accommodate a new feature, or we could push it back to a screen with fewer design constraints. We can only judge what is a “good” solution in the context of how much time we want to spend and how important it is.
2/ Narrow down the problem.
Flip from asking “What could we build?” to “What’s really going wrong?”.
Sure, a calendar sounds nice. But what is driving the request? At what point specifically does someone’s current workflow break down without this thing they’re asking for?
Step 2: Rough out the elements of the solution.
The questions we’re trying to answer are:
Where in the current system does the new thing fit?
How do you get to it?
What are the key components or interactions?
Where does it take you?
Work with your Design & Engineering counterparts.
Pair with the designer on your team: 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.
Get continuous feedback from engineering: You don’t need to be a programmer to shape, but you need to be technically literate. You should be able to judge what’s possible, what’s easy and what’s hard. Knowledge about how the system works will help you see opportunities or obstacles for implementing your idea.
You as a PM bring the strategic perspective: 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?
When you discuss feature ideas, you 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.
Wireframes are too concrete.
This leaves designers no room for creativity. “I’ll give a wireframe to my designer, and then I’m saying to her: “I know you’re looking at this, but that’s not what I want you to design. I want you to re-think it!” It’s hard to do that when you’re giving them this concrete thing.”
Over-specifying the design leads to estimation errors. When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth.
Words are too abstract.
When a project is defined in a few words, nobody knows what it means. “Build a calendar view” or “add group notifications” sound sensible, but what exactly do they entail?
Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out.
Use techniques like fat marker sketches or breadboarding.
This step of shaping is still very much in your private sphere. It’s normal for the artifacts at this point — on the wall or in your notebook — to be more or less indecipherable to anybody who wasn’t there with you.
Step 3: Address risks and rabbit holes.
Think through the user flow in detail. Slow down and consider different states.
Present to technical experts.
Emphasize that you’re looking for risks that could blow up the project.
Try to keep the clay wet. Rather than writing up a document or creating a slideshow, invite them to a whiteboard and redraw the elements as you worked them out earlier, building up the concept from the beginning.
Invite them to suggest revisions. Having seen this concept, do they have any insights about how to drastically simplify or approach the problem differently?
Depending on how the conversation goes, you may either have validated your approach or discovered some problems that send you back for another round of shaping.
Declare out of bounds. Call out any cases you specifically aren’t supporting to keep the project well within the appetite.
Cut back. There may be parts of the solution we got excited about during the sketching phase that aren’t really necessary. We could mention it to the team as a nice-to-have, but everyone should start from the assumption that the feature is valuable without it. (I’d say: scrap it, put it as ‘no’). Nice-to-haves are nonsense.
Step 4 just below (I separated it because it’s a key element of Shape Up).
—
The Pitch
The purpose of the pitch is to present a good potential bet. It’s basically a presentation.
It’s only ready to bet on when problem, appetite, and solution come together. Then you can scrutinize the fit between problem and solution and judge whether it’s a good bet or not.
There are five ingredients that we always want to include in a pitch:
1: Problem — The raw idea, a use case, or something we’ve seen that motivates us to work on this.
The best problem definition consists of a single specific story that shows why the status quo doesn’t work. This gives you a baseline to test fitness against. People will be able to weigh the solution against this specific problem—or other solutions if a debate ensues—and judge whether or not that story has a better outcome with the new solution swapped in.
2: Appetite — How much time we want to spend and how that constrains the solution
Stating the appetite in the pitch prevents unproductive conversations. There’s always a better solution. The question is, if we only care enough to spend two weeks on this now, how does this specific solution look?
Anybody can suggest expensive and complicated solutions. It takes work and design insight to get to a simple idea that fits in a small time box.
3: Solution — The core elements we came up with, presented in a form that’s easy for people to immediately understand
Help them see it. People who read the pitch and look at the drawings without much context need to “get” the idea. Use annotated fat marker sketches.
4: Risks — Details about the solution worth calling out to avoid problems
5: No-gos — Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the appetite or make the problem tractable
After you’ve finished your pitch, you share it with stakeholders.
We post pitches as Messages in Basecamp. We created a Message Category called Pitch so we can easily find them. Pitches are posted to a Team called Product Strategy that can be accessed by people on the betting table. (Could do the same on Slack, or with an email, or on Confluence - can be for the PM team, or include stakeholders, depends)
People comment on the pitch asynchronously. Not to say yes or no — that happens at the betting table — but to poke holes or contribute missing information.
Examples:
—
The betting table (prioritization)
Before each six-week cycle, we hold a betting table where stakeholders decide what to do in the next cycle. At the betting table, they look at pitches from the last six weeks — or any pitches that somebody purposefully revived and lobbied for again.
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.
Our betting table at Basecamp consists of the CEO (who in our case has the last word on product), CTO, a senior programmer, and a product strategist (myself).
Everyone has had a chance to study the pitches on their own time beforehand.
Questions to ask at the betting table:
Is this problem more important than that problem right now?
Is the appetite right?
How attractive is the solution?
Is this the right time?
The kind of project we want to do next can depend on which projects we’ve done recently. Maybe it’s been too long since we’ve made a splash of news with a new feature. Or perhaps we’ve been building too many new features and feel overdue to fix some long-standing customer requests. Or if the teams spent the last couple cycles in the same area of the app, their morale may dip if we plan yet another project doing the same kind of work.
Those are all reasons that we might pass on a project even though it’s perfectly well shaped and valuable. The project’s great; it’s just not the right time.
—
6-week cycles
Basecamp plans in 6-week cycles. Then they have 2 weeks of ‘cooldown’.
Use a circuit breaker: 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.
It eliminates the risk of runaway projects. We defined our appetite at the start when the project was shaped and pitched. If the project was only worth six weeks, it would be foolish to spend two, three or ten times that. Very few projects are of the “at all costs” type and absolutely must happen now. We think of this like a circuit breaker that ensures one project doesn’t overload the system. One project that’s taking too long will never freeze us or get in the way of new projects that could be more important.
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 in 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.
It motivates teams to take more ownership over their projects. Teams are given full responsibility for executing projects. That includes making trade-offs about implementation details and choosing where to cut scope. You can’t ship without making hard decisions about where to stop, what to compromise, and what to leave out. A hard deadline and the chance of not shipping motivates the team to regularly question how their design and implementation decisions are affecting the scope.
The key to managing capacity is giving ourselves a clean slate with every cycle.
Only bet one cycle at a time. Never carry scraps of old work over without first shaping and considering them as a new potential bet (sunk cost).
Even if we have some kind of road map in our heads at the time scale above cycles, we keep it in our heads.
Each six weeks we learn what’s working and what isn’t, what’s important and what’s not. There’s no downside to keeping the option open and massive upside from being available to act on the unexpected.
What about projects that just can’t be done in one cycle?
In that case we still only bet six weeks at a time. Suppose we envision a feature that takes two cycles to ship. We reduce our risk dramatically by shaping a specific six week target, with something fully built and working at the end of that six weeks.
If that goes as expected, we’ll feel good about betting the next six weeks the way we envisioned in our heads. But if it doesn’t, we could define a very different project. Or we could put the multi-cycle thing on pause and do something urgent that came up.
—
Principles for cutting scope
Cutting scope isn’t lowering quality.
Variable scope is not about sacrificing quality. We are extremely picky about the quality of our code, our visual design, the copy in our interfaces, and the performance of our interactions.
The trick is asking ourselves which things actually matter, which things move the needle, and which things make a difference for the core use cases we’re trying to solve.
Make scope cuts by comparing down to baseline instead of up to some perfect ideal.
If we aim for an ideal perfect design, we’ll never get there. At the same time, we don’t want to lower our standards. How do we make the call to say what we have is good enough and move on?
It helps to shift the point of comparison. 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?
Seeing that our work so far is better than the current alternatives makes us feel better about the progress we’ve made. This motivates us to make calls on the things that are slowing us down. It’s less about us and more about value for the customer. It’s the difference between “never good enough” and “better than what they have now.”
—
How to prioritize between slices of work when you start a project
Start with the most important problems with the most unknowns.
It’s better to get a few critical scopes over the top early in the project and leave the screw-tightening for later. Start with risky, new things that are core. You don’t want to save the surprises for the end.
As the end of the cycle approaches, teams should have finished the important things and left a variety of “nice to haves” and “maybes” lingering around.
Journalists have a concept called the “inverted pyramid.” The idea is their articles start with the most essential information at the top, then they add details and background information in decreasing order of importance. This allows print newspaper designers to get the crucial part of the story on the front page and cut the end as needed without losing anything essential.
Start with something small enough.
If the first piece of work isn’t small enough, there isn’t much benefit to carving it off from the rest. The point is to finish something meaningful in a few days and build momentum—to have something real to click on that shows the team is on the right track.
—
Prioritization
Example: The Dot Grid Calendar.
We launched version three of Basecamp without a calendar feature. It had a “schedule” feature that just listed events one after the other without any kind of monthly, weekly or daily grid.
Soon after launch, customers started asking us to “add a calendar” to Basecamp. We had built calendars before and we knew how complex they are. It can easily take six months or more to build a proper calendar.
Past versions of Basecamp had calendars, and only about 10% of customers used them. That’s why we didn’t have the for spending six months on a calendar. On the other hand, if we could do something to satisfy those customers who were writing us in one six week cycle, we were open to doing that.
With only six weeks to work with, we could only build about a tenth of what people think of when they say “calendar.” The question became: which tenth?
The outcome:
We did some research and narrowed down a use case that we wanted to solve. We eventually arrived at a promising concept inspired by calendars on phones. We could build a two-month, read-only grid view. Any day with an event would have a dot for each event. A list of events would appear below the calendar, and clicking a day with a dot would scroll the events for that day into view. We called it the Dot Grid.
The Dot Grid wasn’t a full-featured calendar. We weren’t going to allow dragging events between days. We weren’t going to span multi-day events across the grid; we’d just repeat the dots. There’d be no color coding or categories for events. We were comfortable with all these trade-offs because of our understanding of the use case.
—
‘Shape Up’ also covered many more insightful topics. You’ll find them below in alphabetical order.
Bets
Talk about bets, not features.
Bets have a payout. We’re not just filling a time box with tasks until it’s full. We’re not throwing two weeks toward a feature and hoping for incremental progress. We intentionally shape work into a six-week box so there’s something meaningful finished at the end. The pitch defines a specific payout that makes the bet worth making.
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. We’re not trying to optimize every hour of a programmer’s time. We’re looking at the bigger movement of progress on the whole product after the six weeks.
A smart bet has a cap on the downside. If we bet six weeks on something, the most we can lose is six weeks. We don’t allow ourselves to get into a situation where we’re spending multiples of the original estimate for something that isn’t worth that price.
Bugs
All software has bugs. The question is: how severe are they?
There is nothing special about bugs that makes them automatically more important than everything else. The mere fact that something is a bug does not give us an excuse to interrupt ourselves or other people.
If we’re in a real crisis—data is being lost, the app is grinding to a halt, or a huge swath of customers are seeing the wrong thing—then we’ll drop everything to fix it. But crises are rare.
The vast majority of bugs can wait six weeks or longer, and many don’t even need to be fixed. If we tried to eliminate every bug, we’d never be done. You can’t ship anything new if you have to fix the whole world first.
Use cool-down. Ask any programmer if there are things they wish they could go back and fix and they’ll have a list to show you. The cool-down period between cycles gives them time to do exactly that. Six weeks is not long to wait for the majority of bugs, and two weeks every six weeks actually adds up to a lot of time for fixing them.
Bring it to the betting table. If a bug is too big to fix during cool-down, it can compete for resources at the betting table. There’s a huge difference between delaying other work to fix a bug versus deciding up front that the bug is worth the time to fix.
Schedule a bug smash. Once a year—usually around the holidays—we’ll dedicate a whole cycle to fixing bugs. We call it a “bug smash.” The holidays are a good time for this because it’s hard to get a normal project done when people are traveling or taking time off. The team can self-organize to pick off the most important bugs and solve long-standing issues in the front-end or back-end.
Idea banks
Our default response to any idea that comes up should be: “Interesting. Maybe someday.” 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 too early to say “yes” or “no” on first contact. Even if we’re excited about it, we shouldn’t make a commitment that we don’t yet understand. We need to do work on the idea before it’s shaped enough to bet resources on.
Problem statements / definition
We once had a customer ask us for more complex permission rules. It could easily have taken six weeks to build the change she wanted. Instead of taking the request at face value, we dug deeper. It turned out that someone had archived a file without knowing the file would disappear for everyone else using the system. Instead of creating a rule to prevent some people from archiving, we realized we could put a warning on the archive action itself that explains the impact. That’s a one-day change instead of a six-week project.
In the case of the calendar request, we called a customer who asked for this feature. 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? We narrowed down the need from “do everything a calendar does” to “help me see free spaces so I can figure out when to schedule something.”
Plays to better understand problems:
Customer interviews. Don’t ask “why”, ask “when.”
Solution design
“Good” is relative. 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. The ultimate meal might be a ten course dinner. But when you’re hungry and in a hurry, a hot dog is perfect.
Stakeholder management
Engineers:
Designers and programmers always want to do their best work. The best programmers want the code base to feel like a cohesive whole, completely logically consistent with every edge case covered.
Designers:
Designers and programmers always want to do their best work. It doesn’t matter if the button is on the center of the landing page or two pages down a settings screen, the designer will give it their best attention.
Click here to browse more book summaries.