When shaping, flesh out the risks and the likely implementation 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."
In the shaping phase, pre-solve problems that wouldn't be fair for a designer or engineer to try
and solve in the pressure of a cycle without introducing lots of delivery risk.
A pitch needs a solution. "A problem without a solution is unshaped work. Giving it to a team
means pushing research and exploration down to the wrong level, where the skillsets, time limit,
and risk profile (thin vs. heavy tailed) are all misaligned."
On backlogs: they don't use them. People track things their own way in independent lists, and
every six weeks, whatever is shaped, fresh, and urgent/important is brought up by team members to
the "betting table" to be considered for the upcoming cycle.
Intro
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."
Shaping the work
A small senior team works in parallel to the "cycle team" (the team working on the cycle/sprint)
to shape and vet the next set of bets. It's the "pre-work."
Targeting risk
The greatest risk is 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."
Principles of Shaping (chap 1)
Spectrum of projects: abstract <-> shaped <-> concrete
Wireframes are too concrete, and words are too abstract.
Property 1: it's rough
The advantage of a rough spec is that the team can see the open spaces where their contributions
will go. Leave them room to apply their own expertise.
Property 2: it's solved
The overall solution is spelled out. The solution elements are connected.
Property 3: it's bounded
The idea's definition and scope matches the appetite the company has for it.
Shaping is 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?"
Shaping is a closed-door, creative process.
There are two tracks here: one for shaping, one for building.
When shaping, flesh out the risks and the likely implementation 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."
Set boundaries (chap 2)
The appetite: the time budget for this idea.
There's two appetite sizes:
Small batch: a project that can be built in 1-2 weeks by a team of one designer and 1-2
programmers. A few of these are batched together into a six week cycle.
Big batch: the project can be built in six weeks by the same size team.
Fixed time, variable scope
"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."
Set a time box and maximize what you can do within it.
Also cap the shaping/research investment: "if it's not critical now and we can't get our hands
around the problem, we'll walk away from it and work on something else."
(Isn't the idea of an "appetite" backwards for some types of work? If the descoped solution
doesn't hit the business objectives, then its value may be zero, and thus so will be its
appetite).
Find the elements (chap 3)
Leave room for the designers
"Regardless of what you say, any specific mockups are going to bias what other people do after
you — especially if you're in a higher position than them. They'll take every detail in the
initial mockups as direction even though you didn't intend it."
Fat-tipped markers elevate the level of abstraction, leaving room for the designer to make it
concrete.
Provide the boundaries and rules for the game, not a spec.
Risks and Rabbit Holes (chap 4)
The ideal delivery time distribution is tall and narrow, with its center at the appetite size (six
weeks, in their case).
The distribution is long-tailed to the right if there's unidentified/unsolved rabbit holes when it
goes to the implementation team.
In the shaping phase, pre-solve problems that wouldn't be fair for a designer or engineer to try
and solve in the pressure of a cycle without introducing lots of delivery risk.
Declare out of bounds
"It's still a good idea to call out any cases you specifically aren't supporting to keep the
project well within the appetite."
Builders will naturally try to cover every case, and make the solution excessively complete.
Help them out.
"Instead of asking 'is it possible to do X?' ask 'is it possible to do x in 6 weeks?' That's a
very different question."
Tactically, keep the clay wet by discussing at a whiteboard, not over a fleshed out doc or deck.
The Pitch is "a document that we use to lobby for resources, collect wider feedback if necessary,
or simply capture the idea for when the time is more ripe in the future." It then gets presented
to the betting table.
Write the pitch (chap 5)
A pitch has these components
Problem
Appetite: how much time we want to spend and how that constrains the solution
Solution
Rabbit holes: details to avoid
No-gos: anything specifically excluded from the concept
A pitch needs a solution. "A problem without a solution is unshaped work. Giving it to a team
means pushing research and exploration down to the wrong level, where the skillsets, time limit,
and risk profile (thin vs. heavy tailed) are all misaligned."
Help the team see it: you need to provide enough visual detail to help sell the concept to the
betting team.
Presenting a pitch: review and comment on the pitch doc asynchronously; then debate it live at the
betting table.
Bets, not backlogs (chap 6)
Backlogs
"Backlogs are a big weight we don't need to carry."
"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 time wasters. The time spent constantly reviewing, grooming and organizing old
ideas prevents everyone from moving forward on the timely projects that really matter right
now."
At six week boundaries, host a "betting table". It's a dispassionate review of where to place your
chips.
"At the betting table, they look at pitches from the last six weeks — or any pitches that
somebody purposefully revived and lobbied for again. Nothing else is on the table."
Each option on the betting table is well-shaped and risk-reduced.
There is no organized view of the likely bets beyond 6 weeks.
"What if the pitch was great, but the time just wasn't right? Anyone who wants to advocate for
it again simply tracks it independently — their own way — and then lobbies for it six weeks
later."
Decentralized lists
The support team keeps a list of requests or issues that come up more often than others. Product
managers track ideas they hope to be able to shape in a future cycle. Programmers maintain a
list of bugs they'd like to fix when they have some time.
"This way the conversation is always fresh. Anything brought back is brought back with a context,
by a person, with a purpose. Everything is relevant, timely, and of the moment."
Important ideas come back
Rare bugs will fade. Annoying bugs will keep getting encountered.
The betting table (chap 7)
Six week cycles
Working in cycles simplifies the resource availability constraints. Everyone frees up at once.
"A cycle gives us a standard project size both for shaping and scheduling."
Says two week sprints are too little for shipping big things and there's too much planning
overhead.
Cycles need to be short enough to see the end from the beginning, but long enough to allow for
substantial momentum.
Cool down
They allocate two weeks after each cycle for cooldown. People can work on whatever they want.
Bugs, POCs, mocks.
"After working hard to ship their six week projects, they enjoy having time that's under their
control."
(I wonder if the cool down period becomes the overflow for "quality work", where engineers go
back and fix the corners that were cut? Is that a bad thing? It seems refreshing to have
specific time to do this type of work earmarked.)
Standardized team sizes
Each team is 1 designer and 1-2 engineers.
"Big batch" teams spend 6 weeks on a project.
"Small batch" teams use the cycle to do several 1-2 week projects.
1-2 hour meeting. "Pitches" are available to review offline, beforehand.
A well set up betting table gives leadership a "hands on the wheel" feeling of control.
"The meeting is short, the options well-shaped, and the headcount low. When these criteria are
met, the betting table becomes a place to exercise control over the direction of the product
instead of a battle for resources or a plea for prioritization."
The meaning of a bet
It's a bet, not a plan.
The downside is capped to 6 weeks.
Bets have a payout, and thus ROI.
Bets are commitments of six weeks of focus.
Uninterrupted time: "It's not really a bet if we say we're dedicating six weeks but then allow
a team to get pulled away to work on something else."
They only select bets for one cycle ahead, so they can react to big new needs with a max latency
of six weeks.
Circuit breaker
There's an explicit policy that projects can fail if they exceed the appetite.
If a project runs over, it's paused, and gets put back on the shaping track for the following
cycle. Assuming it gets reshaped, then in six weeks time, the newly reshaped, derisked version
is available for consideration at the betting table.
"The circuit breaker motivates teams to take more ownership over their projects" and get them
shipped.
Bugs: prioritize non-P0 bugs in the normal batch cycle schedule, and assign them to small-batch
teams.
The advantage of considering big bugs at the level of the betting table:
"Time should always be used strategically. 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."
Break big projects into six week chunks. Shaping just one six week milestone at a time lowers the
risk.
Place your bets (chap 8)
Their expectations and approach to cycles differs based on whether it's an existing product or new
product.
R&D mode
When in R&D mode, instead of an outcome, just commit time for a spike.
A senior team (the founders, in their case) do these R&D cycles. Once the project is derisked
and transitions out of R&D into production, other teams come in.
"First, you can't delegate to other people when you don't know what you want yourself. Second,
the architectural decisions will determine what's possible in the product's future — they
define the 'holes' that future features fit into. At this phase the team needs to hold the
vision of the product and be able to judge the long-term effects of design decisions."
Jason, David, and a senior designer spent a year exploring HEY.com and settling the core. Then
another year to productionize it.
"The betting table didn't know they would be working on HEY for two years during those first
few R&D cycles. Gradually they gained confidence in the idea and grew a big-picture appetite
for how many cycles they were willing to spend on HEY."
Production mode
Developing an existing product.
When to exit from R&D mode and enter Production mode: "The product does those few essential
things that define it, and the foundation is laid for the dozens of other things we'll have to
do before we can ship to customers."
Cleanup mode
Reserving capacity before launch for the million things that are unexpected.
Consider making some cuts in the cleanup phase to reduce some of the post-launch support burden.
"A smaller surface area on a V1 means fewer questions to answer, less to support, and less
we're committing to maintain indefinitely. 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."
Questions to ask
Is the solution attractive?
The presence of complexity should reduce appetite.
Is this the right time?
Sometimes you need to introduce fresh new features, and sometimes you're in a season where you
need to pay debt.
Hand over responsibility (chap 9)
Let the team define their own approach. Risk-reducing via oversight might not be worth it.
Deploy and Q&A needs to be in cycle.
Docs and announcement are not done in the cycle.
"Those are thin-tailed from a risk perspective (they never take 5x as long as we think they
will) an are mostly handled by other teams. We'll often take care of those updates and publish
an announcement about the new feature during cool-down after a cycle."
Getting oriented: the first few days of a cycle are reviewing the current system and finding the
best entry point.
(Why don't they do this technical design before the cycle starts, to further derisk the cycle?)
Argues that you can't do sufficiently good task breakdowns until you start implementing. Then you
discover all kinds of work.
Get one piece done (chap 11)
Integrate vertically — one "slice". E.g. do both the frontend and the backend, rather than just
one.
Demo something early.
Start in the middle: hack on the interesting, meaty bit first. Derisk the most risky part.
Map the scopes (chap 12)
Don't group tasks by person/role as the primary means of organization.
"People will complete tasks, but the tasks won't add up to a finished part of the project early
enough."
"Scope map": breaking a project into scopes (complete features / vertically-integrated slices),
and tackling each scope in sequence.
The set of scopes you pick becomes the language for the project: which things you group together
as distinct features, the labels you use for those things. This language determines how the work
is organized, and how progress is reported.
The recommended workflow is to generate many unscoped tasks, and then group them into scopes, and
run at the first one.
Discovering scopes
This is mapping out "the anatomy of the problem."
"Scope mapping isn't planning. You need to walk the territory before you can draw the map."
"The scopes need to be discovered by doing the real work and seeing how things connect and don't
connect."
You can't see the interdependencies during the planning phase. You see them after week one or
two.
A poorly defined scope is one which has a name that is not unique to the project. E.g. "front-end
work", "bugs". They're grab bags.
Show progress (chap 13)
Work is shaped like a hill
The first, uphill phase is figuring out what to do. This phase progressively eliminates
unknowns.
The second, downhill phase is execution: getting it done.
"The uphill phase is full of uncertainty, unknowns, and problem solving. The downhill phase is
marked by certainty, confidence, seeing everything, and knowing what to do."
At Basecamp they project status by plotting each scope on a "hill diagram", to convey which part
— eliminating uncertainty, or execution — a scope is in. This is easy for the cycle team to do,
and doesn't rely on fleshed out TODO lists or estimates.
Comparing hill charts over time to see which scopes the team is focusing on, and what's gotten
stuck, is a powerful view.
Management should step in and troubleshoot or rework the project when a scope is getting stuck in
the uphill portion.
Prioritize derisking, which means getting the hardest scopes to the top of the hill before doing
the easier downhill portions.
Decide when to stop (chap 14)
Summary thus far: "when the end of the cycle approaches, the techniques we covered so far will put
the team in a good position to finish and ship. The shaped work gave them guard rails to prevent
them from wandering. They integrated one scope at a time so there isn't half-finished work lying
around. And all the most important problems have been solved because they prioritized those
unknowns first when they sequenced the work."
When deciding whether it's good enough to ship, compare to the baseline
"Compare down to the baseline of what the product is today, not up to the ideal of what you
intend to make it."
This helps overcome the desire to ship the perfect version of a new feature.
Six-week time box: "without a deadline, they could easily delay the project for changes that don't
actually deserve the extra time."
Scope grows like grass; it's natural, and it's no one's fault.
Scope hammering: "Chiseling scope down as the deadline approaches"
"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."
The act of marking unfinished tasks as nice-to-have is scope hammering. These tasks wait until
the end of the cycle to get done, and only if there's time.
QA is for edge cases
Basecamp has millions of users, and a 12 person product team behind it. There's 1 QA person. The
QA person's job is only to check edge cases. Developers take responsibility for the main cases.
"QA generates discovered tasks that are all nice-to-haves by default. The designer-programmer
team triages them and, depending on severity and available time, elevates some of them to
must-haves."
Move on (chap 15)
Feedback needs to be shaped: don't immediately act on feedback from customers about a
newly-launched feature.