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
- 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.
- 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.
- 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”.
- 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.
- 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.
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
- 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.
- 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.
- 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.
- Sometimes these are simple clarifications. Anticipate what the designers/implementors might rabbit-hole on and make the call.
- 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.
- 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.
- 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.]
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.
- 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.)
- 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.
- 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.
- 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”.
[this is as far as I’ve gotten in the book so far! stay tuned!]