Shape Up: Stop Running In Circles And Ship Work That Matters By Ryan Singer

By Ben Nadel

Published 2019-08-25 in Books, Work — Comments (1)

I've been a long-time fan of the good people over at Basecamp (formerly 37 Signals). Their books, like It Doesn't Have To Be Crazy At Work, have a knack for cutting through industry mythology; and, their designs are clear and effective. I've even fantasized about pulling some of their user experience (UX) decisions into InVision. So, when I heard that Ryan Singer wrote a new book - Shape Up: Stop Running in Circles and Ship Work That Matters - I immediately prioritized reading it. And, I'm glad that I did - it's easily one of the most important books that I've read in the last few years.

Ben Nadel giving the thumbs-up to Shape Up, a book by Ryan Singer and Basecamp.

Shape Up outlines the way in which Basecamp ideates and then executes on work. It's short, simple, and to-the-point; and, it only took me about 5-hours to get through. I suggest that everyone read this book (it's free). I have no doubt that many part(s) of it will strike a chord; and, help you to pause, reflect, and take stock of your own team's internal struggles.

For me, the most meaningful take-away was the concept of Appetite. Instead of trying to create estimates based on designs, the Basecamp team starts with an "appetite" - the amount of time they wish to invest in an idea - and then shapes, hammers, and narrows-down the scope of said idea to fit into said time-frame.

And, what's more, at the end of the time-frame, if the team hasn't shipped the idea to production, the default action is to kill the project. They don't continue to add weeks and man-hours. They don't continually re-assure the leadership that it's "almost done". They stop working on it. And then, they re-evaluate the plan, try to figure out why the team couldn't ship it, and then determine whether or not the idea is worth re-thinking, re-shaping, and re-scheduling in a subsequent work-cycle.

The Circuit Breaker

We combine this uninterrupted time with a tough but extremely powerful policy. Teams have to ship the work within the amount of time that we bet. If they don't finish, by default the project doesn't get an extension. We intentionally create a risk that the project - as pitched - won't happen. This sounds severe but it's extremely helpful for everyone involved.

First, it eliminates the risk of runaway projects. We defined our appetite at the start when the project was shaped and pitched. If the project was only worth six weeks, it would be foolish to spend two, three or ten times that. Very few projects are of the "at all costs" type and absolutely must happen now. We think of this like a circuit breaker that ensures one project doesn't overload the system. One project that's taking too long will never freeze us or get in the way of new projects that could be more important.

Second, if a project doesn't finish in the six weeks, it means we did something wrong in the shaping. Instead of investing more time in a bad approach, the circuit breaker pushes us to reframe the problem. We can use the shaping track on the next six weeks to come up with a new or better solution that avoids whatever rabbit hole we fell into on the first try. Then we'll review the new pitch at the betting table to see if it really changes our odds of success before dedicating another six weeks to it.

Finally, the circuit breaker motivates teams to take more ownership over their projects. As we'll see in the next chapter, teams are given full responsibility for executing projects. That includes making trade-offs about implementation details and choosing where to cut scope. You can't ship without making hard decisions about where to stop, what to compromise, and what to leave out. A hard deadline and the chance of not shipping motivates the team to regularly question how their design and implementation decisions are affecting the scope. (Page 62-63)

I can't stop reading and re-reading this passage. There's so much here that I love. I want to force everyone at work to read this. I want them to have to sign it as part of their work-compliance; in the same way they have to participate in the employee handbook, the sexual harassment policy, and the security training. For me, the above passage is a game changer. It's something that I want to put into immediate effect for all tasks that I work on.

You can think of the appetite as another part of the problem definition. Not only do we want to solve this use case, we want to come up with a way to do it in six weeks, not three months, or - in the case of a small batch project - two weeks, not the whole six weeks.

Stating the appetite in the pitch prevents unproductive conversations. There's always a better solution. The question is, if we only care enough to spend two weeks on this now, how does this specific solution look?

Anybody can suggest expensive and complicated solutions. It takes work and design insight to get to a simple idea that fits in a small time box. Stating the appetite and embracing it as a constraint turns everyone into a partner in that process. (Page 43)

There's so much in this book that reads like a cleaner articulation of many of my half-formed feelings and frustrations. It dove-tails seamlessly with a multitude of my previous posts, like:

All of these other posts are me trying to identify, articulate, and express frustrations that I've had in my career. And, in one way or another, I feel like Shape Up touches on all of them. And, provides a framework in which overcome (or at least better understand) these problems.

For example, I love the way that they position Good vs. Great in the context of how long they are comfortable making users wait to have a solution:

It helps to shift the point of comparison. Instead of comparing up against the ideal, compare down to baseline - the current reality for customers. How do customers solve this problem today, without this feature? What's the frustrating workaround that this feature eliminates? How much longer should customers put up with something that doesn't work or wait for a solution because we aren't sure if design A might be better than design B? (Page 105)

This really frames the problem in terms of what's important: the user. They don't get bogged-down in endless iteration and a death-march towards unbounded perfection.

I've shared the parts of this book that meant the most to me. But, there's a lot more in Shape Up that I want to take back to my team. I have full confidence that there's something in here for everyone: designers, product managers, and engineers - we can all learn a thing or two about how to simplify and streamline our approach to getting things done. Read it. It's short. It's free. You have no excuses!

Short link: https://bennadel.com/3687

Reader Comments

Ben Nadel Aug 26, 2019 at 8:11 AM

15,902 Comments

@All,

One of the passages that I mention above really struck a chord in me - the idea that getting stuck in the endless iteration is "about us" and not "about the user". That's one of the realizations that I've had in the last few years, and said passage really helped me get in touch with those feelings:

www.bennadel.com/blog/3688-solutions-don-t-have-to-work-for-everyone.htm

Understanding that solutions don't have to work for everyone is freeing. It frees me up to add value every day, little by little.

Oh my chickens, this post is old!

Hit me up on Twitter if you want to discuss it further.