Beyond the Squad Model: Why We're Centralising Product Strategy

Going from zero to 15 million members is a wild ride. For nearly a decade, we’ve been on a mission at Muzz, and the journey has been one of constant evolution. Our team has grown from a handful of people in a room to a global staff of 150, with product and engineering making up about half of that.

More users means more load, more support tickets, and more complexity. That part is obvious; it scales linearly. The real challenge, the one that sneaks up on you, is how your organisation scales. Team growth strains everything from leadership bandwidth to processes and tools, and it doesn’t scale in a straight line. One month, your process works; the next, it’s a bottleneck grinding the entire company to a halt.

We recently hit one of those critical inflection points at Muzz. I wanted to take a moment to reflect on our journey and share the lessons we’ve learned navigating the chaos of the startup and scale-up world. This isn't a one-size-fits-all playbook, but perhaps our challenges will strike a chord.

Act I: The Startup Years

For the first few years, we kept the team small and lean. Everything flowed from our CEO, Shaz, and this model was our superpower. He had the vision, and the team had one job: ship. It was chaotic, with minimal process, but it was arguably the most productive time in our history, not in the scale of what we could build, but in the sheer speed we could get ideas out the door.

Then came COVID. It was an interesting time for dating apps. If people can’t meet, why would they date? The answer was connection through chat, then through voice and video. While the biggest apps in the world took over a year to react, we went from idea to live video calls in just five weeks. This was our edge.

What was "product management" at this point? Honestly, it didn't matter. It was the common-sense decisions made by one or two people with a clear vision, trying to find what fit for our customers. At that scale, the term has no meaning; you just build.

Act II: Moving into Scale-Up territory

The startup phase doesn’t last forever. Two things inevitably happen: the team grows, and you run out of obvious things to build. For us, these happened at the same time. The team expanded because we wanted to do more, and the product itself was now a solid, mature dating app with a mature feature set competitive with the major dating apps.

Then came the brick wall. A few high-profile features didn't land as expected. We were trying to solve every product, design, and technical decision upfront, and our time was stretched to its limit. It was clear we needed to evolve.

Enter the Squad model

Inspired by Spotify, we moved to a squad model: cross-functional teams focused on key business drivers like Acquisition, Retention, and Revenue. We gave them autonomy and a north star metric. They decided what to prioritise, how to design it and delivered it.

During this time we became even more experiment driven moving to a model where every piece of work has a single question hypothesis to be proved or not. This has allowed us to always ask ourselves what's the quickest way to prove this out. If we don't need to do product work then great. This has been a huge success and will always be part of the way Muzz operates now.

In many ways, it was a success. It decentralised decision-making and forced our teams to think more deeply about the product than ever before. It also freed up senior leadership from the day-to-day grind. The team has done an excellent job making this model work and it's been great to see the dedication people have shown to improving their north star. Any criticism in this article is solely reserved for the model rather than the team who couldn't have done better.

But this model came with hidden costs.

The Trade-Offs of Autonomy

When you give a squad a single metric to own, you introduce new, subtle problems:

1. Incrementalism becomes the default. The model incentivised squads prioritise sure-fire, small wins to show steady progress, while big, risky bets are often avoided unless mandated from the top.
2. Local optimisation. Teams can get stuck iterating on the same ideas for their specific metric, losing sight of whether more time spent in that area is actually good value for the company as a whole.
3. The problem-space gets neglected. Deep, research like understanding new markets or complex retention drivers is too big for any single squad to own. This work either gets ignored or it holds up the solution space.
4. Strategic work gets sidelined. Big, cross-cutting initiatives that don't neatly map to one squad's north star are almost impossible to prioritise. This is especially dangerous for monetisation, where it can encourage a slow drift towards features that extract value rather than create it.

We had built a system of highly effective local teams, but we were losing our ability to make cohesive, strategic moves as one company. We also realised that with all the product experience built up over the years by the leadership team we were too disconnected from the product itself.

Act III: The New Model: Centralised Strategy, Decentralised Execution

So, how are we solving this? We’re evolving again. We are moving all product strategy into a central team and planning work in quarterly initiatives.

The Product Strategy Squad: This team lives exclusively in the problem space. It’s made up of Product Managers, User Researchers, and Data Analysts. Their only job is to do the deep, company level research needed to identify the most important problems and opportunities for Muzz. They validate ideas from leadership and generate their own, packaging their findings into "Initiatives."

An Initiative is a tightly defined problem statement, backed by qualitative and quantitative data. It’s broad enough to give the execution squads creative freedom but constrained enough to provide clear direction.

The Execution Squads: Each quarter, our execution squads are given a roadmap of these initiatives. This gives them clarity and focus, and it allows the entire company to see what we’re building and why. Crucially, it also frees up our talented execution squads to do what they do best: solve problems creatively and ship incredible features.

Within the squad, the Product Designer takes the initiative and leads the solution discovery. The Product Analyst is embedded from start to finish, defining success metrics upfront and owning the analysis at the end. And to ensure the entire process runs smoothly, we've introduced a new role: the Delivery Lead, who is responsible for the squad's execution, unblocking the team, and managing the delivery flow.

In this new model initiatives will be driven from the top but our focus must still be on validating the initiative in the smallest experiment possible so that we can quickly kill off initiatives we shouldn't spend our time on. The end analysis of every project will be assessed by the leadership team so we make a decision on how proceed. This is exactly how we ask the squads to operate right now so in many ways it's business as usual.

In this new world, we no longer need a traditional PM in the execution squad because the responsibilities have been intentionally distributed: strategy to the central team, design discovery to the Product Designer, and delivery to the Delivery Lead.

Our Product Principles

1. Always add value - Are we adding value or just adding something? - For the customer or the company
2. MVP first mindset - For every first release we ask ourselves what we would keep if we only had 50% of the time - the rest can follow - Good enough is often the best approach first
3. Momentum fuels motivation - Short term wins should always be on the go
4. Long term adaptable vision - We should not just be solving problems forever - we should have an aspiration for how we think the product should look in 1-5 years and work towards it but be willing to adapt as we see results

The Journey Ahead

This is a significant shift, and it’s only possible because of the years we’ve invested in building an excellent design function, a strong engineering culture, and an experienced Product Leadership team to guide the process. Interestingly, as we looked for inspiration, we saw that other major companies like Airbnb have made similar moves for similar reasons.

We’re still early on this new journey. There will be challenges to iron out and processes to refine. But we believe this model gives us the best of both worlds: the strategic coherence of our early days and the scalable, autonomous execution of our scale-up phase. It’s how we plan to build the future of Muzz for the next 15 million members and beyond.