(This post was first made in LinkedIn)
Product manager, as we all know, is a cross-functional leader without any authority over other stakeholder teams– viz. Engineering, Sales, and Marketing et al – in an organization. However, product managers own the sole responsibility for the success- both tangible and intangible – of the product. This conflicting expectations demand a product manager to balance the product priorities and to acknowledge the anticipations from the stakeholder teams.
There are many approaches or organization based frameworks that are available to aid in prioritizing the product features. Few of the popular frameworks include Kano analysis, affinitization diagrams etc. With that, acknowledging the stakeholder teams is a very sensitive area that requires some special skill.
I have tried to cover some of the key points below that, I feel, are important for a product manager to manage the expectations of the cross-functional teams:
Communicate: As the word “stakeholder” suggests, each team owns a part of the product and it is important for them to understand the business problem that is being solved and also the business value the product is expected to deliver. MRDs and PRDs are expected to provide all necessary information for the respective teams. In reality, teams do not have bandwidth to spend time on reading over the complete documentation. Hence the product manager should schedule an elaborate kick-off meeting to explain the feature in detail and to answer any queries from the stakeholder teams. This is a session to get everyone on the same page, and to clear any doubts. Post this meeting, PRDs and MRDs can be treated as a reference documents. The communication channel initiated at this point should be open until the delivery of the product.
Listen: Though product managers are expected to cover all details about the features with the MRD and PRD, in reality there might be some valid points that are bound to be missed in these artifacts. Product manager should always keep his/her ears open for the questions or suggestions from the stakeholder teams, without any presumptions. Each of these queries might carry a value add to the product and the feature in question. A good product manager is someone who always gives due respect to the thoughts of the team members and treats their suggestions on merit.
Give and Take: Based on my experience, product delivery and implementation is not always a one way channel – especially with the Engineering teams. Teams would like to add some features that they feel are important. There should be constructive discussions around these suggestions and product manager should weigh these suggestions against the available backlog and the problem in hand. Mostly these suggestions might fall under R&D category, which might require building the feature with some hypothesis. Instead of shunning the idea down, product manager should try to give some bandwidth to build a PoC, at a small scale, with a satisfactory hypothesis. Doing this, the product manager is acknowledging the drive of the engineering team or other teams, and also validating the idea in the market. Instead of missing some new and disruptive ideas, with some narrow vision, this step will open doors for a new level of discussions that will help the product to address customer pain points.
Deliver: It is imperative for the product manager to respond to the requests from the teams on time, every time. From the initiation of the project, there is always some information exchange that happens among the stakeholder teams. Product manager gains credibility by delivering the necessary information – be it an email reply or an artifact – on time as promised to the respective teams. It gives assurance to the stakeholders and ameliorates the trust.
I am sure I might have missed some key points that are worth discussing here. Feel free to add comments so we can build a framework to help a product manager to be a better cross-functional leader.