Ryan Singer

April 27, 2022

20. Framing

Over the last few months I've worked with teams to help them adapt Shape Up to their specific context. Talking to a wider variety of teams has been eye-opening. It's helped me discover many hidden factors that were present at Basecamp when I first wrote the book. This is now leading to a whole new iteration of the process and steps tha...
Read more

November 9, 2021

19. Two kinds of usability

A reader asked on Twitter: “Any recommendations on how to combine Shape Up and usability testing? When is the good timing for it? Should it be included in the cycle? Who should take responsibility for it?” To answer this, I first divide usability problems into two kinds: 1. Perceptual: "They couldn't figure out what to do next", "they ...
Read more

October 29, 2021

18. Dependencies vs. unknowns when sequencing

A good question came up from a long-time Shape Up adopter: “ I’ve noticed you mention two slightly different methods for sequencing: • The interrelationships diagram • Getting to the most unknowns first Have you landed on a preference yet? Are there circumstances where one is better than the other?” To answer, here's an example from a ...
Read more

October 14, 2021

News: I'm giving a workshop on how to hand off and break down work

I'm interrupting the normal newsletter format to let you know about a workshop I'm giving. It's called The Confident Handoff. I'm giving it remotely to a small group of early adopters on November 22-23. Handoff is that point in time where the pitch goes to the build team to start the cycle. Why give a workshop about it? Whenever I ask ...
Read more

August 17, 2021

17. Shape Up is for features, not all development work

I'm seeing a pattern among successful Shape Up teams. Companies first try Shape Up on a product team that builds features. They discover a new rhythm of shaping and shipping meaningful changes, and it feels like a victory. Then, they think "well since Shape Up is working ... we should try to do all development this way." But it turns o...
Read more

August 3, 2021

16. "Done" is relative to what comes next

Right now I'm at the very beginning of a project with lots of unknowns. Starting it exposed me to a common pitfall where scope expands very early in the first steps of a project. I want to prototype a drag and drop interface to do this kick-off exercise. My plan of attack looks like the screenshot below. I sketched eight scopes at the ...
Read more

July 29, 2021

15. Systemizing kick-off

Recently I tried a new exercise to systemize the way we kick off projects. Kick-off is that moment when the person who shaped the work hands it off to the development team. It's an important moment in Shape Up because the dev team takes full responsibility for interpreting the pitch, defining tasks, and coming up with the concrete solu...
Read more

July 28, 2021

14. Small tools for shaping

I'm experimenting with ways to demonstrate the path from a raw idea to a well-shaped pitch. That is, how to go from "I think we should spend time on X" to "here's a specific concept for X that we're confident we can ship in six weeks." Sometimes I have a clear concept in my head from the very beginning, and I just need to sketch it out...
Read more

June 14, 2021

13. Beyond to-dos

When work is turned into tickets, our brains shut off. In ticket-land, the work is a given, and it's just a matter of "doing it." This is true for any traditional to-do software. The thing is, when smart people tackle work, they actually do work on the work to figure out what the work is. They do it in their heads or on paper next to t...
Read more

April 20, 2021

12. Matching problems to business imperatives

I keep getting questions about the work that happens before shaping a project. How do we decide if a problem is worth shaping? When does a problem deserve further research to frame the problem better? To answer this, our natural instinct is to weigh problems against each other. We ask “is this problem worse than that one?” or “which pr...
Read more

April 13, 2021

11. Research gives us the problem, not the answer

I often get asked about how research fits into timeboxed work. If a team is working in a cycle and they can’t decide on a direction, should they do research? How do they fit that in a fixed timebox? This cuts to a fundamental question of where research belongs. If the team can’t decide which of multiple directions is better, it means t...
Read more

April 12, 2021

10. Some solution vs. no solution

It’s natural to argue over what is the best, most perfect solution. Who would want to build anything less? This is especially true when we have our design or development hats on with a specific idea we hope to see in the final product. But it turns out that in the shaping phase, what’s “best” isn’t always the right question to ask. I’m...
Read more

April 9, 2021

9. Shorthand for shaping

Here’s a look at some shorthand I’ve been playing with, early in the shaping process. I use this when I have a bunch of stuff in my head for a design but I don’t know where to start. I don’t know if all the pieces are going to combine or not. I don’t want to just start randomly and find out that I’ve painted myself in a corner, hit a d...
Read more

April 9, 2021

8. Team Integrated and Team Modular

A Shape Up reader wrote an email asking: “1) I work for a company building custom software for different clients. Many times our clients don't have the budget to pay for full-time programmers and designers for six weeks . . . the cost is kind of high for a small business. 2) How do the roles of frontend and backend work? What if a proj...
Read more

April 9, 2021

7. Orthogonality is a choice

There are many definitions of orthogonality. For the overlapping worlds of design, engineering and business, we can summarize with this question: what needs to be solved together as one whole, and what can be solved separately? Two things are orthogonal if we can work on one of them without having to get into the details of the other. ...
Read more

April 9, 2021

6. Work that energizes

After a few newsletters about defining work with pattern languages, a friend of mine said: "I don't get it. These pattern languages just look like outlines or specs. What's different?" Well, okay ... at one level it is just a spec. And maybe focusing too much on the pattern language format is misleading, because a format alone doesn't ...
Read more

April 9, 2021

5. Video: Shaping a feature and writing a pattern language

In Christopher Alexander: A Primer I talked about project-specific pattern languages (49:02). Since then, I've shaped a handful of features for Basecamp 4 using pattern languages. The last couple newsletters gave a peek at that process (#3, #4). I have enough reps now that I'm ready to share more. So earlier this week, when it was time...
Read more

April 9, 2021

4. Measuring usage with a Taguchi signal/noise ratio

Bob's been slowly schooling me in Taguchi methods over the last couple years. I'm starting to make some small steps towards applying them to software projects. My favorite so far is the signal/noise metric. Here's how I understand it so far. How do we know if a product is working "as it should" for people? For example, we could write a...
Read more

April 9, 2021

3. Shaping with pattern languages

I'm re-reading Battle by Christopher Alexander. It shows the exact steps he took to design and build the Eishin Campus in Japan. I feel like a student in a master class when I'm reading this. The phases he went through map very well to Shape Up concepts, but his methods are worked out more precisely, more robustly, and seem more mature...
Read more

April 9, 2021

2. Shaping on the demand side

One day, back in April, I was shaping some work for Basecamp 4 (the next version of Basecamp that we're planning to build next year). At 4:00 p.m. I got an alert from Basecamp's Automated Check-in, asking: "What have you worked on?" Normally I write a few bullet-points to summarize what I did. I felt hesitant and anxious about answerin...
Read more

April 9, 2021

1. Unfolding the interrelationship diagram

A while back, I learned this technique from Bob. Sometimes I'm working on a design problem, and there are too many things to solve. They all seem tangled together, and I don't know where to start. I'm afraid that if I start on the wrong thing, I'll paint myself in a corner or go down the wrong path and have to start all over again. A t...
Read more