Lore

Shaping the Work, Then Team-Led Discovery (37signals)

Overview

Jason Fried's alternative to upfront task assignment: a project is shaped at a rough level, then handed whole to a small team, which discovers the actual work itself as it builds.

The critique it answers

Most teams plan by lining up tasks and assigning them to people before work starts. Fried calls this 'backwards' and 'a broken way to work' — even though it's how most teams operate — because it assumes a false certainty about what the work actually is before anyone has done it.

Shaping

Before a team gets a project, someone (at 37signals, Fried/the shaper) goes through the idea and gets it to a point where the concept and its general shape can be explained — without finishing all the details. An idea at handoff is 'a malleable piece of clay,' not a finished spec; the team molds it into the final thing.

Hiring minds, not hands

Assigning fixed tasks upfront removes people's judgment from the process. Fried: 'I want 54 minds, 55 minds at our company with 55 people, I don't want four minds.' Teams are hired as problem solvers — 'that's why we hired them... I don't hire people just to type code' — so discovering the actual approach is their job, not something decided for them in advance.

Progress on a shaped project is tracked with Hill Charts: Known/Unknown Progress Tracking (vs. Percent-Complete) rather than linear percent-complete.

Related: High-Alignment/High-Autonomy Model, Three Conditions for Empowerment, Product Team (Five-Trait Definition).

Team Composition and Rationale for No Upfront Requirements

Why 37signals doesn't assign requirements upfront

Jason Fried's stated reason for not writing requirements ahead of time is that doing so limits creativity and risks locking in requirements that aren't actually best for the product — a team that discovers the work itself can find better requirements than anyone could pre-specify.

Team structure: no dedicated PM

The team that receives a shaped project is small — Fried says three people, while Mike's recap frames it as a designer-and-developer pair. There is no dedicated product manager; the designer plays that role in addition to design work ("at 37signals you kind of have to play that dual role — the designer is also acting as the PM"). Splitting requirements-writing (a PM function) from building would reintroduce the assign-and-execute pattern this approach exists to avoid. Compare with the more PM-inclusive Product Team (Five-Trait Definition) definition and the general 'Product Owner' Should Never Be a Standalone Job Title critique.

Resourcing argument

Fried also frames small autonomous teams as a resourcing argument, not just a cultural one: if you're paying for the problem-solving minds of everyone on staff (e.g., 55 people) but only a handful actually solve problems while everyone else just executes pre-set tasks, you're wasting what you hired for.