Shape Up is a product development methodology created and used by the makers of Basecamp and Hey email service. I recently worked with a client that was practicing something similar and wanted to analyze it more closely.
As a living methodology it has a periodically updated book. This article is based on v1.8, 2019 edition authored by Ryan Singer, Head of Product Strategy at Basecamp. This revision came out around the launch of the Hey email service so it contains a number of example from that development effort.
What is Shape Up?
Shape Up is a development methodology that attempts to be very pragmatic and less dogmatic than other methodologies like Scrum. It is focused on development by smallish teams and lends itself best to cloud services. As a general guidance, Singer suggests that this is written less as a guide on how everyone should develop and more of an answer to the question of ‘How does Basecamp develop?’ In so doing, he puts the onus on the reader to decide if there is value in it for them.
At a high level Shape Up is a type of dual-track development, which means there are two continuous tracks of work – discovery and development. Shaping is about maturing an idea until it is ready for development. Development is then given a time budget and flexibility to design the details and execute as they determine best fits the previously shaped idea.
The Basecamp team has matured some concepts and provided terminology to describe their practices in a book made freely available.
Here are the significant attributes of Shape Up in my view:
- Shaping Work
- Betting
- No Backlogs
- 6 (+2) Week Cycles
- 3 Modes of Operation for New Products
- Constrained Autonomy for Teams
Shaping Work
Shaping is the act of taking raw ideas and maturing them until they are ready to be handed off to a development team. In dual track development, you will find the term “discovery” used to describe this process. In shaping, it is considered an ongoing activity that may not be easily scheduled. The goal is to shape ideas into something with reasonable constraints that can be handed off to designers and developers for execution. Shaping is an attempt to strike the balance between giving specific guidance on the problem, scope, and solution outline without being too specific in the solution details. Getting the balance right is important because it needs to leave open the possibility of the team using their expertise to execute with some flexibility. (The book gives lots of examples how to strike this balance effectively.) When shaping an idea for a project, one of the most important constraints (in Shape Up language “boundaries”) they define is the appetite. This defines the time box the shaper believes this effort is worth. So rather than estimating how much a project will take based on some defined scope, Shape Up flips it this on its head. Start with the time box, e.g. 2 weeks, and figure out what can be done to solve a problem within that constraint. There may be many ideas in various stages of shaping at any given time. The shaping work may take days or multiple development cycles before it is ready to go into development. It may be lead by a product manager, but involve a wide variety of cross functional contributors along the way to completion.
Critical Thoughts
- Generally it is an ok process and represents a good practice of maturing work just before teams will work on it.
- Under a different names, I have seen this work in practice at multiple organizations.
- This may work well for outsourced or distributed development teams.
- It ignores potential contributions of the whole team until after work is done which can both generate sub-optimal results and make the design and development teams feel like ticket takers.
- Nothing in Shape Up talks about customer or market research. They appear to base all their shaping work on narrow inputs that were pushed to them rather than proactive research. This can have a big impact on getting both prioritization, problem understanding, and design decisions wrong.
Betting
When done, the product manager, or whoever is filling the shaper role, will write a “pitch” for the project. This pitch will eventually be considered by the broader team as part of a betting process before each development cycle. The pitch contains all of the work product so that when the project is agreed to, it forms the complete basis of the requirements handed to the team. For betting to work, the betting team needs to have the full authority to make bets. There should not be an approval process after their decisions are made. So, if the CEO insists on approving all plans, then the CEO must be an active participant of betting. Further, to make this process go smoothly, all pitches must be distributed and read well before the meeting. This gives them a chance to ask questions in advance of the betting meeting.
The betting team will know the capacity of the delivery team, business priorities, technology strategy, and be able to decide which projects to bet on based on the strength of their pitch. The betting table is not just picking favorites but also deciding who from the team will be working on them. At Basecamp, they break the development team into two parts: large batch team and small batch team. The large batch team will ultimately get one big project that fills the entire next development cycle. The small batch team may get 2-3 smaller projects that together fit into the same cycle. For each cycle, the betting table determines the make-up of these teams.
For any bets that do not get done within the next development cycle, they get cancelled by default. Therefore, the Shaper has a strong incentive to craft a project that fits. The development team would likely want to see their effort completed and shipped as well.
Shaped projects can sometimes be brought back for future cycles but the default is to cancel them. The logic is that the original bet was only for such much investment. If the investment was going to be bigger it might not have been made.
- I love the strength of the decision-making done in this manner. Decisions must be made. If a project is not shaped enough to make a clear decision then there can be no decisions to bet on it. This kill analysis paralysis found in too many organizations. Worst case it needs to be matured further and wait until next cycle.
- As long as the people at the betting table have good information, this is as good as any prioritization methodology to get things done.
- As described in Team Topologies, long-standing teams working on a single value stream tend to perform best. Shape Up is going against this grain by flexing team make-up in every single cycle.
No Backlogs
Each person that is developing work to pitch is responsible for tracking it to completion. This may be a product manager or anyone else that shapes projects. Interestingly, when projects are reviewed at the betting table they do not get put into some sort of ordered list.
Therefore, there is no backlog of shaped projects waiting to be worked for future cycles that gets carried forward. Instead, a project that does not earn a bet will simply disappear. There is no central record of projects that got beat. If a shaper wants to re-introduce their project in the next cycle they may but there is not automatic priority just because something was beat in a past cycle.
Further, projects worked on each cycle must be completed and deployed within that cycle. There is no leftover work time that can be assumed in the next cycle. This means that if a project is not deployed, the shaper will need to raise it for a bet for the next cycle.
Not having a backlog creates an incredible attention to re-assessing projects on a frequent basis. What is currently important to the company and what bets now will help us best achieve that?
- No backlogs sounds like a liberating concept. It has a huge potential to stop the waste of prioritizing work that will not get done for many months (or ever).
- Basecamp does not operate with traditional product managers. In organizations that do, I wonder how this approach would be regarded since managing a list of priorities is a key part of the typical PM job.
- With no backlog you are also likely not to have a roadmap. Some companies might implode with no roadmap yet I believe this could actually be a healthy outcome.
- A benefit of backlogs is that as ideas, problems, and requests come in via multiple channels you can match them to existing items in a backlog. If you are reliant on individual departments to raise their own issues each dev cycle this might make high leverage projects harder to surface.
- This really forces bets to provide value by themselves. I am not sure how major investment might fit within this framework. For example, let’s say a new UX Design that will take 3 cycles. Why would you ever bet on a project that may take multiple cycles to be completed?
6(+2) Week Cycles
Basecamp made up their own development cycle length of 6 weeks. This is much longer than the 2 week sprints that are common in Scrum. Their logic is that based on experience, it is hard to get significant work done in very short cycles. Longer cycles will increase the size of their betting (aka investment) risk. So, through experimentation they landed on 6 weeks as the most effective balance.
This time-frame is the upper bound of their “fixed time, variable scope” principle. While the design and development team has some flexibility in delivery approach, they have a hard limit on their timeline. If the shaper believes either a 6 week cycle or less is sufficient, then the team will vary the robustness and quality of their project within that space.
After each development cycle is a 2-week cool-down period. They use this to do any clean up or finishing work necessary to ship product. This may be documentation, marketing, or even finishing up some last minute loose ends in quality of their bets. Further, this space gives the development team a little time to do things like self-development, hackathons, bug bashes, or just to go tackle a pet issue that has not been addressed by the betting table.
With the inclusion of a cool-down period after every cycle, I can see how teams can really focus on the projects knowing they always have a little slack afterward to address odds and ends.
Since this is a dual-track methodology, it is important to note that the shaping track (aka Discovery) does not flow at the same pace as the development. By design, this methodology assumes that shaping work is inherently difficult to estimate so it is unbounded.
- It is a rare customer that actually wants new enhanced code delivered on a bi-weekly basis, let alone daily in the B2B space. Constant changes are a risk to their operations so while they want to see continuous improvement, 6 week cycles are sufficient in the vast majority of businesses.
- There is a lot to be liked about these 6-week cycles lengths. So much can be done in software development and it provides a nice cadence that the organization can align around. On average you are always just 4 weeks from a new cycle start so new emergent business needs rarely wait for long.
3 modes of operation for new products
While Shape Up focuses on business as usual improvements to existing software products, not every situation resembles this, especially when developing brand new products. They identify three modes of development for new products as: R&D, Production, and Cleanup. Generally, in all these modes they are not shipping product or at least not GA product.
R&D Mode – This is when you as pure research work around problems and solutions. Usually lead by a small core team without a lot of involvement from the broader organization at this stage. Too many unknowns. After each cycle the goal will be increased learning and refined design.
Production Mode – After core decisions are made, the team switches to the same style work as if improving an existing product. Full shaping and development cycles. With code delivery expected after each cycle (just not released to customers). This could go on for one cycle to many depending on the product.
Cleanup Mode – For a cycle before the first official GA release, this is the time to finish leftovers, fix bugs, and address any tech debt before it customers start using in production. Once customers start using a product it is much harder to do this work as you don’t want to impact their experience or risk harming their data.
- It is not clear if they do a long development effort without delivering anything to customers. I have to assume that they are delivering something throughout to learn.
- Cleanup mode is such an interesting concept. I have shipped so many initial release products with limited wiggle room before a market launch I wonder what this would have done to quality and initial impressions.
Constrained-Autonomy for Teams
Shaping work is lead by a single person working on a single idea. They finally bring their mature idea to the betting table as a pitch to be voted on. Then this artifact gets handed over to a designated team.
Shape Up promotes this process as assigning projects with goals and not tasks to the design and development teams. Indeed this is not the extreme form of handing out specifically defined narrow tasks. Yet it is also not a fully realized Autonomous Team.
In this process, teams are given some latitude to design the solution but very limited control over defining the problem. The are also given some guardrails on their solution design and clear guidance to limit scope creep.
- Basecamp touts this as giving the teams a lot of autonomy and, in fact, it is compared to the way many organizations work. I have seen this approach work well in multiple environments in the past. The culture of the organization will dictate if this is considered a very empowering or limiting process design.
- Since teams do not have autonomy to discover the problems they work on, the fact that they can change every cycle by the betting team makes these constraints less negatively impactful.
Conclusion
The Shape Up method is somewhat of an agile development approach but definitely violates some of the Principles in the Agile Manifesto. For organizations that struggle with team autonomy, have offshore development teams working for you that make synchronous face-to-face conversations hard, if teams are getting burnt out from 2 week sprints, or you have some other challenge from the rigidness of Scrum – Shape Up is definitely worth a look.
There are a lot of good and interesting ideas here. Including eliminating the backlog and defaulting to stop any bet that doesn’t ship within the planned development cycle. These ideas are worth some serious consideration as they do drive a nice balance of agility and focus.
In practice, the concept of shaping makes a lot of sense to me but I would work to make it a little more collaborative and ensure direct market engagement was the norm. This will increase the odds that the bets taken will hit the mark.
During the development cycle I would like to see the product manager more available and involved. This will help answer questions as they arise and reduce the reliance on a perfect pitch being written in advance.
If you choose to go down this path, remember that Jason Fried’s introduction is not a direct pitch to apply their approach as-is. Instead, the methodology is simply presented to answer the question of how they work. Their process is evolving and while you can draw lessons and inspiration from it , don’t blindly follow it as dogma.
Additional Resources
Shape Up (v1.8, 2019 edition). Stop Running in Circles and Ship Work that Matters by Ryan Singer – lot’s of great examples and more attributes of the methodology to explore. I think the online version has more examples than the PDF version that I had originally read.
Product Management in Notion: How to Shape Up without Basecamp – Notion is super cool as a utility-knife. Using it to manage a Shape Up process is a no-brainer.
Shape Up (v1.7, 2019 edition). Review notes from John Cutler. – John always has amazing insights. He happened to take some notes on his reading of the book last year. I suggest you read the book then skim his notes.