In a comment on my original post on Structuring a Product Management Team, Josh Lannin made some good points I want to respond to. First of all, thanks Josh for the comments. I also have a few other thoughts on the topic, so here goes.
[Josh] 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.
Agreed. The PM team can have a lot of impact in changing the company for the better, but in some cases, it can also be a long tough battle that in fact, may be unwinnable.
Some companies can succeed because of their technical strength, and in most of those cases, because of the vision of the founder. Sometimes this is a good thing, and sometimes this not. I know of one software company which is a leader in it’s field, it’s technology is well regarded, and it does in excess of $50,000,000 in revenue annually.
Everyone who knows anything about that company also knows that it is a technology driven company, the founder rules it with an iron fist, and there is very little anyone, Product Management or otherwise, could do to change it for the better.
While this is an extreme case, technology driven companies often suffer from “founderitis” — the inability of the founder(s) to let their puppy grow on its own. Changing this internally can be a huge struggle.
[Josh] 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.
Yes, when looking at any team, it always comes down to the people. And in an ideal world, we’d have the roles well defined and find the ideal people for those roles. That, unfortunately is rarely the case though. Product Management teams tend to be small, and so every person on the team can have a huge impact, or if they are subpar, create a big gap.
The roles need to be defined in a structured way, and then the people found to fill those roles. Of course, if you come across an exceptional candidate who can contribute significantly, you bring them on if at all possible. But again, that is usually the exception.
In creating a team, you want to ensure that the team can not only deliver on their objectives, but that the team can be resilient to change or disruption. If someone leaves, is the team structured in a way that a replacement can be easily hired to fill the gap? If not, then you have a problem that may be hard to address.
Structure the team so that roles and responsibilities are clear and that no one Product Manager has knowledge that is difficult to replace, should they leave.
[Josh]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.
This is probably the most common way I’ve seen for segmenting up a Product Management team. There is clearly a lot of value in doing this. If a particular PM has full “ownership” over a feature area, then they can focus on end-to-end functionality and entire lifecycle of that feature.
The downside is that not all product managers are capable of end-to-end management, particularly for complex products.
I once worked on a large enterprise product. Initially I was the sole PM for that product. After a while we hired other PMs to take on some of the load. Initially we were feature focussed. A couple of the product managers were weak in this regard. While quite capable in general, they didn’t have the interdisciplinary skills to oversee all the aspects (client, server, mid-tier, security, metadata interfaces etc.) of their feature areas.
The result was that someone who looked at the full product could detect the differences in various functional areas, and certainly integration points across those functional areas were not as strong as they should have been. While it has some advantages, the functional area focus does tend to create knowledge and development silos that can weaken the overall product.
[Josh]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.
Yup. Some people like details, others are best suited flying at about 30,000 feet. Again, IMHO, this goes back to the roles that are defined.
If I could get headcount to have a mix of PMs, some of whom are better at the details, while others are better at finding innovative applications to technology, I’d be happy. My experience has been that the PM teams don’t have that luxury. Making the case for it is certainly possible, assuming a receptive management team, but in my experience, it is a tough sell.
Product Management teams are typically woefully understaffed in software companies. That is part of the problem in building teams. Adding another PM is a tough sell. Adding another engineer or sales consultant or sales person is far easier sell. I wrote about this in Product Management Maturity.
For highly technical products, say targeted at Enterprise IT or datacenters for example, I like the model of having both Product Managers (PM) and Technical Product Managers (TPM) (sometimes called Solution Specialists, or Solution Architects) working together in the PM team.
The Product Manager is responsible for overall product direction, roadmap etc. The TPM (or other equivalent title) is responsible for supporting the PM work through some of the more detailed technical aspects of the product, or competing/complementary technologies etc. The combination of the two, makes for a strong team, but also makes it easier to hire for each. Finding one person who can do both roles very well can be difficult.
My original post was meant to cover some of the key questions that should be considered when trying to structure a PM team. Given that PM teams tend to be small, and the role of Product Managers is not uniformly set across companies, it’s hard to come up with a standard model for a PM team. Going forward, as the role of Product Management is better understood and the practice matures, more standard models for team structures will appear.
Saeed