⏫ Shape Up
Shape Up is a Product Development methodology created by Ryan Singer at Basecamp. It differs from traditional methodologies in its long development cycles, the absence of product backlog and code estimates, and prioritisation model based on high-level requirements.
Let’s talk about Shape Up.
🤔 Why you should care about it
“People often ask us how we get so much done so quickly at such a high level of quality with such a small team. And how we keep our teams together for years and years.” - Jason Fried, co-founder & CEO at Basecamp
Basecamp has built a project management software used by over 100,000 customers, with less than 50 team members. They’ve also been fully remote and asynchronous for over a decade, so there are many exciting ideas about how they work.
Projects never seem to end —> in roadmap-driven organisations, there are always much more features in the backlog than resources to build them, fuelling engineers’ frustrations and fatigue.
Product Managers tend to be either too specific or too vague —> engineers do their best when they can create solutions based on well-defined problems in collaboration with Product Managers.
Projects are always late —> estimating code is highly improbable, especially since complex features contain many unknown unknowns.
Shape Up is a Product Development methodology organised around three main activities:
- Shaping: Product Managers anticipate a project's potential value (appetite) and define a solution's critical elements in a formatted pitch.
- Betting: before each development cycle, the organisation’s key stakeholders hold a betting table where they choose the pitches engineers will build. New features, enhancements and bug fixes are all on the betting table.
- Building: engineers work on projects instead of tasks over a six-week cycle and inform stakeholders of their advancement using a hill chart. They demo projects regularly, tackling one full-stack piece after the other instead of working on the back and front end in parallel.
💡 Key Concepts
Six-week cycles —> Six weeks is a long enough development cycle to build meaningful features while being short enough so that engineers can see the end. Between each cycle, there is a 2-week cool-down period to correct bugs, finish unplanned work and bet on future features.
Shaping —> Shaping consists of four main steps: setting boundaries (anticipating a feature’s potential value), roughing out the elements (with a high-level sketch), addressing risks and rabbit holes and writing the pitch.
Betting table —> A meeting during which product and engineering stakeholders decide on which pitches (features) they will bet for the next development cycle.
Appetite —> Instead of asking engineers to estimate a feature development time (challenging), product managers evaluate how much time they’re willing to spend on a feature based on anticipated value.
Hill chart —> A diagram showing the status of a project, from unknown to known to done.
”It’s impossible to work without a product backlog.” —> Important ideas always come back. Instead, having an infinite product backlog will create a feeling of never-ending work, which Product Managers will forever postpone with new priorities.
”Six weeks is too long to ship simple features customers ask.” —> So you know, Basecamp doesn’t keep a customer requests log and doesn’t make any promises. It allows them to work longer on more impactful features, but the methodology might now work if your sales team keep overpromising to customers.
“My engineers wouldn’t know what to do during the cool-down period between each cycle.” —> Shape Up works best with senior engineers who can keep their backlog of engineering projects and proactively fix bugs instead of waiting for someone else to tell them what to do.
📚 Top books
The Unicorn CTO Newsletter
Join the newsletter to receive the latest updates in your inbox.