Common Pitfalls When Adopting Shape Up (and How to Avoid Them)

I see some common pitfalls when people try to do Shape Up "by the book." There are things in the book that are Basecamp-specific or often misunderstood, and teams who successfully adopt Shape Up all find ways around them. It'll save you a lot of headache if you can call these out and formalize them up front, instead of hoping that your teams will independently figure them out.

Pitfall #1: Shaping without technical depth

The book says shaping is primarily design work. But everyone at Basecamp — including designers — was very technical! If you try to shape with only PMs and non-technical designers, projects will churn because of the unanswered questions that blow up during build. The #1 failure mode of attempted Shape Up adoptions is "undershaped" work.

Recommendation #1: Shape with technical people

Shaping sessions should involve senior technical people who know the realities of the code. Designers who shape should be of the "interaction" type vs. the stylist type. The main output is the wiring of how it works. Think the blueprint of the house, the walls and electrical wires, not the 3D rendering of the kitchen interior. It's where the sink goes and where the pipes go, not the paint or the tile.

Related: Rabbit holes are commonly misunderstood. Any rabbit hole that isn't solved during shaping is a time bomb that can churn the project.

Recommendation #2: Do high fidelity last

High fidelity design done too early will blow up. Build something raw and ugly that meets the functional and interaction requirements first, and style it last — literally in the late stages of the build cycle. This is like painting the walls and moving the furniture around after the construction is done. When the electricity is in the walls, you can still swap the fixtures at the very end.

Pitfall #2: Blurred framing and shaping

You will find that the recommendation to shape with technical people makes shaping harder to coordinate and more "expensive". Therefore, you will want clearer problem definition and more alignment up from to justify the sessions and make them productive.

There is a distinct work step to nail down the actual problem and outcome before shaping. We didn't have a word for it when I wrote the book. Now it’s called Framing. (It's implicit in the book. Ch. 3 "Set boundaries" is actually framing. Ch. 4-5 is shaping.)

When framing isn't tight, the shaping and build phases will go in circles or spiral out in scope. Fuzzy framing also leads to "shiny object syndrome" — when projects get canceled or swapped for other projects midway because there wasn't enough clarity about the outcome to create conviction.

Recommendation #3: Contrast framing and shaping

When you give these phases clear names, you'll find it easier to pull the right people together to have the right conversation at the right time.

Clearly distinguish these two types of work in all communication, including in live sessions. Are we working on the problem or on the solution? Framing is about the problem, the business value, the outcome, etc. Shaping is about the technical solution. Framing is what we solve, shaping is what we build.

In terms of documents, I recommend referring to the "frame" and the "shape." This avoids misunderstandings about "pitch." Be careful with terms like "one pager" where it's not clear what work step they belong to. "Frame" is clearer because it sets expectations for who reads it and what the decision is about.

Recommendation #4: Create Frame and Shape checkpoints

Have checkpoints (in terms of approval) for the framing and shaping steps. Framed means "we are aligned on the problem and outcome, and we understand this enough to shape it." Shaped means "we can give this to someone to build and they will know what to do."

I recommend standardizing the terms. Here is a suggestion:

• Candidate — A request or idea that hasn't been framed yet.
• Frame Go — Approved to shape. Problem/outcome are tight enough and it seems there is an idea worth shaping from both a technical and product POV.
• Shape Go — Ready to build. No material unknowns from both a technical and interaction standpoint.

Pitfall #3: Mixing in non-project work

If you don’t separate out the shaped project work from incidents, urgent issues, etc, the team won't be able to focus. There will be too much WIP all the time and it will be hard to understand what is priority and what the real capacity of the team is.

Recommendation #5: Create a separate process for reactive work

Create separate capacity (time, team, rotation schedule...) for reactive / on call work. Communicate this clearly so everyone knows what work they are doing and not doing. Make the allocation/capacity explicit so you can measure when you have too much or too little.

Track urgent work with tickets. Put them in a different place or tool from the shaped project work so that they don't mix together.

Separate small things from urgent things. A bug that is not on fire should be batched for a rainy day. A bug that is on fire with an upset stakeholder needs attention. 

Project work that relies on third parties is technically reactive work. If you are waiting for a response from someone else, you don't control the cycle schedule. Better to do that work on a kanban than Shape Up style.

This is a post in the Shaping in Real Life Series. Subscribe for more posts about how to make Shape Up work in real-world teams.

What do you want to know more about? Shoot me an email and I'll respond personally or write a post here.