I’ve started beeminding my way through Basecamp’s product management book, Shape Up, and thought I’d see if anyone else wanted to join me in reading it.
(live version of graph)
Either way, I figure I’ll use this thread to take notes on it, like I did for a superficially similar book a couple years ago:
rough notes on Shape Up as I go
Chapter 1: Intro
- No kanban, no backlogs, no sprints or standups, no velocity tracking. Raised eyebrows from me – I’m maybe a little bit attached to some of those things. We’ll see what their arguments are!
- Six-week cycles, with no extensions by default.
- Key concepts: shaping and appetite.
- Teams have full responsibility.
Part 1: Shaping
Chapter 2: Shaping
- Aim for in between words and wireframes – so maybe a 0.4 on the spec-trum?
- Shaping = rough, solved, bounded – and it should happen in a proverbially smoke-filled room, like with a couple people at a whiteboard.
Chapter 3: Boundaries
- Appetite is the inverse of an estimate. An estimate maps a spec to an amount of time. The idea of appetite is to decide how much time an idea is worth first and then shape the spec to fit. Aka fixed time, variable scope.
- “Maybe some day”. The default response to raw new ideas should be a soft no. Don’t overcommit.
- Focus features on what problems they’re solving. What are the use cases? Don’t ask a user why they want something, ask when they want it, as in what specifically are they doing when they get the notion that they need this feature.
- Projects should have circumscribed scope, not things like “redesign goal creation”.
Chapter 4: Finding the Elements
- Breadboarding (as in a breadboard in electrical engineering): define the key elements without worrying about how the final thing will look visually.
- Components of breadboarding: Places (screens, dialogs, menus), Affordances (buttons, fields – things the user can act on), and Connections (how the affordances take you between places) – this makes for very lightweight/flexible spec’ing
- Fat marker sketches: Like literally a fat marker, or set the pen size to a large diameter if you’re using a drawing app. The idea is that if you’re designing something inherently visual then breadboarding doesn’t work but you still want to eliminate unneeded fidelity in the design. Why? To keep yourself from jumping ahead to too much detail at too early a stage in the design process.
- Designers and implementers will take everything in your mockup as a directive. Stay at the right level of abstraction so they don’t interpret details as directives when you didn’t intend them to be.
- Aiming not for a spec but for boundaries and rules of a game that can play out in countless ways.
Chapter 5: Risks and Rabbit Holes
- Before a project is shaped enough to bet on, it should be de-risked, ie, have a tight confidence interval on how long it will take.
- Walk through use cases in slow motion.
- Ask questions like what assumptions you’re making about how things fit together, whether it requires new technical work you haven’t done before, etc.
- Anticipate hard decisions that could trip up the implementors and make them in advance. (I think this also fits into the idea of finding the sweet spot on the spec spectrum.)
- Don’t give your team a tangled knot of interdependencies and ask them to disentangle it as part of implementing the project.
- Mark things out of bounds, aka Joel Spolsky’s “non-goals” as part of a well-written spec.
- As part of shaping, run things by experts on the team (making clear that it’s just being shaped, not in the pipeline).
- Don’t say “is this possible?”. The question is what’s possible given the appetite. “Is this possible in 6 weeks?” is a good question.
- Ask the experts what risks they can identify. Invite them to a whiteboard and show them what you’ve shaped so far. You’ll either get validation of your approach or have found things to consider as you go back to shaping.
- Write up the pitch. That includes elements of solution, patches for rabbit holes, and fences for what’s in-bounds. Now you can decide whether to bet on it. The pitch also lobbies for resources and solicits wider feedback. Or at least captures the idea for the future.
Chapter 6: Write the Pitch
A pitch is a presentation of a good potential bet. It has five ingredients:
- PROBLEM: the problem to solve or a use case
- APPETITE: how much time it’s worth spending and how that constraints the problem
- SOLUTION: core elements, easy to read
- RABBIT HOLES: gory details of solution
- NO-GOS: what’s out of bounds and how we’ll keep it tractable
6.1 The Problem
- It’s all too easy to jump to the solution and imagine that it’s obvious why it’s a good idea. It’s not. Making the problem explicit is also how you assess the solution.
- Also stating the problem clarifies how much it matters, like what users it affects.
- The problem statement might be a single specific story about a shortcoming of the status quo.
6.2 The Appetite
- Think of this as part of the problem definition. Here’s a bad thing about the status quo and we have 6 weeks to fix it. (Or maybe 2 weeks if it’s part of a batch of things for a 6-week cycle.)
- This shuts down speculation about theoretically better solutions. Suggesting those is easy – finding a solution that fits the appetite is hard.
6.3 The Solution
- Shaping means sketching the solution. It’s not ready to bet on if it isn’t shaped.
- Here’s where the spec-writing comes in. It needs good writing that make people grok it. But still not fully to 0.5 on the spec spectrum – no wireframes or high-fidelity mocks.
- Leaving out some detail prevents boxing in the designers/implementers and prevents bike-shedding.
- But need more detail than the hand-written breadboards from the shaping period – those have a “you had to be there” feel.
- A breadboard like this is way too rough/confusing/opaque:
A fat-market sketch like this is not high-fidelity enough:
We want to go up a notch in fidelity but stay fat-markery:
- That lets you imagine how it will work without specifying design details.
- Add a disclaimer in the pitch that, for example, the vertical line divider is not meant as a directive. Clarify how much latitude the designers/implementors have.
- Include visual detail to the extent it’s needed to sell the concept.
- In the fat-marker sketches, use different colors to distinguish material parts of the sketch from annotations that describe it – object vs meta.
6.4 The Rabbit Holes
- Sometimes these are simple clarifications. Anticipate what the designers/implementors might rabbit-hole on and make the call.
6.5 The No-Gos
- This might be pretty similar to identifying rabbit holes.
–
Here are couple example pitches from Basecamp:
The next step is to let everyone read the pitch on their own time. Basecamp does this by making a post the Product Strategy category of their internal forum.
Part 2: Betting
Chapter 7: Bets, Not Backlogs
- Just because someone thought an idea was important months or years ago doesn’t mean we should keep looking at it. This seems to contradict gissue freshening / backlog freshening so I need to think about this!
- “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.”
- Before each 6-week cycle, have a betting table where you decide what goes in the cycle. Review all the pitches that someone is specifically lobbying for right now. These are the potential bets.
- If there’s something amazing that the time isn’t right for, someone who cares about it should just keep track of it on their own and lobby for it 6 weeks later.
- Exceptions to “no backlogs”: Support having a list of requests or issues that users have, or a bug database with things programmers want to fix when they have time. No backlogs means there’s not a single centralized list and none of the other lists are inputs to the betting process.
- Infrequent meetings between Support and Product can help cross-pollenate ideas for what to work on. Support may tell Product that such-and-such is a pain point. Whenever something is proposed as a candidate bet, it’s done with context, by a person, with a purpose.
- Ideas are cheap and accumulate into big piles. The important ones will come back on their own. For example, if it’s a user point that’s impactful enough, users will keep complaining about it.
Chapter 8: The Betting Table
- Standard synchronized periodic 6-week cycles avoids calendar tetris.
- Two-week sprints are too short to get meaningful work done. And the planning overhead is way too high. Not to mention breaking everyone’s momentum so often.
- The 6-week cycle fixes that and it’s still short enough that you feel the deadline looming from the beginning.
- After the 6-week cycle is a 2-week cool-down period with no scheduled work. It’s for meeting and planning the next cycle. Programmers and designers can work on whatever they want during cool-down. They can fix bugs or try new ideas.
- A team is one designer and 1 or 2 programmers, plus a QA person later in the cycle. If the team is doing one project in the cycle, that’s called a big batch team; if multiple 1- or 2-week projects, that’s a small batch team.
- Betting table happens during cool-down and has either new pitches shaped in the last 6 weeks or possibly older pitches if someone specifically wanted to revive them. Again, no backlog grooming for candidates.
- Basecamp’s betting table has the CEO (who in their case is the last word on product), the CTO, a senior programmer, and a product strategist (the author of this book).
- You leave the betting table with a cycle plan.
- Buy-in from the very top is key. No one can interfere with the cycle once it starts.
- “Betting” not “planning” because we expect a payout. Also it’s a commitment to invest the 6 weeks – which is also a cap on the downside if the bet doesn’t pay off.
- No interruptions allowed, not even pulling someone away for “just a day” or even “just an hour”. (This sounds pretty hard to pull off with critical bug reports coming in or autodata partners flaking out or whatever else.) Losing the wrong hour can kill a day, losing a day can kill a week.
- If things do come up, that’s what the next cycle is for. And that’s why you don’t plan farther ahead than the next cycle.
- You can hit the brakes for a real crisis, of course, but true crises are rare.
- The other side of this coin: no extensions! (See also the sunk cost fallacy.)
- This serves as a circuit breaker: one runaway project can’t derail the company.
- Also failing to meet the deadline points to a problem in the shaping. If something doesn’t ship in time, spend the next cycling shaping a new version of it and consider that version for the cycle after that.
- Finally, it’s a commitment device. The team implementing the project has full authority to cut what needs cutting or otherwise do what it takes to get it shipped on time. What’s at stake is that their work won’t ship if it doesn’t ship by the deadline.
- Start every cycle with a clean slate. No carrying over scraps of old work unless you explicitly shape it as a new potential bet.
- If it takes more than one cycle, shape each cycle’s worth separately. [I think I wrote down this point already from one of the first chapters.]
Aside about Bugs
Bugs should be treated like anything else. Unless it’s a true crisis, they can wait and be packaged into the work for the next cycle. Or be dealt with during cool-down. Two weeks every 6 weeks is a pretty decent amount of time for bug fixing.
You can also schedule a Bug Smash – a whole cycle (often around the holidays) – just for fixing bugs.
Chapter 9: Place Your Bets
- Adding to an existing product is like buying a couch that has to fit into an existing room. A new product is like architecting a house.
- R&D mode = learning what you want by building it. So much fuzzier shaping. And it’s the CEO/CTO building it. And the goal for the 6 weeks is a POC or some foundational code, not a working thing.
- Production mode is when there’s enough structure there from R&D mode that it’s like buying a couch, not architecting a house.
- Shipping means merging to master and expecting not to touch it again, not necessarily making it user-visible. (This sounds like a bad definition of “shipping” to me!)
- I like this insight: “There’s something about putting your finger near the launch button that makes your hair stand up. Everything suddenly gets real. Things we dismissed before pop out at us with new importance.”
- That insight is why there’s also Cleanup Mode. That’s a cycle that’s a bit like a bug smash mentioned above in the “Aside about Bugs”. No shaping, no roles, just everyone pitch in and get shit deployed.
- Questions to ask at the betting table: (1) Does the problem matter? Remember to always separate the problem from the solution. (2) Is the appetite right? (3) Is the solution attractive? (3) Is this the right time? (4) Are the right people available?
- Trick to suss out the real reason for an objection about appetite: “What if we could do it in 2 weeks?” If the answer is still no then the true objection probably wasn’t appetite.
- If stakeholders object to the solution, don’t devolve into doing design work at the betting table.
- When the bets are in place, post a kick-off message and let the cycle begin! (Also maybe a kick-off call.)
Part 3: Building
Chapter 10: Hand Over Responsibility
- Don’t split the project up into tasks. That gives people disconnected pieces and they need to see the big picture.
- Testing and QA happen within the cycle; documentation and marketing updates don’t need to, they can happen during cool-down.
- In the first few days, everyone is heads down just figuring out how the existing system works and figuring out where to start. Asking for status reports too early is bad; the honest answer at first is “I’m still figuring out where to start”. After 3 days though, go ahead and ask!
- Imagined vs discovered tasks. Tasks beget tasks. You discover most tasks by diving in on real work.
Chapter 11: Get One Piece Done
- Get something tangible and demoable done in the first week or so. Vertical not horizontal – depth-first not breadth-first.
- First make it work, then make it beautiful. Applies to the back end too. Get things wired together in some expedient way so you can try it. (Similar to the standard startup wisdom: get an MVP, get a few actual users, and iterate.)
- Also in that vein: you don’t want a single handoff between designer and programmer. It should be a back-and-forth as they iterate on the initial crudely working thing.
- Start in the middle: jump to where the most interesting problem is and stub everything else to get you there.
- To spell that out, the place to start is with something that’s (a) core, a sine qua non, (b) small, to build momentum early, and ideally (c) novel, something you haven’t done before. Doing the novel parts first teaches you things and removes more uncertainty.
Chapter 12: Map The Scopes
- Organize by structure, not by person. If you divvy tasks up by person, it doesn’t come together into a working thing early enough.
- You start with an outline of the project, the thing you shaped, then you start identifying tasks which are like little dots inside the outline. Don’t try to arbitrarily group them at first. When you start doing real work on the tasks you see how they’re related. That’s when you can start factoring the project into scopes, like subregions inside the outline of the project as a whole. These are meaningful parts of the project that can be completed independently and in a few days each.
- Pragmatically, scopes are named to-do lists. Those names matter! They become the language of the project – how you talk about what’s done and what’s next and how things connect. This matters for both internal and external communication.
- Scopes should be small enough that important/challenging tasks can’t hide in them unnoticed.
- When you first identify tasks, put them in a to-do list called “Unscoped”.
- Scope mapping isn’t planning: you make the map by walking the territory. You dive into the work and figure out as you go what pieces can be done independently of each other. Those are the scopes.
- Scopes arise from discovered interdependencies. You generally know the scopes around the end of week 1 or start of week 2.
- Scopes are like the project’s anatomy. Signs that your scope is good: (a) you feel like you see the whole project with nothing important hidden in the details, (b) conversations about the project flow naturally because the scopes give you the right language, (c) when new tasks come up, it’s obvious what scope they belong in.
- And signs that your scopes are wrong: (a) you can’t tell how close to done a scope is, which tends to happen when the tasks in the scope aren’t related enough, (b) the names are too generic or not unique to the project; you don’t want grab bag scopes, (c) a scope is too big; it shouldn’t be its own whole project.
- Layer cakes vs icebergs: A project or sub-project is a layer cake if it’s mostly UI work with a thin layer of backend, like a CRUD app. You can judge how hard it by what’s visible. Otherwise it’s an iceberg. Like if a very simple UI form entails a bunch of business logic behind the scenes. Or sometimes you’ll even see an upside-down iceberg where there’s lots of UI complexity but little on the back end.
- It’s ok to have a few loose tasks that aren’t part of a scope. Basecamp calls that a chowder. But if it gets to be more then 3-5 items, probably there’s another scope to be drawn somewhere.
- Prefix nice-to-haves with a tilde. Similar to marking things as mendozas.
Chapter 13: Show Progress
- Asking for progress can feel like nagging. Managers should have visibility into the project without asking. But just seeing the task list isn’t enough. For example, you’re not seeing all the tasks that haven’t been identified yet. Like when you’re just starting, or when you’ve seemingly finished everything and then QA identifies new issues. (See also imagined vs discovered tasks from chapter 10.) Basically to-do lists grow as you make progress.
- Estimates don’t work. They have wildly different confidence intervals depending on experience or what interdependencies it has. And unknown unknowns. Often a true estimate is like “4 hours, or maybe 3 days”.
- Instead: Hill Charts! Divide the project into the uphill half – mostly figuring out what to do – vs the downhill half, actually doing it. Here’s an example with color-coded scopes:
- Basecamp has a built-in tool for making those charts. The left side / uphill is labeled “figuring things out” and the right side / downhill is labeled “making it happen”. You just drag dots representing scopes to whatever point on the hill feels visually/intuitively right.
- Managers can view how those dots are moving over time to see what’s in motion vs stuck. (How to get people to actually update those dots though…)
- The authors claim that no one is willing to raise their hand and say they’re stuck but if you can get everyone to update those dots on the hill chart every day, then the lack of motion of a dot up the hill is effectively a raised hand. And the hill analogy helps the conversation feel better. It’s not you that’s stuck, it’s this scope that needs pushing up the hill.
- Or maybe a scope just appears stuck because it’s not isolated enough. In other words, it points to a needed refactoring of the scopes. If a scope is too big or nebulous then some parts may be over the hill and others not and it’s too hard to place it as a single dot.
- Think of the first 1/3 of the uphill as “I’ve thought about this”, the 2nd 1/3 as “I’ve validated my approach”, and the final 1/3 as “I’ve built enough that there are no more unknowns”.
- Push the scariest scope up the hill first. And push any uncertain work up the hill before pushing anything downhill. You don’t want surprises at the end of the cycle.
Chapter 14: When To Stop
- Review: the shaped work gives you guardrails to keep from wandering out of scope.
- Don’t compare to the ideal, compare to the status quo from the customer’s point of view. (See the Pareto Dominance Principle and mendozas.)
- The end of the cycle is a hard deadline but no cramming – the team should make tradeoffs and question the scope.
- Scope creep! You discover complexities you didn’t anticipate and things that could be fixed or improved while you’re in some corner of the codebase. The team should be empowered to constantly cut growing scope back down in order to meet the deadline.
- Don’t think of it as lowering quality. You’re making the product better at some things instead of other things. That’s what it’s all about.
- Questions for the team to constantly ask themselves: Is this a mendoza? What happens if we don’t do it? Are customers already living with this problem or would it be a regression? How impactful is the problem? How much does the target audience care about this problem?
- Typically marking something a nice-to-have aka non-mendoza means it’s not going to end up getting done during the cycle, which is fine. That’s what makes the mendozas actually get done.
- Basecamp didn’t have a QA role until their userbase was large enough that even tiny corner cases impacted hundreds or thousands of users in absolute numbers. They think of QA as a level-up, not a gatekeeper that all work must go through. In fact, issues discovered by QA are non-mendozas by default.
- Same with code reviews – valuable but not required.
Exceptions to the hard deadline: when to extend the cycle
- It should be very rare – don’t let it become a habit.
- Everything left must truly be a mendoza.
- All remaining work must be downhill. If there’s anything still uphill, it needs to be reshaped.
- Can you wrap it up in the 2-week cool-down? That can be a fudge factor on the 6-week deadline. But dipping into that shouldn’t become a habit either. Something went wrong if that’s needed.
Chapter 15: Move On
- Shipping something creates new work: bugs, related feature requests. But don’t cave to reactivity or spacebar-heating complaints.
- Don’t commit to future work – you need the freedom to shape and bet, not be obligated. The new bug reports and feature requests – after they’re shaped – can vie for a place in the next cycle just like everything else.
Chapter 16: Conclusion
Key concepts and concept handles: shaped vs unshaped work, appetites not estimates, designing at the right level of abstraction (see the spec spectrum), breadboards and fat marker sketches, making bets with capped downside via the 6-week deadline as circuit breaker, uninterrupted time, cool-down period between cycles, breaking a project into scopes, hill charts and uphill vs downhill work and communicating unknowns, and scope hammering.
Appendices
Chapter 17: How To Implement Shape Up In Basecamp
- Create a small team for shaping – could name it something like “Product Strategy” – with just the people who’ll be at the betting table and maybe a few trusted people who can give feedback on pitches.
- Have something like a forum category called “
Pitch” for the pitches. - Create a Project with a name like “Cycle 4: Autopay” for each project in the cycle.
- Post a kickoff message to the forum.
- Create To-Do Lists for scopes. I’m not sure if these map to gissues with task lists or if each scope could be a GitHub Project with items being gissues, or what. They talk about discussion threads for each To-Do Item so I guess that implies gissues.
- (There’s a whole UI for updating the hill charts and adding annotations. Also viewing the history of the updates for seeing how things are progressing up or down the hill.)
- Should we actually try Basecamp?
Chapter 18: Adjust To Your Size
Basic truths vs specific practices
- Shaping is fundamental, worth doing even if it’s just for your future self.
- Same with betting. You don’t need to use a 6-week cycle but you should have a specific pre-determined cycle length.
- Whether or not you use a hill chart, you need to distinguish knowns from unknowns.
Small enough to wing it
Given the low communication overhead and ease of changing direction, you can throw out most of the structure with a tiny team. Just think about what role you’re in at any given time. Set an appetite, shape some work, build it, repeat. Different size bets are fine, you don’t necessarily need fixed cycle lengths or cool-downs.
Shaping, betting, and building are fundamental:
Big enough to specialize
Basecamp has 50 people in the company, about 12 in the product team. I think most of the book is targeted for that size. They need fixed cycles, dedicated shapers, etc. Also they have a dedicated team called SIP – Security, Infrastructure, Performance. I guess that’s Adam in our case. They also have an Ops team that keeps the lights on, as they put it. Also Adam. They also have technical people on the Support team. All of that means that the Core Product team can have 6-week cycles where they’re not interrupted.
With enough people, there are two tracks where the shapers shape while the builders build and the shapers bet during the cool-down cycles:
Chapter 19: How To Begin To Shape Up
Option A: One six-week experiment
- Shape one six-week project. Be conservative! Hofstadter’s Law!
- Don’t worry about the betting part – just shape a project.
- Make sure one designer and 2 programmers can have 6 weeks of uninterrupted time.
- Kick it off by pitching it and emphasize that it’s up to the builders to discover and track the actual tasks.
- Keep the builders in close communication.
- Get One Piece Done: wire UI and code together early in the project. Don’t worry about properly mapping the scopes yet.
Just the uninterrupted time and the pre-shaped work should be huge.
Option B: Start with shaping
If a dedicated 6 weeks isn’t possible, the exercise of shaping a project is still valuable. Even if it’ll realistically end up going into a black hole!
Option C: Start with cycles
Even just switching from two-week sprints to six-week cycles is a Pareto improvement! And it sets the stage for and highlights the value of shaping.
Fix shipping first
None of this matters until you can you get the team into a rhythm of finishing things.
Final tip: don’t worry about possible inefficiencies like finishing early or whether a programmer is blocked waiting for design work or anything like that. What happens at the scale of hours or days doesn’t matter as long as the project gets shipped as intended at the end of the cycle!
That’s it!
There’s also a handy glossary but it seems to be redundant with the list of concepts and concept handles.
Read Basecamp’s “Shape Up”
lol thanks for the flag! 
).
. Now it’s more: LOL! Boss will be super happy when he sees that I did everything I asked! And it won’t even be that hard because I have lots of time and the tasks are easy!
(I think the very best writing on the blog is from 
Is that a 