Book Thoughts: Shape Up
I recently read "Shape Up: Stop Running in Circles and Ship Work that Matters" by Ryan Singer of Basecamp and here are my thoughts:
Overall, Shape Up is a well-written book that delivers on it’s promise of explaining a shipping methodology. In terms of the methodology itself, the way it is presented in the book seems to promote “feature factory” type behaviour, where the “shaping” and “betting” activities are centralized. For example, the “shaping” and “betting” work is predominantly done by a small group of people/leaders (e.g. CEO, CTO, product strategist), although it can also be done by others. Following this, Individuals get assigned to projects (features) that they have decided to bet on.
This means that individuals/teams are working on assigned projects or features, instead of being assigned problems or target customer outcomes and coming up with initiatives via a bottom-up process. This makes sense given the size of Basecamp (~50 people) and the founders are still heavily involved in the product.
That being said, I think there are a number of insights that are good practice or widely applicable for teams building products. Specifically:
Working at the right level of fidelity in the “shaping” process
For example, fat marker drawings to prevent prescribing a solution to designers
Scope projects in such a way that you can show meaningful progress incrementally
Resist the urge to scope by components (e.g. frontend, backend). Instead integrate vertically, so that you can complete and arrive at a functioning piece of work as quickly as possible.
This first piece should be the core of the new project, doesn’t need to be pretty or pixel perfect.
Showing progress via a “hill chart”. This is based on the idea that it is hard to communicate progress in a meaningful or reliable way early on in the building process, as there is little clarity around the exact tasks and volume of work remaining. This phase is categorised as “going up to the hill”. Once you reach the top of the hill, you have clarity on the exact things that need to be done to complete the project. From here, it is easier to provide an accurate estimate on project timelines.
Appetite instead of estimates (fixed time, variable scope). This refers to letting time limit determine scope instead of the other way around. I think this concept can be expanded beyond time, the scoping of features/products is one of the core responsibilities of a PM and necessarily requires balancing of business value, usability, technical feasibility, resourcing constraints etc.
Further, I think Shape Up could definitely be tweaked in order to be more in line with the “empowered product team” behaviours espoused by Marty Cagan. Specifically, by decentralising the “shaping” and “betting” activities. By bringing the shaping process into the specific team that will be doing the work would allow for more bottom-up initiatives. Decentralising the “betting” activity into the teams that will actually be building.
For those that are interested, there also seem to be a number of parallels between Shape Up and the rituals at YouTube during their hypergrowth period:: https://coda.io/@shishir/rituals-for-hypergrowth-an-inside-look-at-how-youtube-scaled