4 ways to organize your scaling product teams

In my 20+ years in product, I’ve had the opportunity to observe many product organizations through different stages of growth. And while there’s no one-size-fits-all formula, there are some guiding principles that can help product leaders scale their organization and structure their teams.

In this post, I’d like to consider how product teams scale up over time, share the four main guiding principles I’ve observed, and weigh in on the pros and cons of each approach. 

Early stages: Before you have an official product manager

At the beginning of a product’s lifecycle, you typically have a founder who plays the role of a product manager. They understand the specific needs and problems of users, the market, and perhaps they have a competitive advantage like know-how or domain knowledge. 

In early-stage companies like this, there might not be a person whose job title is “product manager,” but someone definitely plays that role. They talk to potential customers. They research user needs and pain points. They work with designers and engineers to create the first version of a product. And they validate it through “deep user insights.” 

Once the first minimum viable product (MVP) is complete, they start to improve it based on user and customer feedback. And hopefully, it evolves from an MVP with early adopters to something more significant. If the MVP sees some initial success, this is the stage where companies begin to grow the engineering or product org.

Hiring the first product manager

As a company grows, they hire the first product manager — the person who is going to take over some product-related responsibilities from the founder. That’s typically on the delivery (and adoption) side initially. The founder is still the product visionary, owning the long-term product vision and strategy, and offloads delivery and execution to new product managers. These product managers oversee the detailed product roadmap, adoption measurement, and design outcomes — to name a few things. 

As the product and org grows, the company starts to need more product managers. And when a company begins to hire multiple product managers, there will be a few that are individual contributors and some that are more senior level. So we arrive at the big question: How do you organize your product team? Which principles do you use to guide the evolution of your product organization?

I have observed four main ways of setting up your product organization. I want to preface this section by saying that many of these are not black and white — choosing one principle doesn’t mean that you can’t consider the others. But, most organizations generally select one as their overarching principle.

4 ways to organize a scaling PM organization

Principle 1: Organize around jobs-to-be-done 

The jobs-to-be-done approach is the flip side of organizing around solutions. The team focuses on the users’ needs or problems rather than on ideating solutions. For jobs-to-be-done to be successful, the product team must have an intrinsic, intimate understanding of the users’ pain points surrounding the problem.

If we continue with the chair example, the product team will direct their attention toward the problem of a user needing to rest in a specific context. So, if they’re focusing on the need to rest in a work environment as the job-to-be-done, they might come up with solutions such as a chair, a fitness ball, or a hammock. 

Pros: Jobs-to-be-done helps product teams be more customer-centric because they’re focusing directly on the user. Teams are not beholden to a specific mental model of what a solution looks like and instead focus on what users need.

Cons: It may take a longer time to arrive at a solution when teams follow jobs-to-be-done. Or, if you have multiple teams that are working on different problems, they may all arrive at the same solution. However, this isn’t a major con because in these cases, the solution they arrive at will be better since it’s designed around multiple user needs.

Principle 2: Organize around solutions 

At its core, product management is about empathizing with customers and understanding their problems. You know that a user has a problem or needs to do something, and you solve that need with products or with specific product features. The principle of organizing around solutions means zeroing in on ways to solve the needs of users. 

Pros: This approach could be valid if you have a fairly mature product and the needs of your users are well understood. In this case, you’re mostly doing maintenance or adding continuous improvements to an existing solution that is well-aligned with the needs of the users. 

Cons: You have a limited ability to understand the problem space where you are applying your solution. Or, the solution itself could be a constraint, impeding you from solving user needs differently and more creatively. 

For example, let’s say a product team is organized around the solution of a chair. If the problem is well-defined and you know the chair is the right solution, you can focus your efforts on merely making improvements to the chair. But focusing too much on the solution might mean that you misunderstand the real problem. If it turns out that the problem is that people need a place to rest at home at night while they’re sleeping, a chair might not be the best solution. And by laser-focusing on the chair, you overlook other solutions that might better solve the problem (like a bed, futon, etc.). 

Principle 3: Organize around personas 

When a team is organized around personas, they focus on who they cater needs and subsequent solutions to. The persona is the lens through which the product team operates.

Pros: Organizing around personas allows for a focused understanding of a persona’s needs. This works well when an organization has a well-defined persona or a few personas that don’t differ too much.

Cons: Proposed solutions may be more narrow because the team is just focusing on that one persona. 

We here at productboard have a few personas such as product managers and product designers. If we only focused on the designer persona, we would be missing out on what product managers need to excel in their work. So, to make a persona-driven approach work, you must deeply understand all your personas and their needs.

Principle 4: Organize around customer segments 

When organized around customer segments, product teams group customers according to specific attributes like geographic location, demographics, job title, or other context-specific dimensions. 

Pros: Organizing around customer segments is valid if each has a different need and can be better served by a specific solution that meets those needs.

Cons: Product teams may end up duplicating work if teams arrive at the same solution because the needs of segments are not that different

This approach works well for a physical product and when the needs of segments are differentiated. For example, a toothbrush company might have one product team focus on toothbrushes for adults and another on toothbrushes for children. For children, toothbrush design likely involves making the product attractive and enjoyable so they can build a habit of brushing their teeth. For adults, toothbrush design may focus more on preventing dental problems so they can avoid going to the dentist. 

productboard’s guiding principle

Here at productboard, we’ve chosen jobs-to-be-done as our guiding principle because it makes the most sense for our company at this stage and size. We’ve defined three main jobs:

• Job 1: I as a maker want to systematically learn about the needs of my customers to formulate a product vision.
• Job 2: I as a maker want to prioritize problems to solve via focused objectives to create a clear product strategy.
• Job 3: I as a maker want to align everyone in the organization on what to build next to maximize transparency and seamless execution.

I mentioned at the beginning of this post that there’s no one-size-fits-all approach. And many of these principles are not mutually exclusive. You can consider segments or personas while also taking a jobs-to-be-done or solutions-focused approach. What matters most is choosing the overarching principle that will guide your product team’s work. It all comes down to your organization — what kind of people you have, what their capabilities and interests are, and how much they can shift gears and change the way they work. 

—

I’m curious to hear your thoughts. Do any of these guiding principles resonate with you? Do you follow one that I haven’t included here? Drop me a note in the comments or reach out to me on Twitter to let me know.

.     .     .

productboard is a product management system that enables teams to get the right products to market faster. Built on top of the Product Excellence framework, productboard serves as the dedicated system of record for product managers and aligns everyone on the right features to build next. Access a 15-day free trial of productboard today.

This post has been published on www.productschool.com communities.