One Year of Shape Up
By: Cori Mcelwain
Tags: Shape Up, Product Management, Product Development, Product

One Year of Shape Up

This long, awful year has brought about many changes to our daily lives and the way we work. Some changes we cannot wait to reverse — traveling, meeting up at coffee shops, gathering around a whiteboard to brainstorm, safely seeing co-workers in person — but some changes are likely here to stay.

This year at Desmos we made many big changes, from building out a brand new team to support our curriculum program to shutting down our office permanently and becoming a fully remote company. In the midst of a truly crazy year, with many external and internal distractions, our product development team managed to keep humming along and building great things for our users — from releasing a new activity editing experience to completely revamping our homepage to releasing classes to upgrading our styling options in the calculator, and many many more. Our success with shipping new things this year is due in no small part to our implementation of a new framework for planning and organizing projects: Shape Up.

Our journey with Shape Up began in the summer of 2019, when our CTO came back from vacation with a new book recommendation for the team: Shape Up: Stop Running in Circles and Ship Work that Matters. Around the same time, I had started stepping into a product manager role and was thinking hard about how to set up processes to help us deliver great stuff even as we grew the team. Working with the CEO and CTO, I had been iteratively making improvements to try to better plan and prioritize our product work, but progress was slow and we didn’t have a clear framework for why we were making changes. There were a few issues we recognized and were looking to address:

There was a huge amount of recency bias in what we worked on. We weren’t finding time to think strategically, so when it came time to select new projects we were often choosing from a grab bag of recently discussed ideas, ranging from something someone on our team had been hoping to build to whatever user issues were currently flooding into our support channels. Most of our projects were not well specified before we started to work in code — our engineers and designers were working from short descriptions that often glossed over the problem we were trying to solve and focused on the solution. Without clear deadlines, problem statements, and release plans up front, knowing when something was “done” was a challenge. Projects would sometimes stretch on and on. Our backlog of bugs and feature ideas felt overwhelming to anyone who looked at it, and few folks ever did. It was unclear when the right time was for bug fixes vs. larger projects.

Shape Up promised a different world — one that encouraged us to spend the time necessary to shape the work before picking it up; where teams had enough information about the problem we were trying to solve that they could easily take responsibility of projects; where fixed appetites and hard deadlines allowed teams to scope hammer and move on after the deadline passed. So in the fall of 2019 we kicked off our first Shape Up cycle with a single team and project, learning and adjusting as we went. Since early 2020 we have been using the Shape Up framework for close to everything our product and engineering team builds and in recent cycles we have really been hitting our stride.

We have so much gratitude for the team at Basecamp for sharing their process with the world and providing the foundation by which we now work. With over a year now of experience implementing Shape Up, I wanted to take a moment to reflect and share some of what we have learned. The ways that we adjusted our processes built on top of the core principles in Shape Up to make something that works for our team. I share these with the simple hope that other teams who are similarly enamored with the ideas in Shape Up can learn and adjust the practices for their own needs.