I just finished reading Shape Up and wanted to share some quick takeaways before diving deeper into it. The book is about efficient product development that has worked for building Basecamp. The process involve the acts of shaping, betting and building and they happen around or during a six week cycle. Six weeks is the sweet spot that people at Basecamp came up with to get something meaningful done.

First up, we have the act of shaping work. It is a form of strategic thinking done by product leaders where they come up with features, improvements or tasks in general that are time boxed to fit an appetite. Appetite is the amount of time the team wants to spend on a project as opposed to an estimate. Shaped work is rough, solved and bounded. It is a closed door effort by one or two leader that may or may not later be shared. During shaping, leaders try to avoid coming up with high fidelity mockups and instead do “breadboarding”(placing and connecting “affordances”) or fat tip marker sketches. At the end of this process there is a written pitch with rough elements that address the risks involved along with the boundaries.

Once the ideas are shaped the leadership comes together to “bet” on them. It is an interesting concept where the most promising prospects are bet on for the next six weeks. The book introduces the concept of a “circuit breaker” here— the shaped work must be completed within the appetite or it gets dropped. This gives more value to the bets and is a mechanism against runway projects. During betting the problem, appetite, solution and risk profile is discussed and the problem significance, solution attractiveness, timing, and team availability is put into consideration.

Once the project and team is bet on the ownership of the work is handed over to the team. The composition of a team varies but would typically have one designer and one developer. The work starts off with a bit of private exploration by each team member. The book focuses a lot on how the only way to know what needs to be done is by doing the actual work. Getting something done gives positive feedback and a feel for what different things to consider. While this happens it is important to complete vertical slices of the work that include both backend and frontend.

Instead of having a long list of things to do, which is typically what the team starts with, the team creates scopes within the project. Scopes are meaningful parts of the project that are independent from each other. Once scoped out, the book introduces a hands off approach to tracking project progress with hill charts. Uphill work refers to items that are in the exploration phase and downhill work are items that are sufficiently explored enough to have no hidden complexities. The idea is that by just looking at a hill chart the manager can understand how far along the project is and if there needs to be any intervention.

Depending on where you are with the product itself and how big the team is the book suggest flexible ways to adopt these teaching. When working on a new product they transition between R&D mode, production mode, and clean-up mode. If the team is small enough you could do away with certain aspects like betting and the six week cycles, for example. After a six week cycle there is typically a cool down period where teams could do bug bash.

There is a lot more information in the book that I could not discuss here. If this sounds interesting I would encourage you to give the book a read. In a future blog post I would like to dive a bit deeper into what I think of these suggestions and if they make sense to me.