Product team structure: The ultimate guide
November 05, 2021
Think of the biggest tech success stories of the past 20 years. Google, Facebook, and Apple are all household names. Most of us know how they came about: Mark Zuckerberg in his dorm room, Larry Page and Sergey Brin at Stanford University, Steve Jobs and Steve Wozniak, college dropouts who started Apple in a garage.
One day, they found success and — boom! — they became the mega-companies they are today. A flash Silicon Valley campus staffed by armies of developers, bazillions in the bank, and countless users. But how did they scale so flawlessly?
The secret is… it didn’t happen overnight.
Want to know how some of the biggest companies in history grew so quickly, or hope to create your own startup? You need to understand their product team structure… And you need to learn how startups can adapt them for rapid scaling without losing sight of their goal. This is what we will cover in this article, so if you’d like to know more — read on!
Product roles explained: Product team structure
Product teams are made up of three roles: a Product Manager, a Product Owner, and a Business Analyst. Let’s unpack these roles a little more.
Product Manager in a product team structure
This is a generalist role. If you’re the one hiring, these people could be called ‘visionaries’ or ‘CEOs of small products.’ They own the company vision and communicate it consistently to everyone else. This way, they ensure all stakeholders and employees can see where they’re going and how they’ll get there. These folks need to understand both business strategy and technology tradeoffs. Although their job is to set strategic direction, PMs should also be hands-on enough that they can help out the rest of the team if needed.
Product Owner in a product team structure
This person owns the backlog of user stories that need to be built into a product iteration. They start by prioritizing which user stories go into an iteration (i.e., a sprint) and then prioritize daily tasks.
Business Analyst in a product team structure
This person is responsible for working closely with product teams. They ensure that the products they create meet business needs from a commercial perspective. The Business Analyst is also responsible for creating financial models which can help describe how different products or features might impact the overall business picture.
Even though different types of people play different roles in the product team structure, getting all these people to work together is what makes up your organization’s product culture. If you think of your company as a product itself — and the employees as customers and collaborators — you’ll find that it improves both employee morale and efficiency.
How to organize your scaling product team structure
It’s easy for Product Managers, Product Owners, and Business Analysts in small companies to gather and crank out products quickly. When only a few engineers are on the team, communication flows freely, and everyone shares ideas equally. It’s a fun environment where everyone can contribute their input. There aren’t too many opinions clouding up the focus of what needs to be done. But when it comes time to grow… product teams have an almost insurmountable challenge ahead of them: scaling their teams.
No matter what stage you’re at in your product journey, knowing how to effectively scale is a must. Here are a few tips to add to your own teams for optimal product development.
First, let’s take a look at the typical growth trajectory of a startup.
Stage 1: Early days
Right at the beginning, you typically have a founder and an idea. The founder has a lot of input as far as product development goes. Since there’s no official product yet, there isn’t really anyone else. As the team scales to one or two members, those initial personalities will determine which roles are necessary moving forward.
There’s typically a lot of research and getting to know user pain points during this stage. It’ll all go toward developing your first MVP.
The team takes shape…
You have a few dedicated individuals who put their heads down and move things forward. At this point, you probably don’t need to organize yourself into different roles because everyone is working toward the same goal.
Everyone is collaborating toward building an amazing product that people want. That said, it’s good to start instilling these concepts early on to ingrain them in your company culture. In fact, giving out titles like ‘Product Owner’ creates expectations for collaboration and planning.
For most products, that structure will continue to evolve as the product grows and more team members join.
Stage 2: Growing pains: Building your MVP > Scaling for success
Now that you have your first few users hooked, it’s time to really develop your product. There are larger business decisions like identifying monetization opportunities and building infrastructure to support your growth as you scale.
As you move into this stage, your current team structure will inform how fast or slow you can build out new features. Depending on the size of your company, it could be just a single person who needs to focus on both early-stage research and getting users excited about upcoming releases. However, suppose you’re growing quicker than expected. In that case, it’s possible that only one developer can’t keep up with everything being built for customers. All that, plus all the tasks needed to maintain an efficient development cycle.
An effective way of scaling is having separate product managers/owners/analysts work on different stages of development.
Product owner’s role…
There’s a common scaling challenge we’ve seen is when a company has one Product Owner and multiple business stakeholders (e.g., marketing, customer success, sales). It can be challenging for a single person to represent all of those opinions because each stakeholder group brings their own lens on what’s important for the product.
This can lead to building features that are helpful for one group at the expense of another group. Howver, this defeats the whole purpose of having stakeholder buy-in throughout the process! Instead, it’s best to have multiple Product Owners representing each key stakeholder group.
Another approach is to have one Product Owner and multiple Business Analysts. The benefits of this structure are that it’s simple, everyone knows who the responsible person is, and it enables all the related features to be built together. However, because there’s only one product owner, that person tends to get pulled in a million different directions. Which means they don’t have time to actually sit down and write user stories for everything.
The PM’s job…
What often works best at high-growth companies is what’s known as a ‘2+1’ structure. That’s two product managers and one business analyst. Every feature gets written by at least two people from those two teams — so there’s no duplication between them. That means one person is always accountable for the feature, and that it gets built more efficiently. It also means product managers get to focus on strategy while business analysts are able to help with tactical planning.
The Product Manager’s role is to establish collaborative relationships with everyone in their company by clearly communicating their entire product line’s vision, direction, and goals (including future plans!). They prioritize features according to what will best impact key metrics for each release. Meanwhile, the Business Analyst’s job is to organize ideas into specific requirements that can then be prioritized by the Product Manager. They work closely with teams throughout all stages of software development to help build better products through collaboration.
Stage 3: Making the big time
Maybe a company moves into the big league — think gleaming offices, filthy rich founders, millions of users. They can then either structure product teams to keep things as they are, or keep adapting for more expansion.
If you’re more interested in the latter option, you might want to look towards Amazon and its ‘two-pizza team structure‘ for inspiration.
The two-pizza team is a concept that Jeff Bezos created in order to encourage small teams. A product development team should never be larger than can be fed by two pizzas.
Keeping things simple with smaller teams helps companies build streamlined processes. This enables them to scale up their business more efficiently. Innovation is fast, autonomy is high, and oversight is low. Product teams can take ownership of their own work, and the business can move forward quickly without getting tied up in democracy.
Tip: If your product team can’t fit around one large table, you know it’s time to re-evaluate your process and make some changes — most likely including hiring more people or splitting the team into sub-teams. In this way, it’s not too dissimilar from the way of working in phase two: lots of smaller teams working independently of each other.
Four ways to organize product team structure scaling
Thinking of scaling up? Here are some options.
Organize around ‘jobs to be done.’
For this approach, the team focuses on the users’ needs rather than on ideating solutions.
The process starts by mapping all the steps it takes for a user to get their job done. Then, the team works together to determine which of these steps could be automated or simplified with technology.
For example, if you are considering creating an online ordering system that allows customers to order takeout directly from your mobile app, you would want to create a list of what needs to happen for this feature to work:
1st Step: Download our mobile app.
2nd Step: Login into the app and add my favorite store as a favorite store (optional).
3rd Step: Explore menu options and restaurants in my area.
4th Step: Browse restaurant specials and make a selection.
5th Step: Pay and finalize the order and have it ready for pick up at your restaurant.
Applying the steps
In this case, there are five steps to getting a customer from opening their app to having a completed order in hand. The next step is figuring out where automation could help.
In Step 1 — downloading the app — you might consider if it would be better to integrate the option of ordering directly into your company’s website. This way, customers would not have to download a second application just to take advantage of this feature. You could also use an API that allows other delivery companies to sign up and deliver food. It’s easier to do this through your platform instead of using a separate mobile app or site for those services.
Advantages of using the ‘jobs to be done’ methodology
– The customer is always at the center of your product thinking
– You can easily build on top of what works for customers and iterate while avoiding dead ends
– You gain a more holistic view of your product and company by looking at each step in the user journey from a customer’s perspective
Disadvantages of using the ‘jobs to be done’ methodology
– It takes time to get into customers’ heads (That’s why it’s important not to jump right into product design, but make sure everyone understands how each department views the customer)
– Even if everyone is thinking about the same person, they may still talk past one another because there are different perspectives involved in a given decision.
Organize around solutions
Product development is all about putting yourself in your user’s shoes.
Trying to understand your user isn’t just a one-time activity; it’s an ongoing process. The best way for different teams to do this is by organizing around solutions or problems, and assigning users to team members.
Advantages of organizing around solutions:
– Cross-functional teams can more efficiently solve problems
– It promotes ownership and accountability among team members
Disadvantages of organizing around solutions:
– if your user is more or less the same for all of your solutions, then you might as well, assign them to one person rather than splitting up different parts of their needs between multiple roles.
Organize around personas
This approach places the user personas at the center of everything. Team members are assigned to handle different parts of the user’s experience based on the specific needs of each persona.
Advantages of organizing around personas:
– It puts your team in your users’ shoes, making them more empathetic and providing a better understanding of what they need.
Disadvantages of organizing around personas:
– Since there is no one single structure that fits all startups, this may require some flexibility — not all roles will be compatible with every solution or problem you’re working on. This can lead to lack of focus and unclear ownership. When coupled with strict deadlines, it might even cause bad habits like skipping steps or fast-tracking processes, which can hurt further down the road.
Organize around customer segments
This approach sees product teams group customers according to specific demographics or attributes.
Advantages of organizing around customer segments:
- Cross-functional teams: Team members with different backgrounds work together. This can be very empowering and interesting for some people because it gives them the chance to try new things — it might even turn into a passion.
- Autonomy: Each segment can control its own destiny (finances, deadlines, projects, etc.) and the team will only get involved when necessary.
- Improved focus on customer needs: Since product owners are often more specialized in certain areas/segments of the product, they have better understanding of their customers’ true problems.
Disadvantages of organizing around customer segments:
- Customer segmentation can lead to a more fragmented team, with members working on different things simultaneously.
- It can also lead to a team with more of an external focus, rather than understanding the products’ internal dynamics.
- This approach isn’t very helpful when you’re working on an existing product with lots of customers because it’s impossible to find commonalities between them.
3 Tips for Working With Product Managers
1) Product managers are constantly brainstorming new opportunities for your company. Listen to their ideas and engage in a healthy dialogue about how those ideas can be used practically within your business.
2) Product managers need feedback from all teams involved throughout the software development process to ensure that they are meeting quality standards of user experience, usability, design, and functionality.
3) Product managers know their users better than anyone else. They constantly run surveys, focus groups, and tests with customers to develop a thorough understanding of what type of products will best serve their needs. Try participating in some product manager outreach programs or workshops that help you learn more about who your target customers are.
As with all things, there’s no one-size-fits-all solution. The goal isn’t to get things right straight away — it’s to learn what your users like, and how you best go about answering those needs.
You might find out your first (second, or third) product team structure doesn’t work — and that’s ok. Keep learning and iterating on your product team structure: don’t be afraid to make changes and find something which works better.
Whichever approach you take, working in harmony should be your main focus. Utilizing collaboration tools to keep your team in sync can make all the difference.
Product owners rely heavily on keeping the backlog updated and clearly defined, as does the rest of the team. Furthermore, having organized sprints will help you to plan far in advance at one go. This is something that product management platforms and product design tools like Cacoo are especially good for: they are designed to standardize, automate, track progress and ensure collaboration between all members of your product team — regardless of their role.