In the Hollywood version of the tech industry, all product teams evolve in the same way.

It starts with a handful of brilliant, eccentric founders working out of a garage, obsessing over every detail of their world-changing product. In no time at all, the product takes off, and the company moves to a gleaming campus, staffed by hordes of developers, all working diligently at their small part of the great design.

It’s an inspiring story, but it’s missing a lot in the middle.

In real life, finding the right structure for your product team as you scale is a huge challenge for growing SaaS companies. That’s because the structures that worked at the garage stage won’t make sense when it’s time to delegate duties to multiple teams working on a host of products. And the first thing that usually gets lost in translation is the customer’s needs.

If you’re a SaaS startup, you have to accept that in order to uphold your commitment to the customer, your product team structure needs to evolve.

Product Team Structure Stage 1: The Garage Era

Let’s call this the “garage era” of a SaaS company: pre-funding startups and shops with 20 or fewer employees. At this stage, everyone in your company should be ferociously dedicated to acquiring and serving customers by creating a product that meets a legitimate need. (If this seed of an idea doesn’t resonate with users, your company won’t get past this first stage.)

When a company and its roster of products are still this small, dividing product managers (PMs) by feature doesn’t make sense. Instead, PMs should own a specific area of expertise across all products. So, one PM might be your user experience guru, while another handles budgeting. This structure allows everyone to serve the customer according to their strengths since the company doesn’t yet have enough people to build product teams with diverse skill sets.

Elad Gil—entrepreneur, investor, and author of High Growth Handbook—says there are four types of product managers: business, technical, design, and growth—each with a different balance of engineering skills, business acumen, creativity, and ability to interface with customers. In a big company, each of these areas will have multiple product teams assigned to them, and each team will be able to fully take ownership of whatever feature they’re working on. But at this early stage, PMs can deliver greater value and faster releases by jumping in where they’re needed most.

The danger of this skill-based organizational structure is that it doesn’t scale well. When your entire company can fit in one room, there’s an inevitable sense of shared accountability and ownership, and asking for help is as simple as turning to the person next to you. But larger companies can’t afford to have PMs flitting from project to project with no real ownership over any of them.

There’s also the risk that if one of your core PMs leaves the company, they take their expertise with them, so it’s important to recognize that this structure is a starting point. Plan for the future by hiring team members with well-rounded skill sets that can build out more autonomous product teams.

Product Team Structure Stage 2: The Scale-Up Era

Most funded startups and midsize SaaS companies share the same product team structure: a PM leads a team of 5-8 people who focus on a single feature at a time. However, most companies get this structure wrong because they focus on continuous delivery and forget about validating success through customer feedback.

Product teams end up working in isolated (and sometimes even competing) bubbles, needlessly siloing data instead of collaborating and sharing insights on user response. They forget that the essence of Agile isn’t to deliver for the sake of delivering but to iterate quickly in service to the customer.

The solution is a tweak to the “one feature, one PM” structure that places much greater emphasis on validation and communication. Each product team needs to take responsibility for working closely with users after delivery through qualitative feedback. That feedback then becomes the connective tissue that ties all the teams together, guiding product discovery, and setting priorities for the whole company.

In practice, that means constant communication across teams, and especially between PMs, so that everyone has the opportunity to learn from each other’s iterations, and ensure that features are designed and released to create a coherent customer experience—not just a jumble of features.

Panagiotis Goros, product director at Upstream, has written that this structure does require product teams to trade a certain amount of delivery speed.

“Horizontal functional groups will need to be formed so that expertise and best practices can be spread across teams. Product managers will need to make sure that they over-communicate and are constantly aligned with their peers. And all this takes time.”

Despite the sacrifices it entails, this level of horizontal communication is the best way for product teams to avoid falling into the trap of so many midsize SaaS companies: The essence of the product that made it compelling to users in the beginning is lost because teams become too specialized and lose sight of the bigger picture.

Of course, once a company reaches a certain size, this constant communication becomes overly time-consuming and unfeasible, so a new structure is needed.

Product Team Structure Stage 3: The Big Leagues

Once a company makes it to the big leagues (the part at the end of the movie where all the founders are rich but vaguely unhappy), they can either structure product teams to maintain the status quo or strive for continual innovation and expansion. Let’s assume you’re more intrigued by the latter option, in which case you should look at the team structure favored by Amazon, Spotify, and Hubspot.

Spotify calls these teams “squads,” while Amazon often alludes to “two-pizza” teams, in reference to Jeff Bezos’ famous axiom that teams should be small enough to be fed with two pizzas. Whatever you call it, in this formulation, PMs oversee small teams of developers, designers, and analysts that work with a high degree of autonomy and deliver quickly with little executive oversight.

The advantage of this model is that product teams have greater ownership of and accountability for their releases, and it allows large companies to continue innovating without getting tied up in their own bureaucracy.

Image courtesy of Hubspot

In some ways, this model superficially resembles the structure in phase 2, in that we see lots of small teams working relatively independently of one another. But this also harkens back to the expertise model of phase 1. At both Spotify and Amazon, product teams develop knowledge and tools that are designed to be used across the company. It’s the difference between having teams that design a widget and teams that design a widget factory.

A great example of this is Amazon’s development of Echo. The company started as all good product development should: with a vision of what the end product would do and how it would serve customers (even writing a “press release” for the future product), and then reverse-engineered it. The process took years, but in that time, Amazon’s teams became experts on technologies that would benefit the whole company.

To quote the Guardian: “Machine learning technologies are so fundamental, and so general purpose, that every advancement Amazon makes ricochets throughout its business, increasing efficiency, opening up new fields, and suggesting further avenues of research.”

However, just as with the other product team structures we’ve discussed, there’s a risk here that the voice of the customer gets lost. Plenty of SaaS companies attempt to replicate “the Spotify model,” but focus more on becoming “feature factories” than listening to their customers, preferring to offload that duty onto separate customer success teams.

The key to keeping the customer centered at scale is to hire and empower PMs you trust to embody the customer-first value, and who don’t shy away from seeking feedback as one of the central responsibilities of product management.

Your Product Team’s Structure = Your Product’s Destiny

In rapidly-evolving SaaS companies, it’s easy to treat product team structure as an afterthought and rely too heavily on the brilliance of your developers or the brilliance of your original product. But the difference between teams working in harmony and teams working in isolation is the difference between a symphony and a cacophony.

Always remember that your users are your audience, and they’re acutely sensitive to discord. There will inevitably be challenges in changing your organizational structure to evolve with your company. But as long as you always know who is responsible for your end user, you’ll never stray too far off course.