Place Your Bets

Look where you are

Depending on whether we’re improving an existing product or building a new product, we’re going to set different expectations about what happens during the six-week cycle.

This invites us to reflect on where we are in the arc of our product’s development and bet accordingly.

Existing products

When we add features to an existing product, we follow the standard Shape Up process: shape the work, bet on it, and give it to a team to build. We expect the team to finish and ship some version of the shaped work by the end of the cycle.

On an existing product, all of the existing code and design that isn’t going to change defines a kind of empty space that the new feature will fit into. Shaping and building is like crafting a piece of furniture for a house that is already built.

New products

New products are different. Whereas adding to an existing product is like buying a couch for a room with fixed dimensions, new product development is like figuring out where the walls and the foundation should go so the building will stand.

We’ve noticed three phases of work when we build a new product from scratch. In each phase, the way that we shape and our expectations for how the team will work together during the cycle are different. These phases unfold over the course of multiple cycles, but we still only bet one cycle at a time.

R&D mode

At the very earliest stages of a new product, our idea is just a theory or a glimmer. We don’t know if the bundle of features we imagine will hold together in reality, and the technical decisions about how to model them in code are even less clear.

This means there is a lot of scrapwork. We might decide half-way to standing up a feature that it’s not what we want and try another approach instead.

In other words, we can’t reliably shape what we want in advance and say: “This is what we want. We expect to ship it after six weeks.” We have to learn what we want by building it.

We call this stage R&D mode and adjust for it in three ways.

1. Instead of betting on a well-shaped pitch, we mainly bet the time on spiking some key pieces of the new product idea. The shaping is much fuzzier because we expect to learn by building.
2. Rather than delegating to a separate build team, our senior people make up the team. David (CTO) takes the programming role and works with Jason (CEO and designer) or a senior designer with Jason’s guidance. This is necessary for two reasons. First, you can’t delegate to other people when you don’t know what you want yourself. Second, the architectural decisions will determine what’s possible in the product’s future — they define the “holes” that future features fit into. At this phase the team needs to hold the vision of the product and be able to judge the long-term effects of design decisions.
3. Lastly, we don’t expect to ship anything at the end of an R&D cycle. The aim is to spike, not to ship. In the best case we’ll have some UI and code committed to serve as the foundation for subsequent work. The goal is to learn what works so we can commit to some load-bearing structure: the main code and UI decisions that will define the form of the product going forward.

We can’t ship anything to customers with just a single cycle of R&D work. But we still don’t commit to more than one cycle at a time. We may learn from the first cycle that we aren’t ready to tackle the product yet. Or we may discover that our intuition rang true and the product is coming together. Depending on how it goes, we’ll decide cycle-by-cycle whether to continue spending informal time in R&D mode.

Production mode

If we continue to get warmer after some R&D cycles, we’ll eventually reach a point where the most important architectural decisions are settled. The product does those few essential things that define it, and the foundation is laid for the dozens of other things we’ll have to do before we can ship to customers.

With this structure in place, the senior team can bring in other people to contribute. This is the flip to production mode, where we work in formal cycles with clear-cut shaping, betting, and building phases. Production mode is like working on an existing product: the precedent set by the R&D work enables new contributors to identify where new functionality belongs and how it fits into the whole.

In production mode:

1. Shaping is deliberate again. The shaped work describes what we expect to see at the end of the cycle.
2. The team that builds the projects is no longer limited to the senior group. It becomes possible to bet multiple teams in parallel (if you have them) and cover more ground.
3. Shipping is the goal, not spiking. But because the product isn’t publicly available to customers yet, we define ‘shipping’ differently. Shipping means merging into the main codebase and expecting not to touch it again.

Since we aren’t shipping to customers at the end of each cycle, we maintain the option to remove features from the final cut before launch. This means we can still be experimental. We can bet six weeks on a feature without knowing if we’ll want it in the final product. That’s not a problem as long as we set expectations to the build team: we can’t predict what we’ll want in the final cut, and we’re willing to risk this cycle to take our best swing at the idea.

Cleanup mode

In the final phase before launching the new product, we throw all structure out the window. We call this cleanup mode. It’s a free-for-all. We’ve built enough new products to learn that there are always things we forget, things we miss, details that aren’t right, and bugs that creep in over the course of the R&D and production mode cycles.

There’s something about putting your finger near the launch button that makes your hair stand up. Everything suddenly gets “real.” Things we dismissed before pop out at us with new importance.

That’s why we reserve some capacity at the end for the unexpected. In cleanup mode:

1. There’s no shaping. The cycle is closer in spirit to the “bug smash” mentioned in the previous chapter. Leadership stands at the helm throughout the cycle, calling attention to what’s important and cutting away distractions.
2. There aren’t clear team boundaries. Everyone jumps in to help however they can.
3. Work is “shipped” (merged to the main codebase) continuously in as small bites as possible.

Discipline is still important. We have to check ourselves to make sure these are must-haves we’re working on, not just our cold feet begging us to delay launch. Cleanup shouldn’t last longer than two cycles.

Cleanup is also the phase where leadership makes those “final cut” decisions. A smaller surface area on a V1 means fewer questions to answer, less to support, and less we’re committing to maintain indefinitely. Sometimes we need to see all the features working as a whole to judge what we can live without and what might require deeper consideration before shipping it to customers.

Examples

The Dot Grid Calendar

We built the Dot Grid Calendar (see Chapter 2) for Basecamp, an existing product. We shaped the project, bet six weeks on it, a team built it, and then we shipped it straight to customers.

A new product: HEY

In 2020, after two years of development, we launched a new email app and service called HEY. HEY was in R&D mode for the first year of its development. A team of three, Jason (CEO), David (CTO), and Jonas (senior designer) explored a wide variety of ideas before settling on the core. Nearly a year of production mode cycles followed, where all of Basecamp’s teams fleshed out HEY’s feature set. We ended with two cycles of cleanup and significantly cut back the feature set to launch in July 2020.

To be precise, there was some overlap between R&D and production mode after that first year. Basecamp was big enough as a company that the senior team could shape and delegate production-mode projects around parts of the app that were settled while continuing to explore new territory in R&D mode themselves.

Every bet on HEY was placed one at a time. The betting table didn’t know they would be working on HEY for two years during those first few R&D cycles. Gradually they gained confidence in the idea and grew a big-picture appetite for how many cycles they were willing to spend on HEY. But they made no specific commitments about what would go into those cycles. And flipping attention back to Basecamp, our existing product, was always on the table.

An experimental feature: Hill Charts

A third example shows some grey area. When we built the Hill Charts feature in Basecamp (see Chapter 13), we had no idea if it was going to work out or not. Basecamp was an existing product, and it felt too risky to bet on releasing this experimental feature to customers. So we framed the project more like a production mode bet on a new product. We shaped a first version that was just functional enough to use ourselves. We didn’t expect to ship it to customers without doing an additional cycle on it. This was a risk: we bet one cycle, not two. If it didn’t work out, we’d scrap it. If something more important came up, we might not ever schedule the second cycle. But we ended up feeling confident after the first cycle. We shaped a project to round it out, decided to bet another cycle, and then shipped it to customers.

Questions to ask

Here are some common questions you might hear when people at the betting table are debating which bets to place.

Does the problem matter?

Just like in pitch write-ups, we always take care to separate problem and solution. The solution doesn’t matter if the problem isn’t worth solving.

Of course, any problem that affects customers matters. But we have to make choices because there will always be more problems than time to solve them. So we weigh problems against each other. Is this problem more important than that problem right now?

How the people at the table judge problems depends on their perspective, role, and knowledge. For example, a problem might impact a small segment of customers but put a disproportionate burden on support. Depending on your exposure to support and which aspect of the business you’re focused on, you may weigh that differently.

Sometimes a solution that is too complicated or too sweeping may invite questions about the problem. Do we really need to make so many changes across the app? Have we understood the problem specifically enough? Maybe there’s a way to narrow it down so that we get 80% of the benefit from 20% of the change.

Is the appetite right?

It’s good when we have a solution shaped to a reasonable time frame, like two or six weeks. But we might still debate whether it’s worth the time. Suppose a stakeholder says they aren’t interested in spending six weeks on a given pitch. The negotiation could go a couple directions from there:

1. Maybe the problem wasn’t articulated well enough, and there’s knowledge that the shaper can add to the conversation right now to swing opinion. For example, “Yeah it doesn’t happen often, but when it does people are so vocal about it that it really tarnishes perception of us.” Or “Maybe it sounds trivial, but support has to go through 11 time-consuming steps to get to resolution.”
2. Sometimes saying “no” to the time commitment is really saying no to something else. Maybe there’s something about the solution or the technical implementation they don’t like. Asking “How would you feel if we could do it in two weeks?” can uncover that it’s not so much about the time. The CTO might answer, “I don’t want to introduce another dependency into that area of the app.”
3. The shaper might just let the idea go if interest is too low.
4. The shaper might go back to the drawing table and either work on a smaller version (for a shorter appetite) or do more research if they believe the problem is compelling but they weren’t armed well enough to present it.

Is the solution attractive?

The problem may be important and the appetite fair, but there can be differences about the solution.

For example, adding interface elements to the screen carries an invisible cost: giving up the real estate. A button in the corner of the home page might perfectly solve the problem. But that real estate is valuable. If we give it up now, we won’t be able to use it in the future. Are we selling it too cheaply to solve this particular problem?

If someone offers an immediate design solution, like “how about we move that button to an action menu instead,” we might discuss it. But generally we’ll avoid doing design work or discussing technical solutions for longer than a few moments at the betting table. If we catch ourselves spending too much time in the weeds we’ll remind ourselves “okay, we’re not doing design here” and move back up to the high level.

Is this the right time?

The kind of project we want to do next can depend on which projects we’ve done recently. Maybe it’s been too long since we’ve made a splash of news with a new feature. Or perhaps we’ve been building too many new features and feel overdue to fix some long-standing customer requests. Or if the teams spent the last couple cycles in the same area of the app, their morale may dip if we plan yet another project doing the same kind of work.

Those are all reasons that we might pass on a project even though it’s perfectly well shaped and valuable. The project’s great; it’s just not the right time.

Are the right people available?

As part of the betting process we choose who specifically will play which role on each team. That is, we’ll pair a project with a specific small team of a designer and one or two programmers. We have a “Core Product” team of designers and programmers and we select from that pool when planning teams for each cycle. The team will work with each other for the whole cycle and then the next cycle can be a different combination of people.

Different projects require different expertise. Maybe we need some more front-end programming on this one. Or this other one is going to invite a lot of scope creep so we need someone who’s good with the scope hammer.

The type of work each person has been doing is another factor. Someone who’s done a long string of small batch projects might prefer to take on a big batch, or vice versa.

And lastly there’s always a little Calendar Tetris with peoples’ availability. Vacations or sabbaticals affect which projects we can schedule in the coming cycle.

We’ve seen some other companies use a different model where instead of assigning the projects to people, they let the team members choose which projects they want to work on. Culturally, we are too meeting-averse for this extra step. But we’ve heard it can work well for some teams because the project teams have a little more buy-in.

Post the kick-off message

After the bets are made, someone from the betting table will write a message that tells everyone which projects we’re betting on for the next cycle and who will be working on them.