Skip to content

Reflections on Shape Up

Just over 9 months ago, I kicked off a pilot of Shape Up with a cross-functional team of engineers, designers, and product managers. We'd been grappling with challenges around project planning and execution, and Shape Up seemed like it would solve some of our problems.

That turned out to be a great decision for a lot of different reasons.

Rationale

TL;DR

Already sold on Shape Up? You can skip the background and jump ahead to what worked for us.

Before applying Shape Up, we'd already been riffing on process changes, but they'd fallen short in a couple of ways. The product development process looked something like this:

  1. product management identifies an idea/opportunity
  2. designers take the idea, produce mock-ups/prototypes, and share them with the team
  3. the team walks through the designs, discusses considerations, and establishes feasibility
  4. a high-level estimate is established and a kick-off is scheduled for the project
  5. the project is broken up into high-level user stories covering the major features
  6. the team executes the project, and the release date is adjusted with increasing confidence as the date approaches and the backlog of stories is pared down

Where things go sideways

This process is probably familiar to you, and at a high level, it seems sensible. Unfortunately, there are a lot of things that can go wrong along the way; these are some of the ones I've seen:

  • the mock-ups are overly-detailed and have subtle but complex features thrown in
  • the user stories fall short in one of many ways:
    • they're too broad and cover too much functionality in one pass
    • they're too small and don't capture a useful/complete feature
    • they're too light on details and lead to a bunch of questions
  • risks that seemed manageable translate into major technical problems once the work starts

Course correction

These problems are annoying, and while they may not derail a project entirely, they certainly make delivery unpredictable. Assuming the team has committed to a deadline, you can do one of two things to adapt:

  • cut scope, assuming there is something non-essential you can cut
  • push the deadline back, extending the overall project timeline
  • hold the team to the date and force your engineers into crunch mode

The first option is okay, assuming it's even on the table. Yes, the team should be tackling the riskiest work first and building an incremental MVP, but shit happens, and it's usually because of one of the aforementioned process problems. At this point you may be several weeks into the project and the team may have already built some of the optional scope, or the project is already as pared down as possible.

The other two are bad regardless of how you frame them to the team, and over time they'll erode the team's confidence and sense of accountability. Trust between departments will break down as people ask questions like "why was that in the design?", "why didn't we state that in the product specs?", or "why didn't engineering catch that earlier?".

Overcompensating

Ultimately, these are all failures in planning; the team ran into something major they didn't expect, and if we had caught that earlier, everything would have gone smoothly, right? As a result, you may be inclined to:

  • add more detail to user stories so there's less ambiguity
  • look at design mocks really closely to catch features that sneak in and balloon scope
  • break user stories down into smaller tasks to stamp out any unknowns

In the best case scenario, the plan you lay out is accurate and covers all of the work and associated risks. This is rarely the case, but even if you're so lucky, planning now takes up an inordinate amount of your time. You've also robbed the team of opportunities to exercise critical thinking and agency.

It's a well-intentioned response, it's just not the right one.

Exploring an alternative

If you've read the elevator pitch for Shape Up, you'll see that it aims to solve a lot of these problems. I've cherry-picked some of its most valuable concepts below, alongside some tips and general commentary highlighting things that have worked well for us.

Pitches

There are many concepts and processes introduced in Shape Up, but the most valuable is the "pitch", which is a written document describing the project at the correct level of detail1. It generally covers:

  • ⛈ Problem description and rationale

    What are we trying to solve? Why is it worth solving?

  • ✅ Critical scope decisions

    What's essential to solving the problem? What's just nice to have?

  • 🖌 High-level UX

    In broad strokes, how will people use the product to solve their problem?

  • 🐰 Rabbit holes

    Is there anything ambiguous or overly complex that risks derailing the project?

Pitch writing is powerful for a lot of reasons, but one of my favourites is that it fosters a culture of writing things down. Had a productive discussion around a feature? Add the takeaways to the pitch. See something written that's loaded with assumptions? Point it out with a comment. Having a document creates a single source of truth that naturally anchors discussions, tracks decisions, and consolidates information around a project.

Isn't this just waterfall?

Pitches feel analogous to the technical design documents used to specify requirements in a waterfall model, but I can assure you there are important differences. In many ways, Shape Up feels like a middle ground between waterfall and agile, and the balance between those two boils down to the level of detail (and ensuing flexibility) in the pitch.

Pitch writing2 is a team sport, typically started by product but with design and engineering involvement. That cross-functional nature is really important, as it ensures we're solving a worthwhile problem, that it's intuitive to use, and that it's technically feasible. Once an initial pitch is written, it's shared with a subset of the team3 responsible for refining it.

Appetites

A subtle but important detail in pitches is the appetite, which flips estimating on its head and has the team specify how much time they'd like to spend on a particular feature. Additionally, appetites have an upper limit of 6 weeks, which forces the shaping team to break down large projects into manageable phases.

We've use appetites often to cut scope when shaping projects.

Appetites only work with variable scope

For this to work, there needs to be scope you can cut. The smaller the project, the less useful appetites become as the features become fewer in number but greater in importance. As the project length approaches ~2 weeks, determining its length becomes engineering-led since very little can be cut, making it mostly a question of how long the feature will take to build.

Callouts

When shaping work, you'll hash out details, identify risks/rabbit holes, and adjust scope. Some of these decisions are important enough that you want to call extra attention to them. Many wikis support the ability to do so using a visually-distinctive block; in fact, you've already seen several examples of callouts above. Using these can help establish a convention for conveying the most important details. Here are some of the ones we've landed on:

Rabbit holes

When planning a project, it's common to run into questions that aren't easily answered, or technical risks that aren't well understood. Shape Up refers to these as "rabbit holes", and they need to be resolved before the pitch can be handed off to the team. Here's an example of a callout we might use to cover one of these:

Rabbit hole/risk

Use these blocks to warn readers about things that are likely to trip up the team, which typically require additional research to resolve.

Because these are highlighted in a consistent way, you can easily scan the document for them to make sure any loose ends are tied up before sharing the pitch more broadly.

Key decisions

Capturing important decisions during shaping can provide helpful context to the team. I've found the most useful decisions to call out relate to scope, but they can also be technical or architectural:

Important decision

These blocks help make key decisions more explicit, and can provide valuable context.

The more subjective an area, the more valuable these become. If the shaping team needed to debate different options, those will come up again when the team starts the project. Explicitly declaring decisions and explaining why they were made will prevent the team from rehashing the same arguments.

Open questions

When you're writing a first draft of a pitch, there are a lot of decisions to make, some of which need to be discussed with the shaping team. Calling these out as open questions is a great way to solicit feedback:

Needs input

Highlighting areas that need input from others is a great way to foster productive discussions with the shaping team. This is even more important when re-reviewing a pitch, since it can be hard to track what's changed over time; these callouts focus the team on specific areas that need consensus.

Like adding a TODO comment to work-in-progress code, noting and deferring these decisions while drafting an initial version is a great way to maintain momentum without losing sight of important details that must be addressed before finalizing the pitch.

Beyond a first version

For us, Shape Up solved a lot of problems and created just enough structure to allow projects to succeed. As we started to roll it out more broadly, there were a couple of things I noticed that are worth calling out.

As we saw early success, we started running more projects concurrently, all on the same calendar cycle. Depending on the number of engineers you have, you may be tempted to dedicate all of them to projects. After all, Shape Up prescribes a 2-week cooldown periods following each 6-week cycle, which feels like a healthy feature:maintenance ratio.

The problem with this approach is that it depends on having finalized pitches ready to go, but doesn't provide any capacity to write pitches.

Staffing shaping work

Shaping requires engineering input, and while engineering management is a good choice when piloting the process, you'll eventually want an IC involved with this work. If you've allocated all of your engineers to projects, they're going to (correctly) prioritize that work over anything else, which makes it difficult for them to meaningfully engage with pitches until their project starts.

Shape Up acknowledges this need, advocating for a two-track system with "out-of-cycle" engineers that sit outside of 6-week project cycles to help shape upcoming projects4. This is something I'm currently working on so I can't comment on its efficacy, but it sounds great in theory.

Small features and bug fixes

While Shape Up works really well for 3-6 week projects, it's less useful for smaller features. This mostly boils down to the fact that this work has less variability in scope and fewer details to really dig into.

Bug fixes aren't a good fit, either; they usually require investigation to understand root cause and are inherently less subjective.

You may be tempted to group together a bunch of these into a theme and treat it like a typical project, but that doesn't work very well. Shape Up labels this anti-pattern a "grab bag", since it's just a collection of loosely related things that can most often be shipped independently.

In these scenarios, a traditional backlog is a better alternative. The most important thing is to write down the work that needs to be done and prioritize it.

How do I know when something is just a grab bag?

The difference between a bunch of loosely-related features and a proper project is subtle. However, you'll find out pretty quickly when writing the pitch.

Good pitches tell a story, and their features should read like miniature chapters along the way. It's hard to tell a story with a bunch of disconnected ideas because they don't have a lot of shared context or common goal. If you're struggling to connect features in a meaningful way, that's when you know you're dealing with a grab bag.

Conclusion

Overall, Shape Up has been a great fit for project planning and execution. It provides just enough process to keep plans grounded and in-check while giving teams the agency to figure out how to accomplish them. Shapers define what we're building, and the team gets to decide how we build it.

That said, Shape Up isn't a panacea. While it's great for mid/large-sized projects (and breaking even larger ones into manageable iterations), it's not a holistic solution to all of your development needs, and that's okay. When paired with other systems to manage more general R&D, small features, and bug fixes, it's an excellent, pragmatic approach to product development.

  1. This is one of those "you'll know it when you see it" kind of things that you're likely to get wrong at first. Stick with it; it's a bit of an art, but it's incredibly powerful and worth repeatedly trying to get right. ↩

  2. This is one aspect of "shaping", which can also include things like design prototypes, technical investigations, and anything else needed to determine the feasibility of a project. ↩

  3. Hereafter referred to as the "shaping team". ↩

  4. In fact, if you can rotate engineers in and out of feature cycles so that they execute the pitches they helped write, they'll be able to leverage that prior context and benefit from greater agency in shaping the work they undertake. ↩