1. Introduction

You can think of this as two books in one.

  1. I want it to give you better language to describe and deal with the risks, uncertainties, and challenges that come up whenever you do product development.
  2. The specific processes we’re using at Basecamp to make meaningful progress on our products at our current scale.

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/6cfad75d-780a-48d8-bb79-2e973fa84f60/image_106.png


2. Principles of Shaping

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/26829229-9010-4aff-bdf4-bd8cd6feb6d0/image_1.png

We shape the work before giving it to a team. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves.

When shaping, we focus less on estimates and more on our appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite.

Case study: The Dot Grid Calendar

Soon after launch, customers started asking us to “add a calendar” to Basecamp. We had built calendars before and we knew how complex they are. It can easily take six months or more to build a proper calendar.

Past versions of Basecamp had calendars, and only about 10% of customers used them. That’s why we didn’t have the appetite for spending six months on a calendar. On the other hand, if we could do something to satisfy those customers who were writing us in one six week cycle, we were open to doing that.

We eventually arrived at a promising concept inspired by calendars on phones. We could build a two-month, read-only grid view. Any day with an event would have a dot for each event. A list of events would appear below the calendar, and clicking a day with a dot would scroll the events for that day into view. We called it the Dot Grid.

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/11868314-70a1-4a77-b1ea-93f457b671bc/image_2.png

The Dot Grid wasn’t a full-featured calendar. We weren’t going to allow dragging events between days. We weren’t going to span multi-day events across the grid; we’d just repeat the dots. There’d be no color coding or categories for events. We were comfortable with all these trade-offs because of our understanding of the use case.

Property 1: It’s rough

One can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits everyone to the wrong details.

Property 2: It’s solved