Heads up! This page uses features your browser doesn't support. Try a modern browser like Firefox or Chrome for the best experience.

New versus existing products

First a word of warning about when shaping, betting, and building won’t work.

If you’re working on a completely new product or using technology that’s entirely new to you, first check to see if the architecture you’re building upon is settled or not. When you haven’t established the basic architecture of the product, it can easily happen that you need to scrap everything and start over a couple times. We call this early phase of a new product “R&D mode.”

In the R&D phase, our goal is to figure out what the right architecture is. You can’t make bets on specific features yet because the ground underneath isn’t solid. Too much is in flux. In this phase, it’s better to build a few features half-way instead of building one feature all the way to completion. Build just enough to gain confidence in the architecture so you can “pour the concrete” and commit to the key points of the overall product design.

In terms of process, approach this phase by making a general bet on the exploratory work. Dedicate one team and six weeks to explore a few tent-pole features and work out how they tie together into the main architecture of the product. The team should combine shaping and building in a blurry mix—sometimes shaping what to do in the next few days, sometimes building out an idea, sometimes scrapping it all and starting over. You don’t want separate shapers and builders at this stage because there are too many unknowns and the feedback loop will be too long and too slow.

There will come a time where it’s reasonable to flip from R&D to “production” mode. This happens when the team who led the exploratory work feels the ground has become firm and can see where the pillars of future features will stand. At this point they’re ready to separate the task of shaping from building and delegate shaped work to other people in the form of bets.

With an existing product, most new work takes place on an established architecture. New features go where there’s “room” in the existing design without breaking up the concrete or drastically changing what already works. But there can still be cases where a particular new area of work has an unsettled architecture. For example, when we built the Hill Chart feature in Basecamp, we had never designed a high-fidelity interface like the one we needed to drag dots along the curve of the hill. The data model was also unlike anything we had done before. We shaped the basic idea, but we didn’t set a hard expectation that the team would finish the feature and deploy. The first cycle was very exploratory and false starts were expected. Later, after we gained more confidence in the prototype, we commited to another more specific bet and set the expectation that the feature would ship after six more weeks of work.

Option A: One six-week experiment

You don’t need to change everything all at once. If the whole product team isn’t ready to make a big change, just start off with a single six-week experiment. These are the steps to take:

  1. Shape one significant project that can be comfortably finished within six weeks. Be conservative and allow extra time on your first run.
  2. Carve out one designer and two programmers’ time for the entire six weeks. Guarantee that nobody will interrupt them for the length of the experiment.
  3. Instead of a proper betting table, simply plan for the team to do the work you shaped for this one experiment.
  4. Kick off by presenting your shaped work to the team, with all the ingredients of a pitch. Set the expectation that they will discover and track their own tasks. (Hand Over Responsibility)
  5. Dedicate a physical space or a chat room to the cross-functional team so they can work closely together.
  6. Encourage them to Get One Piece Done by wiring UI and code together early in the project.

You don’t need to worry about Mapping the Scopes or Showing Progress right away. You should see a big leap in progress just by dedicating uninterrupted time, shaping the work in advance, and letting the team work out the details.

Once the team gets used to Getting One Piece Done, the stage will be set for properly mapping scopes down the road. It’s the same idea, just repeated. Later still, when they are good at defining scopes, you can use the hill chart to Show Progress on those scopes.

This approach lets you demonstrate success with one team and a single six-week commitment. With credibility gained from a good outcome, it’ll be easier to lobby for a bigger change and convert the wider team to working this way.

Option B: Start with shaping

Sometimes it’s not possible to get a team together to work for six weeks because somebody else, a CTO perhaps, controls the programmers’ time. In that case, you can start by shaping a compelling project with clearer boundaries than past projects. Present the project and put it through your company’s existing scheduling process (even if it’s a paper shredder). Better-shaped work can shine a light on the engineering team and help them open up to things like longer cycles or a more deliberate betting process.

Option C: Start with cycles

Another approach is to start by working in six week cycles. For teams that formerly used two-week sprints, this removes the overhead of constant planning meetings and gives programmers more time to build momentum and hit their stride. Once the team has more room to breathe, it’ll be natural to think more about how to shape the work to take advantage of this new capacity.

Fix shipping first

Build your shipping muscles before you worry too much about improving your research or discovery process. You can have the best customer insight in the world, but if you can’t turn it into a project and ship, it won’t matter. First get the team into a rhythm of finishing things. Once you have the capability to ship, then you can start improving the inputs to your shaping process.

Focus on the end result

Sometimes it can be scary to give the teams more free rein to set their own tasks and schedule. You might wonder: What if they don’t use up all the time we dedicate for the cycle? What if one of the programmers or designers sits idle at some point in the cycle?

To overcome these worries, shift the mindset from the micro to the macro. Ask yourself: How will we feel if we ship this project after six weeks? Will we feel good about what we accomplished? When projects ship on time and everyone feels they made progress, that’s the success. It doesn’t matter what exactly happened down at the scale of hours or days along the way. It’s the outcome that matters.

We built Basecamp to execute the techniques in this book. It puts all our project communication, task management, and documentation in one place where designers and programmers work seamlessly together. See How to Implement the Shape Up Method in Basecamp.