先定时间再改范围：Ryan Singer 讲 Shape Up 在真实团队里怎么落地

Singer traces Shape Up back to the first version of Basecamp in 2003, when three people were building it. Co-founder Jason Fried wanted constant forward movement, and David Heinemeier Hansson was programming only about ten hours a week, so there was intense pressure never to build something that would later be thrown away.

The other half of the story was a pair of short, intense working sessions between Singer and Fried, with a Sharpie and a big pad of paper, to crack the idea before David came back. Those sessions, Singer says, are the seed of what the book calls shaping: not a document, a requirements list or a polished Figma file, but fast collaboration until the idea was crisp enough to get a confident yes.

Because the company hired slowly and took no investment, this way of working spread organically for roughly ten years. Singer remembers the first project that stalled, with open questions and no quick answers, as the moment he realised it would not keep spreading by itself. That is when he started to formalise it so it could be reproduced as new people joined.

Singer names three ingredients. First, you do not start unless you can see the end, so rather than asking for an estimate you ask for the maximum time you are willing to spend. Second, shaping varies the scope within that fixed time, like choosing a car or a house with a budget in mind and accepting trade-offs.

Third, once a solution is doable and desirable from an experience, functional and technical standpoint, you give the whole idea to a team. He contrasts this with what he calls the "paper shredder" of splitting work into a hundred tickets and hoping it still fits together. Teams then create their own tasks, which in his experience brings much more engagement from the technical side.

Singer stresses you do not need to adopt all of it. Teams tired of rituals often want to grab the six-week freedom first, but that only works if shaping gives the team enough clarity. Quoting Bob Moesta, he says you can't put ten pounds into a five-pound bag, and telling a team to "vary your scope" on an unshaped project is cruel.

Lenny contrasts this with two-week sprints. Singer replies that six weeks is only a maximum: for a six-month chunk there are too many unknowns to see, but at six weeks you can shape something and surface the complexity up front. Growth teams can still use the technique for two-week projects, and some teams prefer four weeks.

On what happens when time runs out, Singer pushes back on the simple idea of cutting scope. In real product work you cannot drop the pieces that made the project valuable, and doing so hurts morale and leaves a sense of debt going into the next cycle. Basecamp's "circuit breaker" meant cancelling a project that was not on track, but few teams have the stomach for that.

The more palatable version is to stop reinvesting in something you do not understand and take it back into shaping mode. That may involve different people asking different questions to find what is fuzzy before anyone gives it another go. Singer says he has seen adoptions that amount to "just cut scope", and he says that is not the method.

Singer says the shaping step is crucial and that Parkinson's-law logic does not hold for real feature work. Shaping means finding the main moving parts of the problem and the solution, and how they connect. He teaches live shaping sessions that include a senior engineer who really knows where the bodies are buried, a product person who understands why this is an opportunity, and a designer, all whiteboarding together.

He also prefers the term time box to cycle: teams with several parallel teams may want a fixed cadence, but a small team can simply set one time box after another. What matters is that the time budget pushes back on what you shape.

On company size, Singer says it works even at very large organisations. He mentions friends in pharmaceutical clinical trials where a few teams in important areas work this way. It takes a senior engineering leader who can untangle systems so one can be worked on independently, and who can protect the team's capacity for the duration.

For reconciling with a quarterly or six-month company rhythm, he has seen teams run five weeks plus a one-week cool-down so cycles add up to a quarter. Others simply deliver meaningful work consistently, so that at executive reviews they can say what they promised is finished, which is what leaders want to see.

Singer defines shaping partly by what it is not. When product teams hand over a PRD or many Figma files, contact with engineering triggers a reality check and a return to the drawing board. A UI also hides flows, logic and what happens behind the scenes, so he uses a home-renovation analogy: a perfect rendering of bedside lamps is worthless if nobody checked whether there is electricity in the wall.

His worked example is the calendar from the book. Instead of building "a calendar", the team first framed the problem: customers needed to see empty spaces, which the existing agenda view could not show. The solution then had fewer than ten moving pieces, which he offers as a rule of thumb for a well-shaped idea.

Those pieces were two months side by side with dots marking days, an agenda view that slides underneath when you tap a day, month navigation and a create button. That is not a calendar, he says, but a two-month dot grid with an agenda below, and it supports a realistic conversation about whether six weeks is enough. Lenny summarises it as key components and flows, not a spec, final design or user story, and Singer agrees.

Lenny asks whether engineers will resent a detailed plan. Singer says the dominant failure he sees, again and again, is not enough detail, and engineers going back to product to say they are not getting enough. Still, nobody wants to be told how to implement a database schema.

He treats detail as a dial. With a junior builder, a senior engineer in shaping can suggest an approach, because juniors tend to hide being lost until it blows up later. Over a few projects you can dial back, and with stellar, trusted people you can leave more out. If someone on the build team wants a say in the fundamental approach, he suggests bringing them into the shaping session in the technical role.

The point is to de-risk the biggest unknowns. In a fintech onboarding example, a team planned to remove a step by piping data from bank partners, only for the code to reveal three different branches depending on the bank. Found in week four it would hurt, but found in shaping, with what he calls a "grumpy old plumber" opening the walls first, it becomes a useful trade-off conversation about which branches are worth doing.

Singer says people are not used to working so fast in a workshop. Starting from a narrowed problem (the empty-spaces framing) and a business willingness to spend six weeks, the group draws ideas and tries to break them. The technical person looks for where an idea will fail, while the product person checks whether it delivers value in the customer scenario.

He coaches people not to stay stuck in one idea for hours but to step back and sketch a very different alternative, for example a month-only view without the agenda. Three-hour sessions can be productive, then people think or run a spike and reconvene, and for a project that uses existing technology he expects an answer in about three sessions.

Everyone needed has to be in the room, or it can all blow up when the technical person sees it later. Figma has its place once you know where the sink goes, he says, but in shaping you need lower-fidelity tools such as breadboarding and fat-marker sketches. They must still communicate the idea clearly, because a blurry wireframe saying a dashboard has four reports does not tell anyone what to build.

Teams sometimes adopt the six-week cycle only to escape Scrum rituals. Singer says that without shaping they do not know what to do, end up scrambling to shape as they go, and run out of time. It is nice to get a break from rituals, but they cannot celebrate launches again and again.

Asked how this differs from a sprint kickoff, Singer says in many Scrum teams the tickets are written by someone who is not doing the building and who may not understand the work. Shape Up gives builders one shaped idea and trusts the professionals to make their own tasks, as contractors know the plans without being told which tool to pick up.

For teams that are not all senior, he suggests a kickoff exercise: draw a grid of nine boxes and have the builders list the nine major chunks of implementation. Six weeks is 30 business days, so nine boxes is roughly four days each. The exercise exposes too much scope and gives seniors a chance to coach, and he thinks more than ten items drifts into "ticket land", speculating that nine is the upper end of seven plus or minus two.

To start, Singer suggests picking a problem that matters, is timely and is large enough to feel like an achievement, even if the first box is only three or four weeks. Narrow the problem, hold a shaping session, and do your best; the available engineering team sets the limit on how long you can spend shaping, perhaps a week.

Singer notes that getting product and engineering into one room is already far along. His advice to sceptical teams is to wait until it hurts more, because changing is hard and the method is not the only way. If you have already cycled through a head of product or a CTO and still have the same problems, that is the moment to try something different.

The pain appears at several stages: a fuzzy request like "calendar" or "dashboard" that becomes an ever-expanding blob, Figma files that meet engineering pushback, PRDs nobody absorbs, and builds where questions and complexity keep multiplying. He is gentle about the work, saying the Figma file is beautiful but arrives early and the PRD contains true things but is packaged so it is not absorbed.

On the "feature factory" critique, he says a team that keeps cranking out features is probably healthy and may only need a different input at the start. The more widespread struggle, in his experience, is that stuff drags, nobody can see the end, and people feel burned out.

Singer says the method was not formalised at Basecamp until it had to be, and the tipping point is usually when founders start delegating to the first hires. They ask how to be fast again, and winging it on Kanban fails because new people lack clarity and need babysitting. A later extreme is a company with revenue but an entrenched engineering team separated from an entrenched product team, with finger-pointing at the executive level.

Most of his clients, he says, remember being fast and are now newly too big. By the time he hears about it, product and engineering together are often 30 to 50 people, though he thinks the seeds appear at the first project handed off, when someone other than the founder is expected to carry it through and it misses expectations.

On roles, he says PMs often spend their time chasing work inside the time box, which drifts toward project management. On Shape Up teams that hit their stride, the PM moves upstream to understand the business context, narrow the problem, negotiate with leadership and find the valuable slice worth a few weeks. Lenny sees a parallel with AI: as building gets cheaper, deciding what to build matters more.

Singer says he did not realise how unique Basecamp was until he left. Every designer coded, so there was no wall between design and engineering; the founders were close to the problem; and with no sales or marketing organisation, there was no contention for engineering time. David kept clear six-week runways in engineering year after year, and the team avoided getting lost in refactoring and technical debt.

That does not mean you must be Basecamp to use Shape Up, but a team with a wall between engineering and design has to work out who to bring together and how to share the knowledge that at Basecamp lived in a single head. Singer says he was a visitor in a foreign country, not someone who found the method broken.

When outside teams said projects kept running over, he asked to see their shaping work and was shown PRDs or Figma files, with no engineer in the picture. On his first consulting project he had the best-suited engineer join product in shaping, and he felt back in the world he knew. He says this lesson led to his course, which is about closing the gaps between the book and typical team structures.

Singer also discusses a possible second edition from 37signals, whose style is to show clearly how they do it. He thinks a book that only documents Basecamp would miss people who need to know how to get closer from where they are, so his own focus stays on those gaps.

Singer notes that some teams who reach out about stalled shipping actually have an unclear input at the start: they do not know what matters to customers or where the value is. That is the link between framing and product strategy. For that stage he reaches for Bob Moesta's Jobs-to-be-Done and demand-side work, with Shape Up covering the supply side of turning an opportunity into something shippable.

His most recommended book for that mindset is Demand-Side Sales 101, which he says is very good at probing what people are really trying to solve, even though it is aimed at sales. For the general spirit of Jobs-to-be-Done he points to Competing Against Luck, written by Clay Christensen.

For consulting, a CPO or CTO usually reaches out first, and it works best when product and engineering heads agree there is a problem. He then helps pick a pilot team and project, narrows the framing, and coaches the team through shaping sessions with feedback rounds. People can find him at ryansinger.co, and he says he learns by hearing from teams who are stuck.