How to build a team that scales

Real examples and principles on how to structure your product org as you scale

If you’re scaling a product team, one of the biggest decisions you’ll make is how to structure it.

And yet, most org design advice is oversimplified, or anchored in someone else’s org.

In reality, structure is a moving target. It shifts with your product’s maturity, your technical constraints, your team’s capabilities, and your business strategy.

An ex-CPO I once worked with told me: shape your org around people and incentives. That advice stuck with me—but it’s hard to translate into something you can actually use when building a team.

What I would have benefitted from then is what I’ll try to offer you now: principles and practical examples based on experience. I've reshaped orgs many times in my 17 years in product. I’ve made some good bets and some painful missteps. Here's what I’ve learned:

Structure Should Mirror Strategy

When I joined Funding Circle, we were still early. I was hired as the Senior Product Manager for “Borrowers”, but I also did investor-related work, because there wasn’t enough demand for a full investor team yet.

The lines were fuzzy. Bringing on institutional investors, for instance, was good for borrowers, but required “non-borrower” work. It worked because priorities, not structure, drove ownership - and we knew this change would enable a vastly improved borrower experience.

Your tech will follow that structure

Whilst at Funding Circle, we utilised the principles of Conway’s law. This law suggests that the structure of an organisation significantly influences the technical architecture of the systems it creates.

Strategically we needed to re-platform. We’d become slow. To do that we needed to chip away at our original monolithic architecture, and we started with payments.

This is why by Series D, we had five product domains: Investor, Borrower, Business Systems, Payments, and Data.

What made it work was that the use cases were distinct and the structure reflected our ambitions for where we needed the business - and the platform - to go.

Your product breadth will help guide you

I took on a fractional role where one of the challenges was a ‘lack of real product ownership’. The Founder complained the team were not user focused enough, but I could see they were trying.

Looking at it closer it was clear the product breadth was enormous. Different industries, different users and buyer types, multiple product lines. All under a single Head of Product and a product manager.

The only solution was to restructure the team for scale. We put in a broader SPM bench under a CPO to create more focus and ownership on each product area to deliver on a intentionally broad strategy.

Picking the ‘right’ buckets - what I got wrong

When I joined Multiverse, two teams were doing everything, admissions, onboarding, learning design, internal tooling. Ownership was murky.

We split by funnel: Admissions on one side, Learning on the other. That made sense—we were building an LMS and the user journeys were very different.

But over time, the split started to feel artificial. The same apprentice was being handed off between teams. Context got lost. So we restructured by user type. One team owned the apprentice experience end-to-end. Another owned the coach experience. Clarity went up, misalignment went down.

I didn’t get everything right, though.

Early on, I pushed for a growth team, because that’s what we had at Funding Circle, and when I joined the priority was building a new website. I later realised: we never should have built our own website. That was a pattern-matching mistake.

I also spun up a platform team, again based on what had worked at Funding Circle. I even hired an amazing technical PM to lead it. But we were too slow to hire around them, and the team’s mandate shifted underneath them. They left, and it stung. It was the first early departure I’d ever had that was fully my fault. I’d misjudged both timing and scope.

So you know, although there’s no perfect - the cost of doing it wrong can be painful.

Want to turn this into a plan for your team?

In the second half of this post, I’ll walk you through how to choose the right lens, questions to guide your design, and a PDF summary to take away.

Available for paid subscribers below.