Basecamp is a company known for a few things. Some of these are their smallness, their independence, their success, and their occasional contrarian opinions. They've written extensively on some of their work practices, and on effective methods for small teams, both in books and blogs.

To this collection of insights, Ryan Singer adds an exposition of their product-management practices, called "Shape Up".

What follows are some of my notes on their book describing these practices. Being a summary, these notes are of course not comprehensive. The book itself is relatively short, and easily navigable. It can fill in a more complete picture.

Chapter 1

We don't know if we're going to build the right thing (the author recommends Clayton Christiansen's "Competing Against Luck") but, discovery will improve when we equip teams with Shape Up.

The Shape Up process came about organically through successes with Basecamp and other products. It was formalized as the team grew to 50 people and more. Notably, their first product, the eponymous Basecamp, took just 10 hours per week of DHH's time over a July through February time frame. Key aspects of the method are: high autonomy teams, 6 weeks intervals. By default, the team drops the product if it's no good or incomplete at 6 weeks.

Part 1 of the book is about shaping. In shaping, we set an "appetite", do sketching, and writing a pitch.
Part 2, Betting, is about how to choose among pitched products.
Part 3 is about expectations set on the teams and special practices they use to discover what to do.

Chapter 2: Principles of Shaping

Don't be too abstract (too vague) or too concrete (no creativity for designers, can take more time). Wireframes are too concrete, words too abstract. Good shaping should be rough and bounded.

An Example Singer gives is in addressing customer desire for calendar, but knowing calendars take long to build. The didn't want to build a calendar view 10% of users use, so they built a simplified grid view.

Shaping is closed door, mostly design work, interaction design. It's about:

• What the feature does new.
• How it works.
• Where it fits an existing flows.

It helps in shaping to be  technically literate and know how hard implementation is. Shaping touches on strategic cost considerations, opportunity cost, customer. A shaper may have collaborator. Shapers move fast, speak frankly,  and jump positions.

Steps:

1. Set boundaries.
2. Rough out the elements.
3. Address risks and rabbit holes.
4. Write the pitch.

Chapter 3: Set Boundaries

Appetite is defined with these questions:

• Is it worth a quick fix?
• Is it a big idea worth a whole cycle?
• Would we redesign what we already have to accommodate?

"Small batch" takes one designer and one to two programmers one to two weeks. "Big batch" is the whole six weeks for a same team. This is fixed time, variable scope. The appetite is not an estimate, it's a creative constraint on what we are going to make. You have to make trade-offs because with all time there's always a "better".

Respond to raw ideas with a default "someday". Don't put it on the backlog; wait and see if it's important.

For example: a customer asked Basecamp for more complex file permission roles. The team found someone on customer's team had accidentally archived the file, making it invisible. The team added a warning to the archive button reducing a six-week project to one day.

Beware grab bags like "redesign" or "refactor" or "files 2.0". These are too vague.

Chapter 4: Find the elements.

"This isn’t a spec. It’s more like the boundaries and rules of a game. It could go in countless different ways once it’s time to play."

Questions we are trying to answer:

• Where in the current system does new thing fit?
• How do you get to it?
• What are the key components or interactions?
• Where does it take you?

Shaping involves "breadboarding", a concept that's borrowed from  electrical engineering. In EE, we're not worrying about the clock's case material just it's wiring.

Things we indicate in breadboarding:

1. places - things you can navigate to.
2. affordances - things a user can act on like buttons and Fields.
3. connection lines - how affordances take the user from place to place.

Another shaping technique is a "Fat Marker Sketch" – a sketch done with a big Sharpie so big you can barely write text with it.

With either technique you don't want to say to a designer or programmer: "I know I drew it this way, but ignore that." By that time it's too late, they've already taken it as a direction especially if you're above them in a hierarchy.

Chapter 5: Risks and Rabbit Holes

We're looking for a very low probability of shipping before or after 6 weeks. Rabbit holes are technical unknowns, unsolved design problems, misunderstood interdependencies that make something take a multiple of the original appetite.

Questions when searching for rabbit holes:

• Does this require new technical work we've never done before?
• Are we making assumptions about how the parts fit together?
• Are we assuming a design solution exists that we couldn't come up with ourselves?
• Is there a hard decision we should settle in advance so it doesn't interrupt the team?

For one of Basecamp's projects, they had requests to do a grouping view for to-do lists. It's harder / riskier to do a group view for a to-do list; instead they left it as is and attached group labels to each item to show list groups. The workaround fit appetite. They compromised and they knew it.

Declaring something out of bounds is being upfront and explicit about what we're not doing. Everything is possible but nothing is free, so don't ask "is it possible" But "is it possible in six weeks?" then ask for ideas about risks.

Check in with technical experts. Present all the shaping work up until now then ask for feedback, and do it "conspiratorially". Say, "I'm not ready to present the pitch yet but wanted to get your take."

Chapter 6: Write the Pitch

It has these ingredients:

1. problem
2. appetite
3. solution
4. rabbit holes
5. no goes

The best kind of problem definition is single specific story that shows why the status quo is no good. It gives a Baseline. Pitch specifies whether this will be big/small batch. Wireframes are still too detailed. Breadboards might be too much insider info. A nice midway is fat marker sketches with annotations. We present a pitch asynchronously in a collaboration tool, betting will be synchronous later. Check out some examples.

Chapter 7: Betting

Backlogs are no good. Why look at a big list of ideas from one or more quarters ago? And they waste time grooming, etc.

• Spread our responsibility for prioritizing. If someone likes something that much they can track it in their own way.
• We pick a pitch from the last 6 weeks to bet on, and if it doesn't pass we drop it, track independently.
• Ideas are cheap, they pile up, and good ones will come back.

Chapter 8: The Betting Table

Basecamp's experimentation shows 6 weeks is ideal for cycle length.  Two weeks is way too short to do actual delivery, especially compared with time planning and grooming etc. A cycle must be uninterrupted, which gives programmers and designers time to implement, decide scope trade-offs to fit in 6 weeks.

Momentum is a second-order effect, you can't measure it in one point. The wrong lost hour is a lost day; the wrong day on some bug someone asked a programmer to fix at a moment's notice can be a lost week. It's a rare bug or true crisis that can't wait 6 weeks. It can be shaped into a new pitch if need be, or addressed by a desiring programmer in the cool down period after the cycle.

It's called "betting" versus "planning" because bets have a payout. A bet is on a full chunk of functionality and if the bet fails we have finite loss. Maximum 6 weeks. If it fails, there's probably a problem with shaping (not the team).

At the betting table: It's a one to two hour call, pitches were reviewed on people's own time beforehand. The people present are the CEO, the CTO, senior programmer, product strategist,

• As an aside, team sizes are one to two programmers, one designer and later maybe one QA person.
• A small betting table makes it fast, gives c-level employees a hands-on feeling.
• Any "roadmaps" live in one-on-ones and in people's minds.
• A failed bet is a circuit breaker. No Quagmires. Repitch if needed.

Chapter 9: Place Your Bets

Projects that are entirely new are a bit different from standard Shaping. Basecamp calls this R&D mode. In R&D mode the goal is not shipping but spiking meaning there's some prototyping work happening to test intuitions. The cycles may be a little less formal.

The work in this stage is done by a senior team, in this case, the CTO, The CEO (Basecamp's CEO is design-savvy also), plus maybe a couple of others. "You can't delegate to people when you don't know what you want yourself." Analogy: R&D mode is like figuring out house walls, foundation versus finding a piece of furniture for a gap you measured in the room.

Production mode is when we use standard Shaping. Note: shipping is still different than what one might expect for new products. It means merging to the main master or trunk code and not touching it after.

Before launching is cleanup mode. This is a free-for-all most similar to "bug smash".

• No shaping.
• No clear team boundaries.
• Work is "shipped" in many small bets.
• Should not go longer than two cycles.

As an example, Hey.com an email service, took approximately two years. One year was spent in R&D mode. One year in production mode. The team made no specific long-term commitment to Hey in early cycles. They were still making bets one cycle at a time.

Questions asked at the betting table:

• Does the problem matter?
• Is the appetite right?
• Shaper might need to go back to the drawing board if the pitch is not well articulated, or if more research is needed, or if there's low interest.
• Is the solution attractive?
• Think about what you give up, we're not going into the nitty-gritty of design.

People's availability needs to take into account morale. If someone's been on the same type of work a while they should probably get some new type of work this cycle. Basecamp assigns two teams but you don't have to.

Chapter 10: Hand Over Responsibility

Don't task out the project. Teams want autonomy not to be code monkeys or ticket takers. There are about 3 days early in the cycle where they may be orienting themselves. Note that QA should be accounted for within the cycle also. It's up to the team to hammer the scope to fit within the cycle. Don't bug them for updates, especially not in those 3 days.

Stuff like marketing copy is low-risk, not accounted for in the cycle. Some, or even most tasks will be discovered in the cycle, for example: we add a button, but no good place for it on the mobile version. So we work it in, but now we need to rearrange text to fit things etc.

Chapter 11: Get One Piece Done

Implementation is going to be a frequent back and forth between the designer and the programmer. The first run should be visually bare bones or defaults (it looks like Craigslist). This may take around one week or so, but is a full vertical of functionality.

We don't want a bunch of fully fleshed-out designs for the front end, but you want something working. For example, a button that adds a database record when clicked but does not update the UI layout. Think "affordances before Pixel Perfect screens". Things here should be core, small, novel.

Chapter 12: Map to Scopes

Scopes are sets of related tasks that form a piece of functionality. They're defined as tasks get discovered; tasks get discovered as the work progresses. The team will start out with some unscoped tasks, and be able to segment them into scopes. Basecamp's example was a messaging drafts project with scopes called "reply","save or edit" among others. Scopes are more like archaeology and less like organizing your closet. The scopes often solidify in one to two weeks.

Knowing if Scopes are right:

1. You feel like nothing about the project is hidden in the details.
2. You have more of useful language for the project now.
3. You know where to put new tasks.

Signs that it's necessary to redraw the Scopes:

1. It's hard to say if the scope is done.
2. The name is not unique to a project EG "bugs", "front end". This is a junk drawer.
3. Too big.

Regarding the junk drawer, we can have a "chowder" list, it should be less than 5 items long.

"Layer cakes" are normal business app type functionality where there's equal front-end and back-end work. An "iceberg" is a project with a complex back end. An "upside down iceberg" is a project with a complex UI, eg a calendar.

Chapter 13: Show Progress

Good managers don't like to ask for status updates, they want the team to have autonomy. Basecamp uses "hill charts" to put scopes at the appropriate phase on drawing of a hill, which has a kind of x axis representing level of "known-ness" about the tasks. Early on in a project, there are many unknowns, and a lot of the work is about making knowns with respect to various scopes. About midway (the hilltop), there's a turning point where more confidence around remaining implementation happens. For example:

Unknown is still figuring things out, like what actually needs to be done for a dinner party you're hosting, and known is like cooking the meal.

Hill charts shift the language of status updates from individuals to scopes. Not "why are you blocked here?" but "what needs rescoping or breaking out further here?" or "what needs reshaped?" or "what is a surprise obstacle that can be removed?".

It's better to start with scarier unknowns.

Chapter 14: Decide When to Stop

Don't compare to ideal, compare to baseline. Is the problem more solved than it was before?

The scope creeps and grows. Shaping in a rough way gives the team autonomy to hammer the scope. Cutting scope is differentiation. Differentiation is good for market positioning.

QA is, by default, a nice-to-have. Basecamp has one QA person on a 12+ person product team. The QA person helps a lot but they're not essential to shipping. It's similar for asking for code reviews from the CTO.

Hammer questions:

• Is this a must-have for the new feature?
• Could we Ship Without this?
• What happens if we don't do this?
• Is this a new problem or a pre-existing one customers already live with?
• How likely is this case to occur?
• When it occurs, which customers see it?
• What's the actual impact of It?
• When something doesn't work for a use case, how aligned is that use case with our intended audience?

In very rare cases, we may extend past the circuit breaker. But it must be only 'downhill' work. Otherwise reshape and repitch in the future.

Chapter 15: Move On

Shipping may result in feedback, some of it negative. Give that feedback time and some will die down. Remember what you shipped was a bet. Let it play a bit and leave yourself free for the next cycle and future shaping around with gentle "no"s to customer requests for features or changing things back (continue contemplation of raw feedback, it's a soft no). "Let the storm pass".

Appendix: Adjust to Your Size

Maybe your experience shows a better cycle length than 6 weeks, but you still need the "capped downside" of the circuit breaker. You might not use hill charts but still ought to track unknown versus known.

Tiny teams of two to three can be more fluid or multi role. At a 50-person org like Basecamp, the fluidity of ad-hoc coordination is too much. It's better to do the standard 6 weeks, hill charts etc. Maybe elevate a designer to dedicated shaper or mostly-dedicated shaper.

Appendix: How to Begin Shape Up

The outcome is what matters not what happened exactly at which hours. "Fix shipping first": get the team accustomed to shipping.

Option A: One 6-week experiment:

• Shape one significant project with comfortable completion window.
• No Interruption for the designer and 1-2 programmers.
• Instead of betting table just plan for the work you shaped for this experiment.
• Kickoff by presenting shaped work to the team as a pitch, set the expectation they'll discover their own tracks.
• Dedicate space or a chat room.
• Write UI and code together from the start ("getting one piece done").

Don't worry about mapping scopes or showing progress yet.

Option B: Start with Shaping:

If you can't get six weeks, shape and put into the current scheduling process. Better-shaped work can "shine a light" on the engineering team.

Option C: Start with Cycles:

Teams that used to have two weeks will get new autonomy in six weeks. As their sense of autonomy grows, add shaping.