Ship faster with the shape-up method

UPDATE: Basecamp and Ryan Singer choked on #BLM :(

Shortly after the collective street actions in 2020 (and long after I published this post), Basecamp’s founders responded… uhhhh shall we say badly to concerns raised by employees about the company’s internal culture. As a result of their shortcomings, a third of the company accepted a buy-out offer in order to leave. For his especially egregious comments, Ryan had to resign.

As a long-time admirer of both Ryan and Basecamp, I’m truly dismayed to hear how they failed this basic test of values. The best thing I can do is take what I’ve learned from them and move forward, seeking new sources of inspiration. I’m leaving this article published first because the shape-up method has influenced my approach to product management and secondly, to remember how we destroy the value of our work when we lose sight of our values. Thanks for reading~

In Shape Up, Ryan Singer (VP, Product Strategy) captures what he’s learned in the more than 15 years he’s worked on Basecamp’s core products. I’ve reached a nice inflection point in my own career and find myself in a similar state of mind — though not quite ready to write a book! Until I am, enjoy my tl;dr and takeaways from Shape Up.

A word on the philosophy behind Basecamp’s books

Basecamp released full books on aspects of their company philosophy since their earliest days as a web design agency called 37 Signals — in fact, I still recommend their original 1999 manifesto today. In that release, they explain why websites needed usability more than a splashy animated design commonly found 1990s websites.

The appeal of their “less flash, more function” philosophy drove a massive growth spurt that eventually precipitated their pivot from web design to project management software — they couldn’t find a tool to help them keep up with so many clients, so they built one!

Singer begins their newest book by calling out one of the core tensions in product management: the urgency of day-to-day implementation details vs. the necessity of strategic planning. Left unresolved, this tension leads to a slew of practical problems (missed deadlines, tangled codebases) and low morale.

Basecamp wins this tug-of-war by refusing to take sides; instead, they run “shaping” and building sprints on their own tracks with staggered schedules. Each track gets its own team and has its own distinct, yet non-determinant process. The tracks converge when its time for shapers to give another “shaped” project descriptions over to builders for development.

The shaping method in a single (wordy) sentence:

Product leaders “shape” proposed projects to fit into a six-week delivery cycle, put each one up for “betting” at a leadership meeting, then pass the winner to a team of engineers and designers who have the freedom (and full responsibility) to determine how they implement the project.

“Shaping” the work means:

Singer describes “shaping” as an exploratory, iterative process of researching and refining the value of a work to a customer in the context of its strategic impact on the company. Vague? Sure is, and that’s the source of its strength as a product development philosophy. You get to focus on the qualities that define “success” in this context and then start clarifying the scope without feeling pressure to puzzle out every last detail.

Product leads bear responsibility for things like estimating the business value and resolving technical risks or sources of scope creep before issues arise. They then capture the shape in a formal (presumably standardized) document to facilitate decision-making (“betting”) as well as communicate with the dev team later.

Pro tips for shaping work:

appetite > estimate
Humans suck at planning, even when the task is familiar, and that goes double for software-making humans. Instead of estimating time, try to gauge your team’s appetite (i.e., energy and enthusiasm) for the core problem. Know what your team finds mouth-watering and shape your sprints around their tastes.

no wireframes
You’ve communicated core objectives, mitigated the most serious risks, and blocked all paths that lead only to rabbit holes. That’s enough! You’ve marked the boundaries of an effective solution yet left the field open enough for your team to move freely. Predetermining their destination with wireframes only introduces barbed wire and broken glass to the landscape.

batches, big & small
Basecamp runs six-week development cycles (“sprints”) as a rule. Projects that likely would take longer to complete get cut down to size during shaping; no project spans multiple sprints! They save smaller projects until they have enough to batch them into a single sprint.

“Betting” on shaped work means:

“Betting” is how Basecamp describes their strategic decision-making on units of shaped work. Senior leaders pitch shaped projects to one another at a strategic meeting, debating merits and evaluating risks until a clear favorite emerges. They then present the winner to the development team for the next six-week sprint. Remaining projects don’t disappear, and they don’t get tossed into a bottomless backlog bucket. They stay shaped, ready for reconsideration at a future round of betting if a product lead wants to make the wager.

How to do work once it’s shaped

Because Basecamp handles risk and sets functional requirements during shaping, the team building the feature needs less day-to-day direction than typically provided by product managers. The team takes responsibility for figuring out how the feature looks and feels in addition to writing the code to make it run.

Noteworthy ideas on implementation:

vertical slices ftw
Gain immediate momentum by directing the team to “get one thing done” as quickly as possible, where “done” means both frontend and backend elements of the thing exist in some state. People call this approach a “vertical slice” and I highly recommend it as an evolution in agile product management.

tasks != tickets
Team progress is tracked by task (not “managed” by tickets) using intuitive tools built by Basecamp. Because shaped work doesn’t in a box, the team has better insight into tasks they’ll need to complete to complete it. I write a mean ticket, yet wonder if a tightly-knit team might find them heavy-handed.

sprint for the summit
Springer uses the metaphor of a hill to divide each sprint into an uphill discovery phase and a downhill implementation phase. Often the hardest part of both design and engineering is figuring out what the heck to do and how to get it done. Executing on that knowledge is usually easier by comparison. Work as fast as you can to reach the inflection point.

Reflecting on my own product experience

I found myself literally nodding in agreement as I read it, and have only two points to add based on my own experience in product.

1. Everything is made of people and anything they touch is the product.
The companies I most admire take a comprehensive approach to product design that goes well beyond their software. They map out the user’s journey from the beginning, lay smooth paths between likely destinations, and generally create experiences consistent with the company’s mission and brand at every waypoint.

Basecamp is one of these companies which leads me to believe they shape work according to this philosophy. If this idea is new to you, read this thread from Jesse Farmer.

2. Design thinking and taste is essential for a product manager
Basecamp lives and dies by design. It started as a web design agency, and Springer’s final interview involved redesigning Verizon’s website. I imagine that they continue to hire design-savvy folks for every position on their product team.

At teams where design played a smaller role in the company’s culture, a product manager might need to steer both the aesthetic and functional development of the product. The shaping method as outlined in the book doesn’t account for extremely early-stage products not yet supported by a design system. Team members tend to become better collaborators over time, which may mean that a product manager should hover a little more closely if the team is fresh.

In conclusion… thanks, Basecamp!

Reading Shape Up made me admire Basecamp even more, and I appreciate the opportunity to reflect on what has and hasn’t worked for me in the past. Most of my experiences have been at early startups and yet this methodology matches my intuitions despite being based on operations at a well-established company. I choose to believe this means the principles of innovation and joyful work apply no matter what your scale.

Thanks once more to Ryan Springer and the good folks behind Basecamp for sharing Shape Up with their fellow product nerds!