Update: April 29, 2021

When the Desmos product team adopted Basecamp’s Shape Up process, we adapted it to be our own — you can read more about that below. Given the problematic power structures at Basecamp that have recently come to light, we’re taking time to introspect on how to make our product-building process more democratic, preserving what serves us while modifying it to ensure that the way we work is consistent with our values.

–

2020 was a long, awful year that brought about many changes to our daily lives and the way we work. Some of these changes we cannot wait to reverse - travelling, 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:

1. 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.
2. 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.
3. 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.
4. 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 Shape Up 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.

Part 1: Shaping is Designing

Shape Up recommends that shaping be done without considering the exact design and that solutions in a pitch include only fat marker sketches or bread boards of the rough idea - that you leave room for designers on the building team. We tried that approach with our first few cycles, but it didn’t feel right to our team for a few reasons. With only 6 weeks to build something with potentially lots of moving pieces, fat marker sketches were often not enough to truly hit the ground running with a project. Engineers quickly felt blocked on designs and the designers felt stressed by needing to deliver designs as soon as possible.

Shapers also felt limited by fat marker sketches and breadboards. Many of the shapers on our team knew a lot more details about what the solution should look like and leaving those details out of the pitch ended up being harmful to the team. The building team would end up learning details late in the cycle while getting design feedback and felt frustrated by wasted time building “the wrong thing”.

So we decided to move the design work to earlier in the Shape Up process, incorporating thoughtful product design, and even wireframes and high fidelity mockups, into the shaping of new projects. Concrete designs helped our shaping and betting conversations move faster since everyone involved could easily imagine what changes would need to happen in the product. Fewer core details of the solution were left ambiguous.

The precise makeup of our team at Desmos is a potentially large factor in why this shift worked so well for us - we have a very small product team with very experienced designers. Involving the entire product team in the shaping process has had a lot of benefits for us:

• We can now have many building teams that do not have a full time designer on them because many designs are done up front. Our designers are still available to collaborate and answer questions, but the majority of their building time can go into one or two projects with lots of thorny details to work out.
• Building teams that do include a designer also benefit from some mockups included in the pitch since engineers feel like they have a clear starting point. No one feels limited by the details of the mockup and the teams are generally grateful for some clarity about how the solution will fit into our existing product.

Our projects are often quite ambitious for 6 weeks and recognizing that the majority of shaping a project is designing product solutions helped us move faster and get more done.

Concrete recommendation: Try involving your product design team in shaping.

Part 2: Betting is Emotional

The betting process laid out in Shape Up did not go according to plan for our team. Even with only a few voices in the room making decisions - our CEO, our CTO, and me - we still found ourselves fighting over priorities and, even worse, revising the solutions while at the betting table.

Some of this was resolved by putting more design energy up front into our pitches (see Shaping is Designing) and spreading the shaping to more folks on the team. We still ran into issues though trying to reach consensus as a betting team with only a single meeting close to the deadline. Lots of one on one shaping conversations ended up being re-hashed at the betting table.

To address these issues, we started meeting as a betting team more regularly and much earlier in the process, looking at proposed pitches and projects well ahead of the betting table. We realized that we all needed more time to reflect on problems and proposed solutions and address any questions about pitches before betting. This turned into what we started calling the “pre-betting” process where project ideas were discussed and refined before ever looking at our team capacity.

Even with extra time to arrive at a shared understanding, the “pre-betting” and betting table meetings can be quite hard. This is where we leaned on work done by an amazing group within Desmos called the Equity Steering Committee, who help think about equity both within Desmos and in our public facing work.

The Equity Steering Committee helped refine our betting process in two ways. The first was that they spent a good chunk of time developing and iterating on a set of community agreements for our company. These agreements are a list of simple, but powerful statements that help us ground ourselves before difficult conversations. We generally take 1-2 minutes to read them silently at the beginning of a meeting and then each person at the meeting shares an agreement that resonates with them in that moment. We have found that having a few moments to look at community agreements has been especially helpful for the tough product strategy conversations that happen during pre-betting meetings.

The second tool from the Equity Steering Committee that has helped us with betting is our Equity Principles. As we consider projects to bet on, and the solutions laid out in pitches, we reflect on some of the queries from our Equity Principles to guide our decisions. For example, “How might this work help the communities we aim to serve? How might it harm these communities?” has been a helpful query for determining if a proposed solution feels ready to implement and won’t cause undue harm. The Equity Principles, plus our one year goals as a company, provide a guiding light by which to make decisions on what to bet on next.

Concrete recommendations:

• Consider meeting as a betting team many times before you need to decide on projects, especially in the first few cycles of Shape Up.
• Make sure the betting team reads all the pitches before the betting table and any questions around the solution have been resolved ahead of betting.
• Develop some community agreements to help difficult conversations stay grounded.

Part 3: Building Teams Love to Scope Hammer

At the end of every cycle we have retrospectives for teams to share how the project went from their perspective and if there are any suggestions for improvements to the Shape Up process generally. These retrospectives have helped us adjust and iterate on our process in so many ways, but one that is worth highlighting is the addition of a “Release Plan” to all of our pitches.

At the beginning of our implementation of Shape Up, teams still struggled sometimes to know what “done” looked like. The writers of Shape Up say that done means deployed, but that didn’t feel specific enough to us - deployed to who? Everyone? Our internal team? How did we build ambitious projects or experiment with new ideas using Shape Up?

To help define “done”, we came up with 3 potential end points for Shape Up projects:

• Prototype: These projects may never be deployed to production, but are immensely helpful for informing future projects and seeing if an idea is viable in our product. Prototype projects can feed into the shaping of another project or let us put an idea to rest that doesn’t work out like we thought it would. (Our written feedback system in activities started as a prototype before we released it to the public)
• Internal Release: We frequently build tools for our own team well before they are released to the public. Projects that end with an internal release require less polish than something released publicly, but still have to work well for our team and be straightforward to use. The code is deployed to production, but the features are hidden from our end users. (Our new activity editor was built for internal use by our curriculum authoring team before we released it to the public)
• Public Release: Some projects end with a public release. To release a feature publicly to all our users we hold ourselves to a high standard of UX and UI polish. We also think through the communication plan for release, localization plan, and any support materials that need to be built. Public Release felt like the assumed default from Shape Up, but it’s actually a minority of our projects.

We now use these 3 end points to help us define a release plan for each project and include a Release Plan section at the end of every pitch. By defining a release plan up front, the desired end state of each project becomes crystal clear to everyone involved. The Problem at the beginning and Release Plan at the end of each pitch act as bookends for the project that clearly define what success looks like - if the team builds something that addresses the problem statement and releases the solution to the audience described in the release plan then it is a success!

With the release plan and problem statement in mind, teams finally felt empowered to scope hammer anything that didn’t directly and clearly block release as defined in the pitch. At a recent retrospective with all engineers, “scope hammering” was one of the few processes at Desmos that received a resounding 100% satisfaction score. Lots of room for improvement, but this part of Shape Up is starting to feel spot on.

Concrete recommendations:

• Include retrospectives in the cycle planning - this is how you know what’s working for your team and what’s not.
• Consider adding a Release Plan to the end of pitches to clearly define what “done” means for each team.

Acknowledgements

I would like to express gratitude to everyone at Desmos who helped inform this process and shape Shape Up into something that feels right for our team. Special shout out to:

1. Desmos leaders who saw an opportunity for improvement and didn’t shy away from big structural change
2. Engineers and designers for speaking up about what worked and what didn’t - we have had dozens of project retrospectives this year, but I learn something new every time.
3. The Equity Steering Committee for helping us constantly improve and refine our processes to incorporate respect, kindness, and equity.

And of course to the original author of Shape Up, Ryan Singer, and the team at Basecamp for sharing their process in a free and easy to understand format.