Shape Up

Below are my notes after reading Shape Up, from Basecamp. This free e-book can be quickly summarized with, “How Basecamp approaches software development.”

Raw Idea

A raw idea is something like, “The customer wants a calendar”. Sometimes the raw ideas are very exciting, but we should temper the expectations.

Define the time around a good idea. Either

Don’t shut down an idea right away, but don’t give the impression of excitement, meaning it will get done.

Take the time to get more information. Talk to the users. Adjust the scope. Get details.


Beware of grab-bags. “Redesigns” or “refactoring”. Caused by a lack of expectations. “Redesign the files” vs. “Add previews to files”.


Appetite is defined as the value of a project. How important is it. How well understood is it? Until it is well understood, you cannot define how much you want it. If you constrain an idea to a Small Batch, is it still as enticing?

Each idea is fixed to a specific timeframe, so you have fixed time but variable scope. If a project won’t fit in 6 weeks, can it be broken up smaller?

Appetite is applied at each part of the process. Even the R&D time. How much appetite should we put in? Given the appetite, how much can we accomplish?

Find the Elements

Closed door exercise without technical experts.

Adds value to the Raw Idea. Can still walk away as not too much has been added. Gives ammunition if we do walk away, to set the appetite later. Keep these organized!

Either work alone, or work with people who work at the same speed / level.

Avoid getting too specific too deep. Stay as high as you can while still answering:

This is not a deliverable! This is an approach for how to solve the problem.


Closed door activity without technical experts. Discuss components, not specific design.

Drawing three things:

Column layout. Place name at the top, and a line. Affordances below the line. Connection lines from an Affordance to a Place.

This is flexible, change as needed. Leave old stuff around.

Fat Marker Sketches

Helps slow down so you’re not jumping ahead to too high of a fidelity.

Visual ideas require drawing. Adding details should be almost impossible. Crank up the size of the marker / pen (in digital).


The output of either is a list of elements. Affordances from either Fat Marker or Breadboarding.

Room for Designers

Leaving out the details leaves the designer free from unintended direction. However, a designer does not need so much freedom that they get lost looking for, “Which is better?”

Risks and Rabbit Holes

Closed door exercise to search out risks and rabbit holes before design begins.

Identifying risks is about depth of the project. What are the rabbit holes we can fall down? What are the stumbling blocks? Is what we’re talking about even possible in the timelines?

This is the time to resolve technical unknowns. The suggestion is to walk through the customer experience in slow motion.

“Out of Bounds” is a set of requirements you WILL NOT include in this specific scope. For example, we may not address adding a second credit card processor to each Payment Collector, when creating the Payment Collectors system. Define that for another scope.

While defining out of bounds is also a good time to cut things back. If a feature is a “nice-to-have”, define it as such, but make it ancillary to the project at hand. Do not list it in the main features.

While defining risks, may need to present the idea to technical experts. Rather than write it up, present it more whiteboard-y. “Keep the clay wet, so they can contribute”. Less “This is something coming”, and more “This is an idea I have, but don’t tell anyone.” Beware “Is this possible?”, as anything is possible. Be more specific. “Is this possible in six weeks?” “Is this possible with pure CSS?” Emphasize that you’re looking for ways this could blow up in your face, not looking for additional scope. Making sure the plan is safe. Shrinking the scope is OK! If they can simplify it, awesome!

Write The Pitch

The pitch puts the breadboarded and shaped feature into a format anyone should be able to understand.


Never present a solution without a Problem. What if this Problem only effects one person, for a few minutes per month. Appetite is a part of the problem statement, as it limits the amount of time to fix the problem.

The Solution outlines what we’re working on, so that nebulous statements like, “The customers don’t like it”, do not pass muster. Add disclaimers where design may be shown in a drawing, but is still flexible.

Pitches should be stored where they can be read asynchronously. Where each better can review in their own time, keeping the “betting” time short.

Bets, not Backlogs

Backlogs take time to maintain. Each better can keep track of the pitches that don’t get implemented. No centralized lists, but each person can keep their own lists to advocate for later.