Hey! It’s me, Nathan Baschez (@nbashaw). I haven’t been writing much lately, but I read a book last night that I loved, and inspired me to use my 6-hour flight today to publish an extension of the theory. Hope you enjoy!
A few months ago, Ryan Singer, who runs product strategy at Basecamp, published his first book. It’s called Shape Up, and it’s all about reducing execution risk for software development teams:
Even if things aren’t that bad in your team, people often feel a sense of malaise: Can’t we make this thing grow faster?
Shape Up thinks you can. The method is like Agile, but with a few major tweaks. (And a lot of new terminology intended to induce a feeling of risk. For example, “plan” becomes “bet.”)
Last night, I finally got the chance to dig in. I saddled up at the bar of an airport hotel in New Jersey and read the whole thing in one sitting. I loved it. But, as I was reading, I noticed something was missing. Perhaps an opportunity to extend the theory?
Shape Up was written with companies like Basecamp in mind: ~40 person product teams building off a solid base with reasonable traction. (This is why it took me so long to actually read it. I’m exploring new startup ideas right now and it didn’t seem totally relevant.) But as I was reading, it was clear to me that the core principles and risk reduction methods are equally valuable to people building startups and tiny personal projects.
I even used it to write this post! (More details on that at the very end.)
Between my experiences at Hardbound, Product Hunt, Substack, Gimlet, General Assembly, and Olark (not to mention a bunch of side projects) I’ve seen a healthy variety of development processes, team sizes, and levels of product maturity. So I thought I’d be reasonably well placed to write this essay essentially as an adapter.
Here’s the roadmap:
How Shape Up works at Basecamp
Shape Up vs. Agile
Why it works / how it reduces execution risk
What’s different about startups
How to adapt Shape Up to fit startups
(Disclaimer: This post isn’t endorsed by Ryan Singer but—hi Ryan!—if you’re reading this I’d love to hear what you think.)
(I’d also love to hear what you think even if you’re not Ryan Singer!)
Ok let’s get started.
Basecamp’s product team has two fundamental work streams running in parallel at all times: shaping and building.
Shaping is transforming raw ideas into specific pitches.
Building is transforming pitches into shipped product.
(This diagram was drawn by Ryan Singer in Shape Up)
Here’s more detail on how it works:
The whole company is oriented around 6 week cycles (with 2 week “cool down” periods in between).
In a cycle, they might have ~4 teams working in parallel (two web teams, one on mobile, and one on infrastructure, for example).
Each team consists of a few designers and engineers. In a cycle, they’re assigned either one “big batch” project that takes up the whole six weeks, or several “small batch” projects.
Before a cycle begins (during the “cool down” period after the last cycle), the senior leadership of Basecamp meets to decide what projects to bet on. They call this the “betting table.”
Pitches presented at the betting table have a specific format. They have a short description of the problem, an “appetite” (basically how much time and headcount do we think this is worth), and a rough description/sketch of a solution that plausibly fits within the constraints of the “appetite.”
Once the senior team decides what bets they want to make, Jason Fried (the CEO) writes a memo letting the whole company know what’s coming up.
When projects are handed off to teams, they basically just get handed the pitch that the senior team bet on: problem, appetite, solution. It’s up to the builders to figure out how to tackle the project from there and ship it before the end of the cycle. There are no PM’s to tightly manage the workflow, just loose guidance from senior leadership as needed.
In the first few days, the team gets oriented with the problem domain, and figures out the most important slice to build first. The idea is to get a basic element working in code, end-to-end, and polish/expand from there.
Build teams decompose projects into logical groupings as they get started and discover how it will work. These groupings are called “scopes” and basically represent areas where there are a lot of tight interdependencies.
The progress of each scope is measured on a hill chart. The idea is that as you make progress, you figure out all the tasks you need to do. So even though you’re making progress (reducing risk and uncertainty) it looks like you’ve completed a smaller percent of the project. The hill chart is designed to represent the uncertainty and risk of a project. Once you see clearly everything that needs to be done in order to ship (Ryan compares it to having screws and a screwdriver in your hand and knowing exactly where they need to go) the dot goes “over the hill.”
If projects aren’t completed by the end of cycle, they are by default cancelled. This is the “circuit breaker” that prevents bets from spiraling out of control. In order to resume the project, it needs to be shaped and bet on again. Basecamp leadership is able to detect possible trouble spots early by looking at the hill charts of their teams.
Instead of managing designer’s and developer’s workflows, the product work involves shaping raw ideas into pitches. This is what Ryan Singer does. He studies data, talks to users, thinks through the core elements of a solution, runs it by team members for a sanity check as needed, and crafts it all into a pitch document. (Most PMs I know would kill to have this much time to think.)
If you take a step back, the flow of work is basically a supply chain, starting with raw ideas and ending with shipped product:
(Another diagram from Shape Up)
A lot of this may sound pretty familiar to you. Isn’t a “shaped pitch” just a spec? Shouldn’t developers and designers be empowered to own their own projects? How big a deal is the difference between a two-week “sprint” and a six-week “cycle”?
Ultimately what’s important is not the terminology. (Although, for whatever reason, I do prefer most of Shape Up’s words to their traditional Agile counterparts.) There are a lot of teams that operate very similarly to Shape Up, perhaps using words derived from Agile tradition, and don’t even realize it. The most important thing is understanding what the true sources of execution risk are, and how to manage it effectively.
And this leads us to an important aspect of Shape Up that I think is nowhere to be found in agile and matters a lot: fixed cost constraints (aka “appetite”).
In most settings I’ve worked in, people pitch ideas (often not very shaped) and we estimate how hard they’d be to build, and how much probability-weighted impact they might have, and then rank the ideas by expected value. You pick out a couple of big ideas then fill in some smaller ones, and draw the line at an amount of work that feels reasonable to fit in your two-week sprint cycle. The first step in execution is to write a spec, but we’ve already committed to do it.
The problem with this method is that in order to decide what to build next, you probably want to go a little deeper than the raw idea, but not as detailed as a spec. As you outline the solution, you need to understand how much cost you’re willing to incur. To borrow a metaphor from Ryan, software features are like cars: it makes no sense to ask how much they cost in the abstract. Costs ranges from “dirt cheap” to “more than you could possibly imagine.” There are a million different variations on something as basic as a calendar, or a todo list. You can only start to make hard but real tradeoffs if you understand how much it’s worth to you and how much resources you’re able to commit to it.
Once you understand that, it becomes the critical constraint that defines the entire project. If you neglect it, you end up spending 2-5x, maybe even 10x what you originally had in mind. And once you figure out you’re on that path, it’s hard to get off it. You’ll probably have to throw away a lot of work in order to start from scratch.
Another critical ingredient of Shape Up that’s also not commonly found in agile is the “circuit breaker.” It means if you don’t finish a project in the time you allotted yourself, it’s dead by default. If you want to extend it, it needs to go through planning again.
Because two weeks is such a short cycle time, you often end up with teams indefinitely extending failing projects. So you don’t think twice about extending. That’s what you always have to do, by default. Six weeks is long enough time to build meaningful ideas and have no excuse for not shipping, but short enough that you don’t feel like you have a lot of time to fiddle around.
These are all ways of solving for the same thing: fixed cost constraints. Because scope is like a gas (it can expand or contract to fill the available space) you have to impose some hard edges.
Shaping work is as much about creating a container and a goal and letting build teams run with it, rather than telling build teams exactly how to tackle the project, and breaking it into little tasks.
As you scale an organization from a core founding team to a product org with dozens of teammates, there are a few important things that change:
You can work on more stuff in parallel
Your uncertainty about the business / problems space shrinks
Roles increasingly specialize
Keeping everyone on the same page requires structure and repetition
Conversely, if you compare a pre-launch startup to a mature product org, you notice:
You can really only build one thing at a time
Your theories about the business and problem space are totally unproven
People are mostly generalist and need to figure out new skills on the fly
Communication is fluid and informal
In a startup, it would be absurd to spend six weeks shaping a bunch of work for yourself, gathering all 3 team members around a formal “betting table,” and planning out 6 weeks worth of projects. Everyone should be capable of both shaping and building, and, although a clear long term vision is crucial, it makes no sense to plan specific work that far out in advance.
And yet startups face the same fundamental dynamics as everyone else when it comes to execution risk and uncertainties. When you start building something you’re not sure exactly how you’ll do it, and as you go along the path you start to learn more and face important trade-offs. Moving quickly is critical, but you also want to build solutions that actually work, so you need to thoughtfully decide what your “appetite” is for any given problem.
In other words, there’s a lot in Shape Up that you don’t want to throw away.
Here are a few ideas I think make sense:
In a startup sometimes you want to commit to focusing on building a thing for a few days then decide what to do next. Other times it could make sense to commit to a project that will last a few weeks. The most important work may not neatly fit into a standard cycle time. Problems and opportunities in the real world are irregular like that.
As you get bigger, you can smooth it out because the work is spread across more teams working in parallel. But when you’re small you feel it intensely.
So why not pick a length for each cycles when you plan it? It’s important to still start with appetite and deadline, and to have the “circuit breaker” default be to not continue if it goes over deadline. But there’s nothing wrong with starting with a one week cycle, then deciding we think the next thing is worth 3 days, then deciding the next most important thing is worth two weeks.
If you had a big team of people it would be hard for everyone to keep track. But you don’t.
Here’s an example from my life: I had an idea for a product that I wanted to build a few months ago and I was working with a potential co-founder on it. The risks I wanted to solve were 1) do we work well together? and 2) are the problem and solution I’m imagining seem to be real?
Given our life contexts, we decided to work on it for a month and regroup at the end. We put together a loose spec for a version 1 that we felt could teach us a lot of important lessons, and then started building it together. At the end of the month, we decided to re-up. We spent another month. But this time at the end, we decided not to pursue it any further.
I’m bummed at some level that it didn’t work out, obviously, but I’m also really glad. I think we could have made it work to some degree of success, but we learned a couple specific things about the market that made us both want to pursue other opportunities.
We weren’t explicitly using Shape Up, but looking back, I see ways we could have learned even more efficiently. We picked a month somewhat arbitrarily. I was too used to thinking in “standard cycles.” I think I could have come up with an even tighter shaped pitch, and it would have constrained my appetite even more, and we could have learned even faster.
Having a non-standard cycle time probably stops making sense pretty quickly in the life of a company. It makes more sense to settle into a rhythm. Just don’t let yourself accidentally keep extending projects past your initial appetite.
When your team decides it’s time to regroup, take a look at your Trello. Perhaps it has the following columns:
Raw ideas
Shaped ideas
Planned bets
Building
Done
In each planning meeting, bet on what raw ideas you want to see shaped before the next cycle, and what shaped ideas you want to see shipped before the next cycle. Just because your team is probably too small to have one person 100% dedicated to shaping doesn’t mean you shouldn’t shape ideas before you commit to building them.
I’ve often been guilty of this. At pretty much all of my jobs, I’ve created prioritization lists that look like this:
Spec twitter login flow
Design twitter login flow
Build twitter login flow
If a feature is really critical to build RIGHT NOW then you’ll realistically just build it after you shape it. But it’s important to keep an open mind when you’re shaping, and consider that you may want to do this later. Or there may not be a great solution that’s possible within your cost appetite.
It makes sense to only commit to the smallest unit of incremental work that reduces uncertainty meaningfully. A shaped idea is much less risky and uncertain than a raw idea. If you want the highest throughput of ideas with the lowest project thrash and churn, it makes more sense to break these into two separate stages, with two separate commitments.
At Basecamp, build teams aren’t responsible for anything except getting their projects done during cycles. In the “cool down” phase they can fix random bugs, refactor code, etc.
As a tiny team with a more unstable product/business, it’s more likely that you could have bugs that really are urgent to fix. Or maybe you just want to delight an important customer who sent you a feature request by turning it around within the 24 hours. These marginal wins (and loss preventions) are more important at small scale.
(Plus, realistically, you’re going to have to do a bunch of random stuff as a founder. Ever heard of workers compensation insurance? Neither had I until I started Hardbound.)
So, to manage this random stuff, think about the “cool down” period as an hour or two at the end of your day after you finish your main thing, rather than just as a thing you do for a couple days at the end of a build cycle.
At the end of the day, Shape Up is a really useful read for anyone who wants to understand the nature of execution risk. Whether you adopt it as-is, or just use it as inspiration to improve your execution ability on the margin, the main idea is that you should shape ideas before you commit to them, only commit with a specific appetite in mind, and be strict about enforcing the limits of your appetite.
If you do all those things, you should be able to ship a lot faster and more predictably. Whether in a giant corporation, or a tiny startup.
PS - Thanks for making it this far :)
Here’s how I used Shape Up to write this article: First, I took the “raw idea” of writing an article adapting Shape Up to startups, and shaped the work. I thought about the problems startup founders might have in trying to adapt Shape Up for their team. I thought about possible solutions. I thought about my appetite to work on this. I bet on it! I wrote the core elements first. Then I went back and polished up the language, wrote the intro, conclusion, etc.
