Will the real Product Manager stand up


[Also published on Linkedin Oct 19, 2015 – https://www.linkedin.com/pulse/real-product-manager-please-stand-up-km-mukku]
In a recent article Michael Siliski does an excellent job to underline the properties of a Product Manager. He also accepts the ambiguity inherent in the Product Manager role, and identifies some fundamental (behavioural) characteristics required of the product manager in certain aspects of product development. I have no issues with the points raised in the article, except for the fact that the entire piece seems representative of too ideal a situation. If one is only considering Google, Apple, Twitter, Linkedin, Microsoft, etc., then fine, but as soon as you widen the net to include other industries in particular the IT service industry, then I am not sure the points made in the article stick. If one were to rewrite by considering the context within which the Product Manager works, the conclusions may be more jaundiced but accurate. This context being the IT service sector and certain legacy organisations.

Vision and Strategy

You are responsible for neither the vision nor the strategy, but you are responsible for the execution strategy of the product. In fact in some industries the chasm between the visionaries, strategists and the execution is visibly vast. This chasm is the outcome of both the organisation structure and the distribution of work. And, the more remote the Product Manager is from the design, code, and architecture the less he is in a position to claim ownership of anything other than appraisals and delivery. In fact with a proper development-operations set up, even the delivery responsibility is owned by the developer. What was to be a glorious career move turns in the end to be nothing but a redundant project manager role.

Execution and Impact

You should know what your developers are doing, and what they will be doing in the next 2 to 3 sprints. Of course, only if nothing changes in the meantime, but this is what you are hired for to keep the obstacles of the development path for the developers. Will your team members know what you are building? Depends, this is known as the communication chasm. If you are building a product for a client, who resides across the pond, then testing is confined to the integrity of the product only, and will never extend to the clients of your client. For this you will have to wait for the feedback (loop or otherwise). The scrum master may believe that some of this is his responsibility (assuming that you have catered for such a role), but the expected conflict with him may never happen, since by all accounts the scrum master role is being quietly laid to rest.

Communication and Visibility

Communication is one of those rarest of skills, but at the same time there is an over abundance need for it. The real question is, what are you going to communicate with your team? If you have distanced yourself from the design, code, etc., you have hardly anything to communicate. You are not one of the visionaries or the strategists, and in any case a pond maybe separating you from them. You have separated yourself from design,code, architecture, etc., and that means certain types of communication doors are closed. The only role that is left is to play is the part of a therapist trying to maintain your team members on the straight-and-narrow path to delivery. Visibility is guaranteed as long as you are colocated, in fact your visibility will increase with each appraisal of your team members. Communication is often misunderstood, it is not just about the ability to utter something, but more about the value of the content you are uttering to your audience. This is where the whole thing fails, since you have distanced yourself from the core aspects of product development, and your other content has to travel the organisational hierarchy before it gets to you.

Honesty and Culture

Every employee should strive for honesty in their transactions within the organisation. But, both honest and culture are directly correlated to the behavioural patterns of the top management, and if that is out-of-whack then you will be allowed only to be as honest as your organisational culture is corrupt.

Conclusion

Our love hierarchies ensures we create ever increasing levels, slowly removing functional responsibility from these roles only to replace them with spurious management functions. I believe that the role of the Product Manager is on its last leg. It would by far be better to expand the Product Architects functional responsibility, to include the functions of the Product Manager. For a physical product the role of the Product Manager has been carried out exceptionally well by the Product Designer, and similarly in some types of organisations the Product Architect is the correct role not the Product Manager. It is wrong to think that the management role that is good enough for a Google, Apple, or a Twitter, etc., can be imported wholesale to other organisations. Some organisations need teams where everyone roles up their sleeves, and preferably none who stand and gawk.

About KM Mukku

Kick-start, build and manage teams in product development (particularly in the financial domain), and enjoy all in adaptive case management, business process design and business process improvement. Currently holding the position of CTO at coMakeIT.
This entry was posted in agile methodologies, product development, product management, Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s