Timeless-Customer Team Structure
Organize teams around customers and problems that never end, not around product surfaces that do.
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 90%
Most companies organize product teams around surfaces — the app team, the dashboard team, the podcasting team — and then reorg every time the surface mix changes. Substack instead organizes around customer types and timeless missions: a writer team, a reader team, a growth team, plus a systems team keeping the lights on. Because you are never done serving writers, never done serving readers, and never done with growth, the structure survives growth instead of being invalidated by it.
Origin
Sachin Monga's structure at Substack, explicitly framed against his seven years at Facebook where team structures were reorganized roughly every three to six months.
Core principles
- 01A team's charter should be a customer and a mission, not a surface area.
- 02Surfaces are ephemeral — the product du jour. Customers are permanent.
- 03The right test for a charter: can you ever check this box? If yes, it will produce a reorg.
- 04Not every team needs a PM — infrastructure teams can run without one.
- 05Structure durability is a signal you chose the right axis, not a sign of stagnation.
How to run it
- 1
List your candidate team axes
Write out the surface-based split you would naturally make (app, dashboard, podcasting, editor) and the customer-based split alongside it (writers, readers, growth).
- 2
Apply the 'can you ever be done?' test
For each candidate charter, ask whether it is a problem you could ever finish. 'Serving writers' can never be finished. 'Ship the podcasting surface' can. Keep only the charters you can never complete.
Pro tip This test is what makes the structure durable — a completable charter guarantees a future reorg.
- 3
Staff each customer team full-stack
Give each team a PM, an engineering manager, a data person or designer, and engineers, so it can own the customer end-to-end across whatever surfaces that customer touches.
Watch out Half-staffed customer teams end up depending on surface owners and quietly revert to a surface-based structure.
- 4
Add an unowned systems team
Run a separate engineering team for infrastructure and scale with no product manager on it. It keeps the lights on without distorting the customer-mission axis.
Pro tip Explicitly saying 'this team has no PM' prevents the reflex to force product process onto infrastructure work.
- 5
Scale by adding teams, not by re-cutting the axis
As the company grows, add more teams under the same customer/mission logic rather than reorganizing around whatever surface is hot this quarter.
In the wild
Coming from zero PMs, around 15 engineers and a handful of designers, Monga built four PM-led product teams — writer, reader, growth — plus a systems engineering team with no PM. The teams map to customers and enduring missions, never to surfaces like the app or the podcast product.
→ The structure held stable through a period of rapid hiring and product expansion — something Monga contrasts with Facebook, where he says structure was reorganized every three to six months.
Because Substack's supply drives its demand — writers promote their newsletters and bring readers with them — the writer team came first and a concerted reader focus only started later, once the platform needed to own demand-side experience directly.
→ Substack could delay demand-side investment without stalling growth, then stand up a reader team on the same durable axis when the network stage required it.
Common mistakes
Organizing around the product du jour
A team named after a surface — the app team, the podcasting team — dies or gets reorganized when the surface's priority changes, taking institutional knowledge and morale with it.
Chasing the perfect structure
Monga's companion point is that no process or structure stays optimal — the only durable goal is whether the team is getting better every week, every month, every year. Optimizing for structural perfection wastes cycles that compound elsewhere.
Is it for you?
Best for
First heads of product and founders standing up a product function at a company transitioning from founder-led shipping to structured teams.
Not ideal for
Companies whose customer is genuinely singular and undifferentiated, or where deep platform/surface specialisation is the actual bottleneck.
From the transcript
“the teams aren't oriented around product surfaces. Like we don't have a team that's like the app team or a team that's like the dashboard…”
“we'll never be done serving writers. We just started honestly having a concerted focus on serving readers. Growth is never a a problem that you…”
“I really like the the focus on a customer and a timeless mission really rather than orienting around what might be a bit more of…”
“And I should mention we have a fourth engineering team that's like the systems team that doesn't have a product manager on it but is…”
From the episode
Building Substack
Sachin Monga (Substack, Facebook)