Studying Shape Up

2026-07-31

Intro

I have always had great admiration and interest in Basecamp, especially in Jason Fried’s work and product vision. Recently, I decided to focus this interest on studying Shape Up, the way the company builds its products.

Uma versão em português desse post também está disponível.

After reading the book and listening to a few podcasts with Ryan Singer (the book’s author), I decided to challenge myself to share my takes and quick summary of the method.

It was a harder task than I imagined. Shape Up cannot be easily summarized in a catchphrase. Instead, it is the result of what I see as several sound premises from a highly efficient and opinionated team that knows how it wants to work.

Although it was somewhat difficult, writing this article was very valuable to me. It forced me to truly interpret and absorb the book’s main concepts and ideas instead of just repeating its proposed rituals.

The result, approximately 2,000 words, was not written in a smooth, straightforward way. I had many false starts and threw away many more words before I managed to find my own way of explaining this methodology.

It is worth noting that I have not yet had the opportunity to apply it in practice. But I noticed that some of its concepts (such as Appetite and good Shaping) have already started to appear in my day-to-day work. At the end, I also reflect on what applying Shape Up might look like in a very small, early-stage team, a challenge I currently face at work.

What is Shape Up?

Shape Up is a product development methodology created by Ryan Singer at Basecamp. It is a way of working focused on building products with small teams.

The central premise of this methodology is the distinction between two moments: Shaping and Building.

Shaping is the moment to look outward. The goal is to explore demands and the situation at hand in order to select the problems that will be tackled. Shaping gives form and scope to problems and possible solutions.

The deliverable from this phase is a document called a Pitch, which contains everything a team needs to build the proposed solution.

This stage is not just about describing an solution idea by oneself. Nor is it limited to a conceptual exploration without getting your hands dirty. It is the moment to put together a coherent and validated project that can be built within a set amount of time. This includes conversations with other teams, technical and operational feasibility checks, usage data analysis, stakeholder approval, and whatever else is needed.

That is why the participation and collaboration of Product, Design, and Engineering are essential at this stage to assess and validate the proposed Projects. It is during Shaping, not during Building, that technical feasibility, rabbit holes, and different solution alternatives should be discussed and explored.

This is a synchronous and loose phase, with many conversations, collaboration sessions, and quick sketches. You should avoid too much formalization and creating documents that constrain your thinking.

During this Shaping period, it is essential to discuss and agree on the Appetite for the project: how much does the company want to invest in this problem?

If resources were infinite, everything (or almost everything) would be desirable, and scopes would tend toward infinity. But in the real world, projects only make sense if they are delivered within a certain amount of time. This means the time-frame question comes before the scope.

After all, the Appetite expresses how much the organization is willing to invest in that initiative, and it translates into a time frame. Most of the time, the problem guides the Appetite, not the solution.

Instead of asking, “How long will this task take?” and making estimates with planning poker, during Shaping we define: “For this problem, we are willing to invest 6 weeks of work, so what solution fits within that time? Is there a 2-week solution?”

Each project receives a fixed time frame, which is not extended. At the end of the Building cycle, the project is closed and another one is prioritized. Taking the time frame this seriously forces teams to make difficult decisions during implementation and be efficient in their choices.

In the real world, simply canceling a project is a very drastic and unfeasible measure in most situations. When something goes wrong during Building and the project is not completed on time, the project usually returns to the Shaping stage. Rather than extending its time frame by default and creating a black hole that sucks in time and resources, the team goes back to discussing and exploring what was missing for a successful delivery.

This is why the Pitch does not present a fully defined final solution, but rather its general shape: what is necessary, which requirements are non-negotiable, and how the solution fits into the whole. The details of the solution will be defined during Building, because only through execution can you dig into and discover all the small realities and corners of the product.

The only requirement for a good Pitch is that it contains everything the team needs to build the proposed solution. That usually means:

The problem and why it matters
The Appetite and delivery time frame
The solution, at the right level of detail
Rabbit holes that have been mapped out
No-gos (what is out of scope)

The right level of detail for the solution is a complex question that depends on the situation. It is more art than science. Sometimes, the solution will need to be very specific and leave little room to maneuver. Other times, the details matter less, but the main goal should always be clear.

In general, we want a Pitch with a high-level solution design. All essential components have been validated and are feasible; the silhouette of the solution and its non-negotiable requirements are clear. The final shape and details will be the team’s responsibility during Building, because we trust the team to understand the problem and make the best decisions and tradeoffs to deliver the project on time.

Notice that, during Shaping, the project is not broken down into individual tasks or tickets. That is the team’s responsibility during Building.

If Shaping is about looking outward, Building is about focusing inward. During this phase, the team receives a clear and well-defined Project and aims to execute its vision. Work is more asynchronous in this phase, and team members have long periods without interruptions.

I like to think of these two moments as building on a physical plot of land. During Shaping, we define the outer boundary of the territory and how the Project will relate to its neighbors. During Building, the team already has defined boundaries and a few rules, but it is free to build the interior in whatever way it considers best, with the goal of solving the selected Problem within the defined Appetite.

This obviously does not mean that, during Building, the team can deliver whatever it wants, cut scope without justification, or settle for low quality. After all, the goal, the rules, and the general shape have been defined. Shape Up trusts the team and gives it autonomy, based on the principle that, with good Shaping before hand, its members will do their best work within the constraints and deliver the Project on time, even if they need to face difficult tradeoffs along the way.

The main rule of the Building track is: the project is only considered delivered once it is finished and in production. There are suggestions for how to work and organize this phase, but each team will have its own rhythm and preferred way of working to deliver the mission it has been given. And if Shaping was done well, the team will have all the pieces it needs to do good work.

During Building, the team should have the autonomy to take the project from start to finish without depending on external factors. Occasional questions, help, and validation are acceptable, but if the team needs to validate an important concept or gets stuck waiting for a request from another team, there is a flaw in the process.

Supporting tasks, such as updating documentation or training materials, can be done during Cool-down periods.

Unlike Scrum, which is based on tickets and tasks, with short sprints (usually two weeks) and several planning meetings, retrospectives, and dailies, Shape Up works with longer cycles and Cool-down periods for readjustment.

At Basecamp, teams work in standard 6-week cycles followed by 2-week Cool-down periods. Projects can be large and take up the full 6 weeks (but never more than 6 weeks), or smaller, with several projects allocated to the same cycle.

During Building cycles, the team works exclusively on the assigned project and cannot divert its attention to other matters. During Cool-down periods, the team has no project assigned and can work on one-off matters and turn its attention to other things.

It is a good time to tie up loose ends, complete tasks or handle one-off requests, and prepare for the next cycle of focused work.

At Basecamp, Shaping and Building are conducted in two parallel tracks by different people. While one team is in the Building cycle, strategic leadership is working on Shaping the next Projects.

One striking difference between Scrum (and other similar methodologies) and Shape Up is how the types of work are distributed over time. While in Scrum the team plans and executes at the same time, taking part in several recurring rituals in short bursts, Shape Up separates these two moments. During Shaping, there are many meetings, conversations, back-and-forth, and fewer periods of uninterrupted focus. It is also normal to conduct studies and analyses or build prototypes (proof-of-concept code that will be discarded).

Once the Project has been defined and handed off to Building, work becomes much more asynchronous, with long periods of uninterrupted focus and few interactions with other teams.

When not to use Shape Up

Shape Up is based on projects and a clear Shaping period. It is a good fit for proactive work.

When work is reactive or depends on close coordination and joint execution with another team (or client), it is better to use a traditional ticket/task-based method.

For example: support work, being on call to fix critical bugs, or implementations with clients. In these cases, there is not enough time or clarity to Shape the problem and the solution.

Very early-stage and exploratory products do not seem like the best fit for this methodology either. Although Basecamp uses an adapted version, I would try to apply only the ideology and concepts behind Shape Up without worrying about the formal process just yet.

Adjustments for a small team

With a very small team (2 or 3 people), it would probably not make sense to implement two independent Shaping and Building tracks. Therefore, I also do not think that fixed 6-week cycles make sense.

We will probably alternate the same people between the two phases. So, the tendency is for us to have cycles and Cool-down periods of varying lengths.

First, we explore a situation and Shape the project, with no fixed deadline for this phase and with the goal of making a good Pitch. During this phase, we are not concerned with building and executing.

Once we manage to finalize and approve a Pitch, we switch our way of working to Building. Now, we dedicate our time exclusively to the assigned Project: we “put our heads down” and “look inward.” The goal is to deliver what was agreed within the deadline.

After the cycle ends, we return to the Cool-down period and begin Shaping the next project as soon as possible.

Because we make up the entire department, being exclusively allocated to a single Project for several weeks may not be feasible. In that case, we could choose one day of the week as “outside the cycle” and use that day exclusively for matters outside the Project.

For example, we could keep Fridays open for conversations and tasks that come from other teams, turning down (as much as possible) anything outside our focus on the other days of the week.

In this case, more than following the processes, I think the greatest value lies in the concepts: trying to Shape and validate a good project before moving on to Building, making the Appetite clear, and avoiding the trap of creating projects with infinite scope.

Summary and key terms

Shaping

The moment to “look outward.” It includes a great deal of exploration and collaboration with other teams. The work is more synchronous, with long sessions of collaboration and ideation. The goal is to select and clarify a problem, understand the Appetite for it, and propose and validate a solution.

Building

The cycle’s period of focus. The work has a more asynchronous and convergent rhythm. The goal is to turn the Pitch into something concrete and deliver the feature to production.

It is important that the team does not do Shaping and Building at the same time. They can happen in parallel, but with different people.

Appetite

How much the company is willing to invest in a problem/situation. This willingness translates into the time frame that will guide what can be done in a project. The Appetite guides the scope, rather than the scope defining the time frame. With a clear Appetite, the team has freedom and autonomy, but is forced to make difficult choices that guarantee delivery within the expected time, avoiding delays, unpredictable deliveries, and endless projects.

Cool-down

This is the moment to step away from the project’s exclusive focus. The team is free to look at other fronts and work on matters that were not Shaped, without having to justify the effort with bureaucracy or formalities.

It is a moment to catch your breath, tie up loose ends, and prepare to execute the next cycle.