Shape Up Part 1: Shaping

In the previous article, Introducing Shape Up, we saw how this methodology differs significantly from traditional methodologies.

We saw that the Shape Up methodology consists of 3 parts: Shaping, Betting and Building. This article focuses on the first part. As the Shape Up methodology is extensively documented in a dedicated book, the aim of this article is not to be exhaustive, but rather to give an overview of its core principles.

General Principles

• Work must be shaped at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes.
• Wireframes are too concrete. When design leaders go straight to wireframes or high-fidelity mockups, they define too much detail too early.
• Words are too abstract. When a project is defined in a few words, nobody knows what it means. “Build a calendar view” or “add group notifications” sound sensible, but what exactly do they entail? Projects defined like naturally grow out of control.
• Two tracks: you can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason there are two separate tracks: one for shaping, one for building.
• During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle.

The 4 Steps to Shaping

1. Set Boundaries

• Setting the appetite: sometimes an idea gets us excited right away. In that case we need to temper the excitement by checking whether this is really something we’re going to be able to invest time in or not.
• Fixed time, variable scope: an appetite is completely different from an estimate. Estimates start with a design and end with a number. Appetites start with a number and end with a design. We use the appetite as a creative constraint on the design process.
• This principle, called “fixed time, variable scope” is key to successfully defining and shipping projects. Take a book writing project as an example. It’s hard to ship a book when you can always add more. But when you have a deadline, all of a sudden you have to make decisions.
• Narrow down your understanding of the problem. The Basecamp team turned “Advanced user permissions” into a simple warning box in a specific page. 1-day work instead of a full six-week project.

2. Rough Out The Elements

• Dozens of different ways to approach the solution: important to move fast and cover a lot of different ideas.
• Questions we’re trying to answer are:
  • Where in the current system does the new thing fit?
  • How do you get to it?
  • What are the key components or interactions?
  • Where does it take you?
• Use fat marker sketches

• The schema above contains a starting place (“Invoice”), affordances (“Turn on autopay”) and connection lines (to “set up autopay”). Note that the connection line doesn’t specify if it’s a separate screen, or modal or what.
• Since we’re using such a lightweight notation, and we aren’t bogged down with wireframes, we can quickly jump around and entertain different possibilities.

3. Address Risk And Rabbit Holes

• Look for pitfalls we can find up front (technical unknowns, misunderstood dependencies, …)
• Maximize the probability that it will ship in six weeks by walking through a use case in slow motion and questioning the viability of each part
• Declare out of bounds: list cases you specifically aren’t supported
• Present to technical experts: verify technical assumptions
• Keep the clay wet: no slides or document, but build up the concept from the beginning on the whiteboard
• 2 types of outcomes:
  • Validated. Can write the pitch document (cfr next section).
  • Discovered some problems. Back for another round of shaping.

4. Write the Pitch

• At this stage, have the elements of a solution and concept has been de-risked.
• But concept still in our heads. Need to create a document/presentation that others will understand.
• Goal: present a good potential bet
• 5 ingredients to always include in a pitch:
  • Problem: the raw idea, use case, …
  • Appetite: how much time we want to spend
  • Solution: core elements we came up with
  • Rabbit holes: details worth calling out
  • No-gos: anything excluded from the concept
• No wireframes or high-fidelity mocks. But more concreteness than the hand-written breadboards.

From this:

To this:

Conclusion

In this article, we have seen an overview of the Shaping process and the main steps. In the next article, we'll take a similar look at the second part of the Shape Up methodology: Betting.

Stay tuned!