Product-oriented Organization

The default way to divide a company was job type for a long time: engineers with engineers, designers with designers. That is a functional organization, and it has real advantages. People doing the same craft sit together, standards are easy to hold, and teaching someone new is straightforward.

The trouble is that the unit a company ships doesn't match the unit it is divided into. Users don't receive engineering output; they receive one feature, and one feature contains product thinking, design and code. When teams are cut by craft, shipping that single feature means collecting a slot in three different schedules.

So the scene repeats. A product manager files a request with the design team, it lands behind that team's queue, and screens arrive three weeks later. By then engineering has committed to something else, so there are two more weeks of waiting. Nobody was late with anything, and a two-week feature took eight. Back when Pagedeck was twenty people, shipping one feature took four cross-team meetings on average.

A product-oriented organization solves the mismatch by moving the team boundary. The line gets redrawn around what the company is trying to ship rather than around the kind of work people do. Once a request becomes a conversation inside one team, the step where you go collect a schedule disappears entirely.

Each team gets one goal and every craft needed to ship that goal end to end. A typical team is one product manager, one designer, and three or four engineers. A forty-five-person company usually lands on five or six of them.

Cutting the org into those teams takes four steps.

1. Pick the goal units. Cut along chunks users actually experience: document editing, sharing and permissions, billing and plans. If names like engineering team and design team survive the exercise, nothing changed except the labels.
2. Fill each unit with the crafts it needs. A team missing a craft still has to file requests outside itself, so when there aren't enough people to go around, the answer is fewer teams rather than thinner ones.
3. Give each team one number to watch. For a sharing team that might be invitation acceptance rate — something the team's own work actually moves. If the goal is company-wide revenue, nothing the team does visibly moves it, and the team loses any way to judge its own work.
4. Write down what the team decides and what stays above it. Copy and release timing belong to the team; pricing structure belongs to the company, for instance. Skip this line and the team goes out for approval every time, which puts the meeting count right back where it started.

The reporting line runs one way, to the team lead. That line decides who writes the review and sets the salary, which makes it the line that matters. What disappears is the person who held the craft standard, so the shape needs a replacement mechanism: designers meeting every other week to review each other's screens, or a design system that collects reusable parts in one place.

This shape starts making sense once the product is too large to hold in one head. The threshold is the number of distinct areas, not the number of products. A single product whose editing, sharing and billing each demand different judgment already has places to cut.

By headcount it is early under thirty people and natural somewhere around forty. Split twenty people into five teams and each team has four, which means no team has a full set of crafts, which means work keeps getting requested outside the team again. That leaves you exactly where you started, with more team names.

In software companies this is close to the default. The same shape gets called a squad on the ways-of-working side, with one difference worth keeping straight: a squad is a small autonomous team owning one goal, not necessarily a formal unit drawn on the org chart.

There are places it fits badly. An agency running client projects has contracts, not products, as its unit of work, so staffing people out by craft serves it better.

The shape also costs something. Judgment now sits in each team, so after about six months the button in team A's screen and the button in team B's screen don't look the same. That is not a defect; it is what got traded for speed. Companies that adopt this shape through a reorg build the mechanism for shared standards at the same time.

"We can finish this inside the editing team. No separate design request needed."

The crafts required are already in the team, so nobody is waiting on an outside schedule.

"We cut the teams by product, but decisions still come from above."

The shape changed and the authority didn't follow.

"The sharing team's metric is invitation acceptance rate, so this quarter is clear."

Each unit now has a number its own work moves.

Pagedeck reorganized three craft teams into four product teams in the quarter it reached thirty-eight people. What Grace worked from was not a picture of the org chart but the shipping record of the previous two quarters. More than half the elapsed time on a feature was waiting rather than work, and almost all of that waiting was on another team's schedule.

Four months later the waiting had dropped to a third. In exchange, Noa turned up four screens where the same function's button looked different. Mia and Noa set up a biweekly session for the four teams' designers and merged the shared component lists into one. Theo made the code side use that same list.

The most common belief is that cutting teams by product raises speed on its own. The bottleneck before the change was requests crossing department lines, so removing those lines looks like the whole fix. But if decisions still get collected from outside the team, the waiting simply moves. Left alone, the meeting count returns to what it was with new team names attached, and nobody can say what the reorg accomplished.

The second is that craft managers stop being necessary. The team lead now has every craft in the team, so it looks that way. In practice the shape needs more people watching standards, not fewer. A lead with three engineers who isn't an engineer has no basis for judging code quality. Left alone, each team hardens around its own conventions, and six months in, anyone changing teams learns a new way of working from scratch.