Product Team Topology as you Scale

This is the first piece and an early excerpt from a book I am working on that I plan to call “Product Snacks”. It will be a concise collection of chapters, each offering practical and accessible advice for product managers and designed to be a desk-side companion, providing quick, digestible tips to guide and inspire when you’re seeking clarity or a fresh perspective. I’d love ANY and ALL feedback and if you’d like to collab, let’s chat!

How to start thinking about organizing your teams.

Scaling product organizations is not easy. To be clear, when I say “product organizations” I mean the Product, Product Design, and Engineering teams — not just the product management team. I also want to be clear that my perspective here is about scaling businesses from the pre-seed/seed stage through to somewhere around 350–500 people and hundreds of millions in revenue.

A topic that I feel is often overlooked and usually only discussed long after you likely should have started making the changes in your org design is team topology. First, what the heck does “team topology” mean? To me, it means the way teams are constructed and how they are interrelated.

This is hard. You have to proactively prepare for these things because it takes a lot of time to find and acquire great talent. Time as a limiting factor is something to plan around because you can’t get it back, and it surely isn’t your friend when it comes to a scaling business. Quite frankly, you’re building the airplane while you’re flying it.

Stage 1: Ship something. Get to market.

At the onset of a company, during startup mode, most product orgs may only have a single team that covers as much surface area as they can to get an MVP or the first version of something up and out to market. This period is usually really fun and exciting. Things can move quickly because everyone is working on the same thing, well aligned, and know what direction to row the boat in. Things can change, and they do, rapidly… but communication is easier both within the team but more broadly with the rest of the company. The goal is to ship something to market and start getting your feedback loops rolling.

Stage 2: Support/Learn/Iterate

After the first version is in the market, things start getting a little harder. You now have to support and maintain what you shipped, bugs are surfacing that need to be squashed, people are actually using the product and you need to listen, observe, learn and work the learning into your planning.

Ideally you’ve shipped something that now impacts the business in a positive way and the Sales, Marketing, CX teams are all major stakeholders that have ideas and opinions (and are GREAT sources of feedback for your feedback cycles). So how do you start to think about the shape of your org to support, analyze, stabilize, and iterate on your product?

This is when topology starts to kick in and you need to think best about how to split the load to keep the optimal pace of iteration and improvements while supporting and maintaining the live product. You also need to start thinking about what the org might need to look like in future iterations so that you can start recruiting the right team.

At this stage it sometimes looks like splitting the team into two teams/pods/squads. This is the first of many hard team topology choices and there isn’t really a “right way”. It depends on what resources you have as a business, what your hiring cycles/budgets look like, how far out you had forecast your need for additional teammates, how quickly you can onboard them, and how you choose to collaborate with other departments, etc.

What I like to do at this stage is introduce a few more engineers and an Associate Product manager to the team rather than split the team up or start a second team. This allows the product manager who shipped product stay close to the strategy, research, and discovery while enabling the Associate to help them. Think of the Associate as additional scale or capacity to convert all of the feedback loops into the next iterations while the additional engineering capacity allows you to start sprint planning with more velocity to allocate to maintenance, infrastructure, and bug squashing. (Try a 70% new work, 20% maintenance & infrastructure, and 10% bugs mix and modify for your needs from there.) The additional longer term benefit of adding the APM into the mix is that they learn the product from the inside out while allowing the PM to build their leadership abilities to set you up for the next topology shift.

Stage 3: Backlog is stacking up fast and everyone needs something

At this point you are doing pretty well, but you start gathering so much feedback from customers and the rest of the organization that there is a seemingly endless backlog of things you can do. Prioritization and communication are starting to be of massive importance and take up a lot of time. Hopefully you saw this coming a bit and you’ve been out there trying to find new and talented teammates to join your product organization.

How do you start structuring the teams when you have:

• a mountain of product discovery to do (what should we build and why should we build it)
• a mountain of features and enhancements that you’ve decided you need to build (product development)
• a mountain of bugs, maintenance, or infrastructure work to do (maintenance & support)
• while the business is coming up with new and important demands from all of the other stakeholders that need access to the data your product is creating or tools to leverage that data to do their jobs (internal tools and systems integration)

At this point you start to need multiple teams and topology starts to change. There are a few ways you can think about it at this stage.

Organize by features

Oftentimes, there are core features of the product you’ve developed that are the bread and butter of the offering and need special attention and constant improvement. You can create teams centered around these core features. This is what I see happen more often than not, but I don’t believe this is an optimal approach because you start thinking about your product as a set of features rather than thinking about your product as a tool that generates outcomes for your customer and your business.

Organize by functional responsibility

You can also break your teams up into Product Discovery, Product Development, Product Support, and Internal Tools teams as a way to service different portions of the product life cycle which can work when you are a smallish team with really great communication. This helps people have distinct ownership over specific functions, but you will have competing priorities that need to be addressed and decided on.

Organize by customers

Customers can also mean your internal stakeholders (ex: your CX team can be one of your customers). This allows the teams to focus on the core user they are serving and focus on the outcomes they seek to create for them regardless of where in the product experience those outcomes need to be created. I like this type of topology when your product org is somewhere between 10–15 people because you can usually have one team focused on the businesses customers while the other team focuses on the internal teams needs and you can cover a lot of ground this way with a limited number of people.

Stage 4: Building and supporting multiple products

In success, your business will scale beyond the single product offering you originally brought to market. This often looks like multiple customer facing products and a few internal tools that you’ve built, coupled with some SaaS products you have integrated into your stack. Now your product organization is becoming responsible for creating value and supporting the business operations needed in order to do so.

While you can continue to scale the versions of topology addressed in stage 3 and be highly functional, I find that you start creating too many seams in the customers’ experience with your business and product. In some cases I feel like I can tell how teams are organized when I use products based on where I can see the seams in the user experience and sometimes even in the design when rolling from one feature to the next. I feel like cars tend to be the worst culprits of this. Imagine the team structure when you look at the exterior of a car and then you get in the driver’s seat, and they feel like two wildly different worlds. (that’s not you Audi!)

In this stage of your company you now have a product organization that’s somewhere north of 25–50 people. Your company at large is now in the hundreds of people. Ideally your revenue is somewhere north of $100M. That’s a lot of people to inspire, align, and coordinate. The way I have found it best at this stage is to start breaking the teams up based on the CUSTOMER LIFE CYCLE.

Try organizing by customer life cycle

This one sounds weird, I know. “You mean to say that we should put the customer at the center of our universe?!” (That was sarcasm). What I mean is to start thinking of the customer journey and life cycle in stages and then organize the team by those stages. This can be difficult and it’s no silver bullet, especially if you have many different customer segments (we can talk about a blended approach in a second). Think about the journey your customers take before, during, and after engaging with your product. The macro lens here can be something like: Awareness, Decision, Purchase, Engagement, Retention, Referral. Let’s look at how teams might align to these stages.

Awareness Team: This team is likely set up to enable your marketing and product marketing functions. They could own the mar-tech stack of tools used and the customer facing website and landing pages and enable the growth marketing efforts. Think of them as the top of the funnel.

Decision Team: This team could be tightly couple with your product marketing team and responsible for the funnel after the first click. Meaning after the customer has landed on a page and clicked through to consider making the decision to purchase or engage with your product. This team could also be tightly coupled with your sales, CX, or solution architects if your sales process requires that. Think of them as optimizing the middle of the funnel and enabling the teams that support this decision to buy moment, and their tooling.

Purchase Team: Depending on the size of your company and the complexity of your sales process, you could couple this up with the decision team, but in some cases like SaaS products that have a long sales cycle with many decision makers and a consultative sales approach, you might have special needs and teams here. This team could own things like your CRM, telephony, CX tools etc. as well as support the growth marketing folks with their mart-tech tools for retargeting, attribution, etc.

Engagement Teams: This is probably multiple teams focused on the suite of products that you customers have made the decision to purchase and use. This team of teams could still be broken out like the options in Stage 3 depending on what works best for your particular needs.

Retention Team: This team could be coupled with the engagement teams if it works for your org/product but I do think it’s fair to start questioning whether you should be building for new customer or building for your existing customer to increase their lifespan and the engagement teams sometimes focus too heavily on the new customers naturally. Retention teams can be focused on what’s working and how to optimize those things to increase the lifetime of these cohorts.

Referral Team: Honestly, I have never actually built a dedicated team for this portion of the journey. I would more than likely couple these efforts with engagement or retention, but it is a core component of the customer life cycle that those teams should be chartered to consider. When your customers bring you customers, your cost to acquire new customers drops significantly which obviously means your margins improve. The other thing teams often forget about with referred customers is that they are often higher quality (better LTV) customers. Don’t treat this stage as an after thought by just slapping on a SaaS tool and calling it a day. It needs focused effort to make that SaaS tool or your own custom approach sing and it’s very much worth the effort if you can get it right.

Well, that’s it for this one. We’ve now seen how our product organization can scale from a few people to somewhere around 75–100 and we’ve helped to make our company grow into hundreds of millions in revenue. It takes a lot of forecasting, planning, and changing as you reach new stages of growth, so be intentional about how you chart your course. Now let’s actually go and do it!

Key Takeaways

• Scaling Complexity: Scaling product organizations (including Product, Product Design, and Engineering teams) is challenging, especially for businesses growing from pre-seed/seed stage to around 350–500 employees and hundreds of millions in revenue.
• Importance of Team Topology: Understanding and planning the structure and interrelation of teams is crucial and often overlooked in organizational design.
• Proactive Preparation: Anticipating needs and recruiting talent takes time, crucial in a scaling business where you're "building the airplane while flying it."
• Organizational Models: Depending on the stage, teams can be organized by features, functional responsibilities, customer focus, or customer lifecycle stages.
• Intentional Planning and Forecasting: Continuous forecasting, planning, and adapting to growth stages are vital for successful scaling.A lightweight way to think about the stages of scaling:
• Stage 1 - Initial Launch: Focus on shipping an MVP or first product version with a single team working in alignment.
• Stage 2 - Support/Learn/Iterate: After launch, split the load between supporting the existing product and iterating on feedback, possibly dividing into two teams.
• Stage 3 - Managing Backlog and Diverse Needs: As feedback and backlog grow, prioritize communication and consider structuring teams based on feature development, functional responsibility, or customer focus.
• Stage 4 - Handling Multiple Products: When the company scales beyond a single product, consider organizing teams based on customer lifecycle stages (Awareness, Decision, Purchase, Engagement, Retention, Referral) to ensure a seamless user experience and address various customer segments.