I make no apologies for blogging again about Product Management because it is important and because, on the whole. As I said in my previous entry, Agile methods have a very simplistic view of determining what needs doing.
In the short run the Alignment Trap tells us that it is better to focus on doing things right, but in the long run Lean thinking tells us we have to do the right thing - remember 80% of features aren’t used. So Product Management is a long run play.
That is one of two reasons why Agile methods tend to underplay requirements and “Product Ownership” - because you get a lot of benefits by ignoring them to start with. The other is that Agile methods largely originated with developers who generally tend to underplay the role of requirements. (The exception to the rule may be EVO which is quite keen to understand exactly what people want.)
The trouble with Product Management is that everyone has a view on what needs doing, thus, in the absence of a Product Manager (or BA if your that type of company) other people will fill the void -
• Developers sometimes try and fill the void but developers have empathy with the code and find it hard to untangle their feelings about the code from what the customer wants.
• Architects claim to fill the void because they have the “bigger view” but architects are - almost by definition - uber-developers so have the same problem as developers. But architects are also tasked with looking at technology therefore any requirements they come up with are likely to be technology not market based.
• Project Managers often try and fill the void but their training and inclination is very different. They have a tendency to view things through the prism of dates rather than business value.
In the UK confusion between Project and Product management is rampant. It is slowly getting better but many companies can’t tell the two apart. This is really sad but also really dangerous.
Project Management can always expand to fill more time: you can always redraw a PERT chart, or level it again, you can always add another risk to the risk log (“An asteroid may hit Earth and delay the project”) or you can always go and ask a developer “Are we there yet?”
Product Management on the other hand can always be shrunk to squeeze in. After all we all have views on what the product should do so stick a finger in the air and guess. (And the more senior the person doing the guessing the more likely their guess will be taken as truth.) It takes time to visit customers, talk about their needs, time to go to trade shows, investigate competitors, time to calculate ROI and so on. Far quicker to stick a finger in the air.
My personal rule is: one Product Manager to every three to seven developers. If your product is stable, changing little and in a quiet market then one Product Manager may be enough for seven developers. But if you product is developing, the technology is innovative and the market changing fast you need one Product Manager for every three developers.
Its a false economy to skimp on Product Managers, you may save money but you may well create the wrong thing. Far better to go a little slower and create the right thing.
Given how much work a Product Manager has to do its natural to look for ways to split the role up. The first split is to hive off outbound marketing to Product Marketing. In a small company or team a Product Manager may do both inbound and outbound marketing but once it grows you should split the two roles.
Another division is between Tactical and Strategic, and with this split the role fits well with the Agile/Scrum idea of Product Owner. The Tactical Product Manager takes on the Product Owner role.
I hadn’t thought much about this until a friend of mine brought some blogs from Eigen Partners to my attention. These guys explain it well themselves so I’ll leave you to read Agile/Scrum Software Development and Product Management part 1, part 2, part 3 and part 4.
In the short run the Alignment Trap tells us that it is better to focus on doing things right, but in the long run Lean thinking tells us we have to do the right thing - remember 80% of features aren’t used. So Product Management is a long run play.
That is one of two reasons why Agile methods tend to underplay requirements and “Product Ownership” - because you get a lot of benefits by ignoring them to start with. The other is that Agile methods largely originated with developers who generally tend to underplay the role of requirements. (The exception to the rule may be EVO which is quite keen to understand exactly what people want.)
The trouble with Product Management is that everyone has a view on what needs doing, thus, in the absence of a Product Manager (or BA if your that type of company) other people will fill the void -
• Developers sometimes try and fill the void but developers have empathy with the code and find it hard to untangle their feelings about the code from what the customer wants.
• Architects claim to fill the void because they have the “bigger view” but architects are - almost by definition - uber-developers so have the same problem as developers. But architects are also tasked with looking at technology therefore any requirements they come up with are likely to be technology not market based.
• Project Managers often try and fill the void but their training and inclination is very different. They have a tendency to view things through the prism of dates rather than business value.
In the UK confusion between Project and Product management is rampant. It is slowly getting better but many companies can’t tell the two apart. This is really sad but also really dangerous.
Project Management can always expand to fill more time: you can always redraw a PERT chart, or level it again, you can always add another risk to the risk log (“An asteroid may hit Earth and delay the project”) or you can always go and ask a developer “Are we there yet?”
Product Management on the other hand can always be shrunk to squeeze in. After all we all have views on what the product should do so stick a finger in the air and guess. (And the more senior the person doing the guessing the more likely their guess will be taken as truth.) It takes time to visit customers, talk about their needs, time to go to trade shows, investigate competitors, time to calculate ROI and so on. Far quicker to stick a finger in the air.
My personal rule is: one Product Manager to every three to seven developers. If your product is stable, changing little and in a quiet market then one Product Manager may be enough for seven developers. But if you product is developing, the technology is innovative and the market changing fast you need one Product Manager for every three developers.
Its a false economy to skimp on Product Managers, you may save money but you may well create the wrong thing. Far better to go a little slower and create the right thing.
Given how much work a Product Manager has to do its natural to look for ways to split the role up. The first split is to hive off outbound marketing to Product Marketing. In a small company or team a Product Manager may do both inbound and outbound marketing but once it grows you should split the two roles.
Another division is between Tactical and Strategic, and with this split the role fits well with the Agile/Scrum idea of Product Owner. The Tactical Product Manager takes on the Product Owner role.
I hadn’t thought much about this until a friend of mine brought some blogs from Eigen Partners to my attention. These guys explain it well themselves so I’ll leave you to read Agile/Scrum Software Development and Product Management part 1, part 2, part 3 and part 4.
No comments:
Post a Comment
Note: only a member of this blog may post a comment.