He spent 17 years at Basecamp thinking about why software teams keep building the wrong thing, then wrote down the answer. The result: Shape Up - the framework that replaced pointless sprints with something that actually ships.
There is a before and an after in how product teams plan their work. Ryan Singer wrote the after.
Here is a man who joined a three-person company in 2003, learned to code because the framework made it easy, shipped features used by millions, and spent a decade quietly documenting what actually worked. Then he put it all in a book. For free. And watched teams across the world throw their Jira backlog in the trash.
Most product frameworks arrive gift-wrapped from consultancies that have never shipped software. Shape Up arrived from someone who had been shipping it, continuously, for seventeen years. The difference shows. Where Scrum gives you ceremonies, Shape Up gives you a circuit breaker. Where other methodologies ask how long something will take, Singer asks how much it is worth - and calls that number an "appetite." If the work cannot be shaped to fit, you do not extend the deadline. You drop it.
Singer's obsession is fitness between context and form - a phrase borrowed from architect Christopher Alexander, whose theories on pattern languages Singer applied to interface design back when that crossover was considered exotic. He delivered a talk in 2010 called "Designing with Forces" that drew directly from Alexander's Notes on the Synthesis of Form. Fifteen years later, he still uses Alexander as his primary frame. "In sixteen years, I have not found any design problem in any domain where these ideas fail to apply," he says. The confidence is earned.
At 37signals, Singer's title eventually became Head of Strategy - but the arc was less a climb than a deepening. He started as a UI designer. Then he learned to code. Then he started running product. Then he started asking why the whole process kept breaking down. Shape Up is the answer to that last question, written in the voice of someone who had personally experienced every failure mode it describes.
Done is relative to what comes next.Ryan Singer
He left 37signals in 2020 after seventeen years. He moved to Portugal. He started Felt Presence - named for the felt experience of using software, which tells you everything about where his head is at. He now works as a fractional CPO and runs workshops where teams shape real projects in real time. The Shape Up book remains free online. He is still writing the next chapter.
What makes Singer unusual is that he never separated design from code from strategy. He learned HTML when Rails made it designer-friendly. He wrote technical architecture articles alongside UX essays. He applied demand-side economics (Jobs to Be Done) to product roadmapping. He used Taguchi signal-to-noise ratios as a lens on feature quality. The breadth is not dilettantism - it is the exact profile you need to see product development whole.
Singer's writing voice is the same as his design instinct - precise, undecorated, and unusually hostile to vagueness. He does not use the word "user" when he can use a specific person in a specific situation. He does not draw wireframes when he can breadboard the logic. He does not estimate when he can set an appetite. Every abstraction he removes is a bet that the concrete thing is more useful. So far, that bet has paid off.
Shape Up is not Agile with better names. It is a different set of assumptions about where time goes wrong in product development - and a systematic attack on each of them. Here are its three phases.
Appetite replaces estimates. You ask how much time this is worth, not how long it will take.Core premise of Shape Up
The insight behind Shape Up is that most software teams are running someone else's backlog. Product managers inherit lists of requests, sort them by votes or perceived importance, and hand them to engineers who have to figure out what "implement search improvements" actually means. Singer's observation is that this handoff - vague work passed to teams without solutions - is where time disappears.
Shaping solves it by making the discovery work visible and assigning it to people senior enough to have opinions. The team that builds should not also be the team that decides what to build. But they should have complete autonomy over how to build it once the shape is clear.
Singer invented the hill chart because burn-down charts lie. They show how much work is left - but not whether you know how to do it. A hill chart puts uphill work (figuring out the problem) on the left, downhill work (executing the solution) on the right. Each scope is a dot on the curve.
In 1964, architect Christopher Alexander published Notes on the Synthesis of Form - an attempt to understand how traditional cultures produced buildings that fit their contexts so well. His answer: not through genius or taste, but through accumulated pattern languages - shared vocabularies of form that encoded working solutions to recurring problems.
Singer encountered this work and never recovered from it. Where most designers borrowed Alexander's "pattern language" idea superficially (Hello, Gang of Four), Singer went further. He applied Alexander's core analytic frame - the idea that good design is about fitness between a form and its context, and that design problems are fundamentally about finding mismatches - directly to product interfaces and, eventually, to the product process itself.
The connection to Shape Up is direct. When Singer shapes a project, he is essentially writing a pattern: a solved form that fits a specific context of use. The breadboard technique encodes the logic of a problem without over-specifying the solution. This is Alexander's "unselfconscious design" in product form - the solution emerges from the forces, not from the designer's preferences.
How architectural theory became product process
Singer's other major theoretical debt is to Bob Moesta and the Jobs To Be Done framework - the idea that customers hire products to make progress in specific situations. JTBD gave Singer a vocabulary for demand-side thinking: instead of asking "who are our users?" he asks "what are they trying to accomplish and what is in the way?" The shift sounds subtle but it changes every downstream decision about what to build.
The combination - Alexander's form-context fitness plus Moesta's demand-side causality - produces something unusual in the product world: a designer who can speak precisely about why a feature is the wrong shape for the problem it is trying to solve.
Research gives us the problem, not the answer.
Done is relative to what comes next.
In sixteen years since I found out about his work, I have not yet found any type of design problem in any domain where these ideas fail to apply.
Teams should be committed to the end goal without being attached to how to get there.
I always knew personas were flawed but finally had a good way to argue against them.
Products are services - designed to help people make progress from one state to another.