When speed became the enemy of clarity

Stackline had scaled from 12 to 90 people in 18 months. The product still worked. The team's shared understanding of it had quietly stopped.

The moment of arrival

We were introduced to Stackline's CPO on a Wednesday in March. By Thursday we were in a room with eight engineers, four product managers, and a whiteboard covered in what turned out to be four separate — and mutually contradictory — diagrams of the same feature.

That's not unusual. It's actually a surprisingly reliable indicator that a company is growing fast in the right direction, but hasn't yet built the shared vocabulary to support the speed. The problem isn't strategy — it's the absence of a single legible version of it.

Our job: make the implicit explicit, then encode it into a system that could outlast us.

How we ran it

  1. Weeks 1–2

    Orientation

    Stakeholder interviews, artefact audit, friction mapping across 12 customer journeys.

  2. Weeks 3–5

    Strategy Sprint

    Product pillar workshops, three rounds of synthesis, one locked definition doc.

  3. Weeks 6–10

    System Build

    Foundations (colour, type, spacing, motion) → core components → pattern library in Figma + code.

  4. Weeks 11–12

    Handoff & Embed

    Docs, Storybook, team training, a contribution model they actually wanted to maintain.

The strategy sprint room, Week 3. The affinity map on the wall became the foundation for the product pillars.

What the audit found

Before touching a single component, we audited everything that existed. The numbers were clarifying.

  • 214

    Unique button styles

    Across 6 surfaces, 214 distinct button permutations had accumulated. No two teams shared the same definition of "primary action."

  • 0

    Shared token definitions

    Not one hex value, spacing unit, or type size was defined in a shared source of truth. Everything was local to each file.

  • 11

    Competing product definitions

    When we asked "what are the three things Stackline does?", eleven different answers emerged across the leadership team.

  • 1

    Agreed answer — after us

    After the strategy sprint, there was one. Not imposed — built together, ratified by the full team, and encoded at every level of the system.

Token architecture: primitive → semantic → component.
Core component library, published to Storybook on week 10.

What we actually built

The design system is the visible output. But the real deliverable was a team that had worked through disagreement together and arrived at conviction — not consensus. Consensus fades. Conviction compounds.

The three product pillars we defined in week four governed every component decision in weeks six through ten. When an engineer asked "why does the data table behave this way?", the answer lived in a document they'd helped write. That's not documentation. That's ownership.

At handoff, we ran a 90-minute contribution-model session with the design and engineering leads. Six weeks later, they had made 23 independent contributions to the system without any input from us. That was the goal.

Start a conversation

If your team is growing fast and your product clarity isn't keeping up, we should talk. No decks, no pitch — just a direct conversation about what's happening.