How much damage can a product manager unwittingly do to his team? The damage can be very large and its affect on the performance of the team could be fatal. The damage that is done through actions whose consequences are not visible is more lasting. If you are a product manager, see how many of the following points apply to you:
- Do you feel the urge to provide sequence diagrams, class models, and other design artifacts to your team as part of sharing the use cases with them? The only time you would do this is if your team lacks experienced designers/architects, and you are forced to play these roles. This is a bad way to start a product development, get a funder behind you and hire the right talent. As a product manager you are an enabler, and if you have the talent in the team then let them do their job. If you are that afraid they will fail, reduce the sprint cycle to catch errors early.
- Are you the type of product manager who stays up in the wee hours to trawl through the code your team has checked-in? Are you looking to fix bugs? Are you looking to fix perceived style errors, or pattern misuses? It really doesn’t matter, unless you are running short of time to release (why?), or you have a gun to your head by the funders, this really is the worst kind of time-waste by a product manager.
Any action that denies responsibility from team members, and only allows blame to be apportioned to them, destroys their morale. They will have no buy-in to the product or any artifacts foisted on them, and it denies them the opportunity to grow as developers/designers etc. Instead of instilling deep commitment what you have unwittingly created is a 9-to-5 mindset. Instead of a team of creative, collaborating team of individuals, you end-up with a team full of government employees. A case in question is an example of a product owner that provided a data model (entity relationship diagram plus the usual) as part of the knowledge transfer. On the surface this could be seen as a harmless gesture to speed the process of delivery, but,
- in this case, the data model forced blinkers on the team, thus denying them the opportunity to investigate many newer data structures that have been introduced since the advent the relational model. It is not being suggested that the data model is incorrect or that relational is wrong, but that the team has no opportunity to learn, it is not possible to investigate others models, such as, NOSQL, etc.
- worse, it forces them to only look for (UI and code) frameworks that are compatible with the data model. If they step outside this restriction they will have to bend and break some frameworks to fit the data model.
- if some processes are not optimal with the data model, you will have to write boiler plate code to handle the conversion.
Do not hire designers, architects, and domain experts if you want to do everything by yourself; you will be doing a great disservice to the hires. The more knowledge the product manager possesses the better, but this is not a license to impede the teams learning process. A product manager must set certain boundaries around him, and not continually step into the boundaries of the team members. It is difficult at times to know where the lines must be drawn. Perhaps the trick is to create feedback loops that will allow both the product manager and the team members to react quickly when things begin to go in the wrong direction. A stand-up meeting is only part of the answer, having the correct tools to provide the communication links for collaboration is the other.
A product manager must create a context within which team members are made to feel they belong, that they have an individual and collective identity in the team, and that they have a positive impact in the development of the whole team. It is these positive feedbacks that will ensure their contribution to the success of the product.
The product manager has many other responsibilities, aggregating the user feedback into the product, liaising with the funders, and playing a lead in marketing and branding of the product. He will fail if sequence diagrams and data models distract his focus. These concerns should be peripheral, and delegated to the appropriate team member.