Last week Ryan Singer, Head of Product Strategy at Basecamp, released a web-book called Shape Up: Stop Running in Circles and Ship Work that Matters. In it, he outlines the unique process of product development they've developed over the past 15 years to ensure their small team is always shipping impactful product changes. Here are the 5 summary points I took away:
1. Dual Track: Shaping vs Building
Unlike Agile processes where the team breaks a large body of work down into smaller sprint-sized chunks and starts to build them, Basecamp's process instead holds fixed the time to release a chunk of work to customers and focuses on "shaping" work into that time period. Big bodies of work take 6 weeks for a small team (1 designer and 2 engineers), while smaller ones take 2 weeks with the same size team (in that case, the team takes on 3-5 smaller bets to fill the 6-week cycle).
To me, the most interesting aspect of this is focus - teams are not asked to juggle multiple things simultaneously but instead are asked to swarm a project together and give it their undivided attention to see it through to completion. I saw the value of this first hand during "Innovation Sprints" we ran at HelloWallet / Morningstar - in a week, small teams of engineers and designers would do amazing things like build an entire mobile app from scratch. Yea, maybe it wasn't production-ready but I can't believe the ability to focus for a week had something to do with their pace.
(Of note, there are no product managers at Basecamp - a few team leads / execs prioritize the work through shaping and betting, and individual project teams are held accountable for delivering during their build cycle.)
2. Shaping Ends with a Pitch
The pitch is a document that includes 5 ingredients:
- Problem - "the best problem definition consists of a single specific story that shows why the status quo doesn’t work"
- Appetite - do we want to spend 2 weeks or 6 weeks building a solution for this problem?
- Solution - Ryan explains they have 2 techniques of communicating a solution that make them specific enough to understand the scope but not so specific that there's no creative freedom for the designers / engineers who take on the project. They are "fat-market sketches" that convey a UI but with very limited real estate and "breadboards" that replace wireframes by showing elements of a page and clicks that navigate between pages as a list of words and nothing else. (see below for visuals)
- Rabbit Holes - pre-defined solutions to minimize risk of not being able to ship in 6 weeks (e.g. ways to resolve any time-consuming UX issues the team might run into while building)
- No Gos - anything that's out of scope for the project
Ryan kindly includes a couple of example pitches in the book.
3. No Backlogs
Rather than work off an always-growing backlog, Basecamp cleans the slate every cycle and only considers a handful of pitches as candidates for the next build cycle. Each team keeps a list of the work they'd like to bet on themselves, and it's up to them to revive old ideas and bring them to the betting table / rationalize why they should be reconsidered.
Of note, none of the pitches are discussed with build teams unless it's decided the bet is going to be made. This way, you avoid distracting people with ideas that aren't prioritized.
4. Work is Like a Hill
Perhaps my favorite concept is how they communicate the status of a project mid-cycle. Ryan uses this hill analogy - when you're at the bottom of the hill, you have a lot of hard work ahead of you to get up the hill. But once you're at the top, coming down the other side is much easier. Similarly, the uphill tasks with software projects involve understanding the problem and shaped bet, then breaking up the work. The downhill tasks are to do the work identified.
Basecamp extends this analogy and visual into their product so stakeholders can get status reports without bothering the project team. The project team spends the first few days breaking the shaped bet into chunks of work, and updates the status in Basecamp to show where each chunk of work is on the hill:
In the example above, the project had 3 "scopes" (chunks of work), represented by the 3 dots on the hill. It's clear the team is still figuring out the Future-Applying Edits UX, the Global Recurring Events is almost done and Permas per Occurence is in-progress. The circle in the top left shows that the bet includes just these three chunks of work (that is, there's nothing left to do after these 3 are done).
5. Make Full-Stack Progress
Ryan makes a point of how most teams split work up by person / role, rather than how the work should be organized to make progress towards the final deliverable (shippable code, in this case). He has some great visuals to show why splitting the work up between front-end and back-end changes without coordinating efforts isn't helpful in reducing risk or making progress.
There are some key concepts I love about this process:
- Fixed time-to-production - holding the build timeline fixed at 6 weeks, shaping work to fit into that timeline
- The ultimate consequence - if a build isn't done in the time allotted, the project is scrapped until it goes through the whole process again
- The hill - the visual is a great way to break up work and communicate status to stakeholders and within the project team
However, there are some parts of this process I could see existing product teams struggling with:
- The role of PM - PMs would need to shift time from roadmap/sprint execution to shaping
- Less direction - Ryan mentioned to me that there's not a formal artifact to convey the product vision or direction. Making bets on what's currently top-of-mind might make it hard to see the forest through the trees or ensure the bets are moving the product closer to an envisioned end-state.
- Right-sizing - knowing what to include in a 2-week or 6-week bet (although I would think the team could get better at shaping over time)