Pixabay - Pexels - Boardgame pieces representing people organized with lines

What is the right structure and size of your product organization?

I have recently authored articles on how to prioritize tasks and determine roles and responsibilities for your product team. Another common query I encounter is, “How large should my product team be, and how should I organize it?”

Here is what I’ve learned: Firstly, the composition of your product team will vary depending on where you are in the product lifecycle. When I refer to the product lifecycle, I’m not talking about the software development process, but rather where your product stands in the market. Specifically, I’m addressing these stages: Introduction – a new product establishing a customer base; Growth – a product with proven market fit experiencing rapid expansion; Mature – a saturated market where the goal is to maintain or explore new markets; Decline – when the product loses competitiveness and begins losing customers.

Understanding your product’s lifecycle stage helps determine the necessary skills for your overall product team. Individuals who excel in launching products may not be as effective with established ones, and vice versa. Thus, it’s essential to hire a strong product leader or consultant to guide your team’s growth and adaptation throughout the product lifecycle. A good leader trains the team on navigating various product stages and equips them with the necessary skills for success in each phase. Inadequate investment in training often results in disruptive cycles of replacement.

For a new product, you’ll need an outward-facing product team, including Product Managers, Designers, User Researchers, Product Marketers, and Engineers, who spend significant time engaging with customers to test ideas and identify market needs. As you progress to growth and maturity stages, you’ll require more execution-focused teams adept at developing and releasing features efficiently.

You might wonder about the ideal team size. At minimum, each product or major feature should have a Product Manager and a Designer. While many PMs and Designers can handle user and market research, rapid prototyping, and user testing, this team size is best suited for early-stage products. As you enter the growth stage, dedicated User Researchers and Product Marketers become essential for achieving growth targets. Mature products will necessitate Analysts and User Experience Designers to explore new markets, strategies, and optimize the product for existing customers.

Now, let’s consider organizational design and reporting structures for these roles. Some organizations prefer a General Manager structure, where each product has a GM overseeing all resources and the full P&L. Others opt for a matrix structure, with separate departments for Design, Product, Marketing, Operations, and Engineering, reporting to the CEO or COO.

Personally, I find the General Manager approach less suitable for software products, as it often duplicates the CEO’s responsibilities and those of the Product Management team. Instead, I recommend a matrixed organizational structure, with a strong Product Manager handling most GM responsibilities, including ownership of the Product P&L.

In a matrixed organization, reporting structures will vary based on the strengths of senior leaders, with no single right answer for the best structure. I have seen just about every structure possible and most of the time the structure tends to evolve organically based upon the strengths and weaknesses of different team leaders and the Senior Leadership Team. In short, I don’t have a standard recommendation for the “best” structure here.

Lastly, I haven’t delved into the differences between Product Managers, Product Owners, Program Managers, or other nuanced roles related to the software development processes. I also have not delved into any arguments about Agile vs. Waterfall or the level of structure needed for either approach. Such discussions are typically targeted towards Product and Engineering leaders and I may address them in a separate article.

If you’re grappling with these issues in your company, feel free to reach out, and I’d be happy to offer observations on your approach. If you want further elaboration on any topic mentioned, don’t hesitate to contact me.