Product Development Team Structure for SaaS Organizations

Product development teams are the most crucial point in any SaaS pipeline. Despite that, many SaaS startups have little if anything in the way of team organization. When you first launch, chances are, roles and teams are poorly defined, if at all. Everyone takes on multiple roles and does what’s needed to get things done. As your organization begins to scale, new employees onboard, volume increases, and structure becomes critical to maintaining output. 

Structuring product development teams typically requires adopting a framework, deciding on a priority structure, and valuing work across your organization. This article includes basic information for structuring product dev teams and offers some tips and advice from the book, Vision to Value. 

Team Frameworks for Product Development 

Product development teams should almost always work using an Agile framework. Why? Waterfall frameworks, using massive upfront planning, leave no room for mistakes or major obstacles. If you determine something can’t be built 5 months into the process, everything must be scrapped and you have to start over. Agile allows you to develop in small, flexible steps, make changes based on obstacles as you go, and essentially work backwards from creating value to how your product must start. 

Of course, Agile comes in many “flavors” and you’re free to choose the model you want. At Nmbrs, we use a variation of the Spotify Model. 

Spotify Model – The Spotify model is based on the Agile framework, with the addition of a cross-functional structure integrating teams together based on functionality, expertise, and role. So, while teams are composed of people from different disciplines, those people are connected to other persons with the same business area, area (such as “Front-end), and common interests (such as “Quality Assurance”). These cross-functional groups allow Spotify to create small, highly autonomous squads that remain connected to others across the organization. It’s a great way to implement Agile and cross-functionality, without creating silos or isolating experts.

Some other, very popular, agile-based frameworks include Scrum, Crystal, Dynamic Systems Development, and Feature-Driven Development. 

Your best option is to research your options and choose a model that best-suits your organization. Of these, Scrum is the most popular. You could also develop your own, but with hundreds of quality team frameworks and models on the market, it’s faster and more efficient to adopt something and adapt it to your needs. 

Building Cross-Functional Teams 

In most cases, product development teams should be cross-functional because it enables you to better utilize skills from across departments, rather than forcing teams to transfer work between teams. Why is this a good thing? Giving teams full ownership of a module or feature allows them to work on that feature at their own pace, with no bottlenecks, and no delays except where features or models interact with other parts of the application. It’s faster, more efficient, and allows your team to be as innovative as necessary to solve presented problems. 

Start with Responsibilities – Teams are normally designed around a “purpose” or “goal” such as “delivering a mobile experience”. This can result in difficulty as that goal or purpose is completed or changed. For this reason, you should consider designing teams around responsibilities. In this case, “maintaining application code” and then assigning that team to the module. If the module changes or becomes obsolete, the team purpose doesn’t have to change to assign the team to something else. At the same time, it’s important to assign teams to individual features and models because this ensures everything is stable and attended to. 

Choosing Roles – Team roles should be chosen based on the team purpose, so that individual skill sets are aligned with those goals. While there is no one-size-fits all structure for product development teams, the following roles add value to development. 

• Product Owner – The product owner is responsible for backlog and its prioritization, aligned with stakeholder expectations. This person may also be a QA. 
• Scrum Master – The role of any scrum master is to remove impediments. A good scrum master also focuses on teaching teams to identify impediments autonomously, eventually making themselves obsolete. Most product development teams should have access to a scrum master, even an external one, for support, operations maintenance, and day-to-day work that would detract from team productivity. 
• Developer – Most teams need at least 2-4. 
• Quality Assurance – Integrating QA into development means better quality assurance, more in-depth testing, and quality assurance that begins when development does. If the QA is part of the team, they understand the use case, how it works, and can begin validation to ensure the user perspective is brought in from the start. Here, the QA takes on the role of quality engineer, everyone tests quality, QA processes are automated so that code can continuously be tested. 
• Customer Support – Support consultants are a direct line to the customer and will bring the user’s voice and perspective to development. Integrations can take two forms, either directly implementing someone from third line into a maintenance team, or including support consultants in kickoffs, planning, quality assurance, and in weekly meetings to “touch base”. 

Size – Small teams are agile, flexible, and can quickly make decisions. Larger teams are more stable and reliable (They won’t drop work productivity if someone is sick or takes parental leave) but slower and less agile. Product development needs both. In most cases, small teams should include 3-5 people and large teams should comprise 6-10 people. Amazon’s famous “two pizza rule” stipulates 3-10 people in a team. Other organizations use their own rules. Basecamp limits teams to just 2-3 people. 

What should one of these teams look like? 

• TeamC, a small innovation team, is composed of 3 developers, and a product owner who is also a quality engineer. The team receives external support from a scrum master serving other teams with the same business function. Weekly meetings are held with a support consultant to track updates to customer needs and user perspective. 
• TeamZ is a maintenance team responsible for a major feature. TeamZ comprises a product owner, scrum master, 4 developers, quality assurance, and a third-line customer support agent, whose primary responsibility lies in customer support. This allows TeamZ to fully own maintenance of their module, directly receive tickets from customer problems, and connect to how customers are experiencing the module. 

There is no one best way to design a product development team. However, most organizations greatly benefit from cross-functional teams capable of owning features and modules, and capable of working on and achieving goals with minimal management and minimal dependencies on other teams. 

Building a team structure for your product development will likely involve trial and error, and likely, several different types of teams. The team must fit the module or feature, and that often means building teams in different sizes, with different goals, and completely different work methods. Vision to Value offers a high-level Agile framework, with everything you need to structure teams, implement scalable processes across teams and pipelines, and scale operations in SaaS organizations.