Product management VPs and directors are sometimes required to make decisions on team structures in order to improve efficiencies, team productivity and moral.

We have seen two models applied to the product management team structure: functional and skills based.

Functional model refers to a structure where for every distinct product you are likely to have a separate product manager (in large companies maybe several and in small, one product manager will look after a portfolio of similar products).

Skills based models are different – they distribute work based on the staff member’s suitability to accomplish a given task and over time they morph into permanent structures where high level of labour specialisation occurs.

In over 80% of the companies we see functional or product based role structure.

But on the minority of case we have seen also seen the skills based model being rolled in companies of different maturity – with mixed success I have to say.

That is not to say it would not work in your team – so let me explain more.

Idea of skills specialisation is a good one (and an old one mastered by Henry Ford and the manufacturing production line) – it will increase productivity where people are doing what they are good at.

However there are risk and as long as you are aware of those risk and manage them properly it can work really well.

The most obvious risk we have seen are:

• Domain expertise risk: by letting staff focus on skill (let’s pick finance for example) they will be really good at that. However now they must use their strong finance skills across multiple product domains (eg. video, internet, telephony). If their product domain skills are not high in all areas you run the risk of inconsistent results and output from this contributor. While skill set for specific role can be specialised, understanding of product markets, competitor etc cannot – will require each team member to develop deep domain experience across multiple product, market, technology and competitor domains – very challenging if the business works across multiple customer segments – need an effective/well resourced CI and other support groups. Success will improve potentially if each team is focused on a specific segment.

• KPI misalignment: traditionally your KPIs for staff would have been product centric eg. each product manager would have his own metrics to meet product revenue, meet growth targets, customer satisfactions etc… In your skills based model these KPIs will not longer work. You will need to develop a new set of KPIs which are related to the skill based activity being performed by each of the staff. For example for product development staff it will be about how quickly they get the product’s to market. That in itself is not a problem. The biggest challenge in this is KPI alignments – meaning how do you still maintain some of the overall product metrics such as margin, growth, market share (which in our opinion you must have) when each of such measured deliverables sits with a different person in the team. What we have found is that over time there can lots of finger pointing eg. ‘I developed a good product but your go-to-market launch plan was poor and it did not work’. In such cases it’s very hard to get to the actual issue. Our suggestion in this case is to have a mixed-KPI structure. For example at the top layer you would have some product centric KPIs which are shared with all teams while under  those you have a layer of skill/activity based KPIs. In terms of balance of the two it’s hard to say but staring with 50% on each side would probably work. Also you would need to ensure that all functional roles have the same KPI’s and are able to change prioritisation as market/business demands it in such a way that it does not result in conflicting behaviour. Eg Product Development team needs to ensure that they deliver new capability in a way that is consistent with the strategic objectives of the Portfolio and Go To market teams – tight alignment between the Managers of the Product Development and G2M/Portfolio teams therefore critical if it is to be a success.

• Poor team communication: I think this one is very clear – with changes in responsibilities it will be very important to increase the communication in the team. Most importantly in the beginning but also in the long run. So upon the change, do not assume previous communications rhythm – we suggest that some extra team meeting be set up, some more regular review and update sessions etc… this will assist in fine-tuning the transition. Also we strongly encourage open communications amongst the teams – ask questions, say what works what not, suggest improvement and changes…

I hope this is valuable.