Structuring a Product Management team (part 1)

wolfpack.jpgA lot of what gets discussed about Product Management usually focuses on the lone Product Manager: that never-say-die individual who is as comfortable speaking to technology-savvy individuals as he/she is speaking to those whose focus is the market and the bottom line.

But, in reality, when it comes to a larger technology company with a wider portfolio of complex products, a product management team really needs to be built to optimally manage the products. The question is, how to structure the team for best results?

There are many ways to structure teams. The first question that must be answered though, is what what will this team of people do? At this point, it’s important to revisit the role of product management in your company and what the primary goals are. The reality is that the PM team will have different priorities in different companies, depending on how the company is driven.

Seth Godin has a good blog entry listing various types of Drivers. And while not all apply to technology companies, there are a lot more than you’d think!

Now, what kind of company are you in? If your company is technology driven, then likely there is a very close association between engineering and product management, and the PM team members can be split along technology segments. e.g. one PM handles Web Services and interoperability. Another handles metadata and the data layer. Another handles server availability and scalability etc.

While there is nothing inherently wrong with a technology driven company, it can mean an inward technical focus for the PM team and not enough focus on customer and market problems.

If the company is sales driven, then the PM team needs to focus on the deal flow that is coming in and optimizing requirements to deliver on the commitments that have been made to customers. This is very different from a technology driven company. This is the ultimate outward focussed driver. The problem here is that, given the sales focus, it becomes hard for PMs to be proactive and forward thinking, particularly if customer expectations are that their needs will be addressed “in the next release.”

Assuming you know what drives your company and the focus of the PM team, the next question is how many product mangers do you need? I’ve written an article on this on entitled You can never have too many Product Managers. The article attempts to describe the problem many companies face where Product Management becomes a bottleneck to efficient deployment of Engineering resources. It ends with a simple discussion of how to rationalize a ratio between the number of people in the Engineering team, and the number in the Product Management team.

While far from perfect, the rough estimate of a 1:10 or 1:15 ratio of Product Managers to Engineering staff seems to apply. It could be as low as 1:5 in some companies or as high as 1:20 in others. Regardless of the ratio, one needs to look at the maturity of the engineering team, the complexity of the product, and the aggressiveness of the competition to ensure there is enough PM resource to deliver high quality requirements in a timely manner, and then see those requirements though the development process and out to the market.

My view on the team structure is that it should:

  • be defined around existing and emerging lines of business in the company
  • ensure the long term focus on the products under management
  • provide flexibility to the PMs so they can engage in new product and market research
  • be nimble enough to adapt to market changes or new strategic initiatives

As you can see, this is far from completely analytic. PM team structure should be aligned with and staffed to meet company business objectives. If a lot of R&D, Marketing and Sales budget is going to be spent on a certain product initiative, then clearly a proportionate amount of money needs to be invested in ensuring the product management team is properly staffed. Why? Because Product Management is an optimization function.

how to optimize a finite set of engineering resources to implement the optimal set of product features that best solve the diverse needs of the target audience

And given the large engineering, marketing and sales expenses required to create, promote and sell a product, why wouldn’t a company invest (and Product Management is truly an investment) to ensure that those other teams’ needs are optimized.

What’s your take on this topic? Have you built out a PM team? How did you structure the roles? Why?


Structuring a Product Management Team (part 2) 


4 responses to “Structuring a Product Management team (part 1)

  1. A few comments- first, I do think that how you organize your team speaks to as much the type of company you are in as the type of company you aspire to be. Don’t underestimate the importance of assembling a team to actively change a pure technical engineering company as you describe it to one more sales focused or vice versa to the benefit of the business. Sitting back and looking at where you company needs to mature to in the next 5 years is important, because PMs that own the roadmap are one of the few organizations outside of marketing that control where the business ultimately goes.

    As well, to build a PM team you have to look at people first because you can’t effectively fit square pegs into round holes. Product managers can have a very diverse set of skills and personalities- making them effective with those skills is often more important than bending them to a particular vision of how the org should look. My team has five PMs, three of whom are very senior and two of whom have been with the business more than 6 years. In some cases, we added people to the organization because they were world class and added immense and unique value, not because we said to ourselves that we needed to fill a particular skill set and went looking for an exact match. As well, it’s only with a new product or business that you effectively get to hire and choose who goes where- ideally you have low turnover so changes in staff don’t happen often.

    With my group, we are focused feature first- because the most important thing for us to do is make sure we have good, non-overlapping coverage of functional areas when working with engineering. Of course you have overlaps of interest, but at the end of the day a PM needs to be responsible for a feature area and the requirements in it and you never want PMs competing over what an engineering team should build.

    Within that context, the scope of roles and size of features has to be effectively balanced because we are also an organization that facilitates field interaction; from gathering requirements, to speaking at conferences, to assisting sales execution. Certain individuals stand out in this regard and what I try to do is give them more focus and goals in this area which naturally fit with their interest level in traveling and so on (while making sure everyone gets a minimum amount of customer time). I’ve also implemented one best practice which is to send team members to the same geography year after year, as that has strong benefits to the field and customers as reputations are built.

    There is another aspect of product management teams that involves your critical blocking and tackling when it comes to requirements, release planning, watching the sales pipeline, etc. This can be a different skill set than a hands on product innovator role with someone that enjoys detailed work less than trying innovative applications of technology. I’ve found that unless you have the blocking and tackling work you’ll never ship good software on time, but you need a mixture of creative types that have the freedom to go innovate without the same level of daily activities and interruptions.

    One way of looking at this in the context of your blog is some people are better at optimizing the engineering resources part of the equation, while another are best at determining the best set of product features to build in the first place.

    Final note- whatever your team responsibilities are, make sure you make them clearly accessible to the field- setup a wiki page with bios and responsibilities so they can find the right people and optimize out the problem of having a large organization.

  2. Pingback: Structuring a Product Management Team pt. 2 « On Product Management

  3. Pingback: Do Product Managers need Domain Knowledge? « On Product Management

  4. Out on twitter last week,

    @onpm How would you integrate your PMs?

    @onpm If the PM team is supposed to have
    more structure than a collection of
    peers, what would that structure be
    composed of?

    I’ve worked in companies with flat
    teams. One company had a PM for
    their API. I’ve seen PMs that
    operated with or without project
    managers. I’ve seen ads for junior
    PMs. I’ve seen PMs focus on the PO
    job. And, I’ve seen where the
    PO=PM was not the case. All
    together, there are hints towards

    @onpm Your article is dead on. But, at the
    beginning of this tweet thread,
    the matter was team beyond flat
    “just a collection of equals”…

    @onpm … That is not really addressed in
    your article. I do agree, however,
    I see organizing entire company into
    phase-specific divsions.

    Those divisions would not lead to
    a richer PM structure, because
    there would be no shared services,
    which such a structure would be.
    Any PM structure would arise
    inside those divisions.

    @onpm Phase specific divisions would serve
    specific market phases w/specific
    capabilities and offers.

    @onpm Hazard for a PM is not treat the
    next market phase prospects as
    being like their current customers.
    One product would need 3 PMs …

    @onpm … over its lifecycle, and if you do
    mass customization in late market,
    even more PMs. Product would
    transition from one PM to

    @onpm …Messy I realize, but necessary to
    overcome over extended linearity,
    and the averaging of functionality.

    I’m organizing the company around
    separate divisions, so we comprise
    a pipelined organization relative to
    commercializing a series of
    discontinuous innovations. Not
    something every company wants to

    @onpm The technical enthusiast PM is
    really doing technical evangelism,
    and eventually, “in the stack”
    licenses. Handles tech layer….

    @onpm This TE PM permanent throughout
    lifecycle of the technology.
    Products and services built on top
    of that technology would have
    shorter lifecycles.

    @onpm Moore’s phase specific markets
    actually involve changes in offer’s
    vector of differentiation. New
    customers unlike existing

    I would take Moore and restate it
    as a series of Poisson games
    (Morrison), which further
    partitions Moore’s market phases.

    @onpm Layered architectural constructs
    like product line-crossing
    UI layer (Adobe’s CS4) would end
    up with its own PM.

    The question of how to structure a product management department with product strategists, product managers, product owner, junior product managers, product planners, and possibly service managers, project managers, product marketing managers, and category managers remains to be seen.

    The full scope of such organizations would depend on the maturity of the organization, capital levels, cash flows, cost structure, staffing levels, and such. Not every organization would be structured in the same way.

    Fully engaging a global market would require at least one product manager for each such market. As it is, most U.S. companies cherry pick global markets via distributors selling goods that meet U.S. requirements, rather than local requirements. Relying on distributors requires less management overhead, but also precludes local market sensing.

    Another factor to consider in structuring a product management organization would be its interface with the customer management organization.