Here’s a common question that’s coming up about Shape Up, our new book on product development:
People in my book club love all the principles, but they had one question: How did they build Basecamp 3 doing this? It seems like all the practices are for adding features to an existing product.
There’s a new appendix in the book now to answer this question: How to Begin to Shape Up: New versus existing products.
We’re working on a new product right now, and we’re following the same approach we used to build Basecamp 3 and Basecamp 2 before it.
There are two phases of work when you start a new product. We call them “R&D mode” and “production mode.”
New products start in R&D mode. Instead of shaping and betting on a specific feature idea, we bet a block of time (a six-week cycle) on exploratory work with an extremely rough list of potential features. An experienced designer/programmer team will pair together skunkworks style to work out the basics of the overall architecture and some key interface elements. Instead of building features to completion, they build just enough to verify that the product hangs together and the architecture accommodates the functionality we’ll need. (The Pragmatic Programmers call this “firing tracer bullets.”)
R&D mode is messy and unpredictable. It’s common to pursue one approach for a couple weeks, realize it’s not working, scrap everything, and then try something else. That would be very unhealthy in production work. But for a new product, you need to get through this experimental phase to arrive at the basic design.
The R&D team integrates shaping and building in a blurry mix within the time box we’ve allocated. They’ll shape an approach, spike it out, learn something, and try something else. That’s why the team needs to be small and senior. There are lots of deep judgement calls to make and no existing code or interface constraints to guide their efforts.
Eventually the R&D team gets to a point where they’re willing to “pour concrete” on the fundamentals. With the key pieces of the architecture in place, constraints now exist for future work. It’s easier to see where new features will go and what they will be built upon. It can take the skunkworks team a few cycles of work before they get to this point. Once they do, we can shift to production mode.
There are still lots of unknowns and unbuilt features in production mode. What’s different is now the architecture is settled and the ground is firm, so we can make surer bets. All the detailed Shape Up methods apply at this point. We don’t know if we’ll like a new feature or if we’ll include it in the final cut of the product, but we can define our appetite for it, shape it, bet time on it, and give it to a team. Instead of building things half-way like in R&D mode, the team is expected to build a fully working version and deploy it by the end of the cycle.
In the case of Basecamp 3, David (co-founder and CTO) started by doing R&D work to define the access model and how data of many different kinds would belong to one project versus another. Extremely bare bones versions of the message board, comments, and to-do features validated the architecture. Those features weren’t anywhere near complete enough to ship, but the stubbed versions gave him confidence that the architecture would accommodate all the functionality we hoped to build later.
We still only made commitments one cycle at a time. We knew it would take multiple cycles to build BC3 — maybe a year’s worth or more. But we didn’t commit to any specific work further than six weeks ahead.
This split between R&D and production mode is also useful for existing products. Sometimes you need to do build a feature totally unlike anything you’ve done before or with unfamiliar technology. In that case, draw a boundary between the part of the app that has a settled architecture and the new area that’s unsettled. Bet time on exploratory work in the new area to firm up the ground. Then if that works out, shape a project with clearer expectations and a hard bet.
That’s how we handled Hill Charts in Basecamp 3. We had never built the kind of high fidelity interactions required to drag dots on the hill, and there were lots of open questions about the data model. For the first cycle, the team wasn’t expected to ship. They had a roughly shaped concept but lots of room for R&D work to figure out how to render the chart and store its history. Then, after we validated the approach, we were able to shape a subsequent project with clearer expectations and build the feature to completion in another cycle.
Haven’t heard of “shaping” or “betting”? All the details about how we work are in the book. You can read it online or download a free PDF here: Shape Up: Stop Running in Circles and Ship Work that Matters.
