Communication in cross-functional teams

Working in cross functional teams is the occupational hazard for product managers.

A typical product manager needs to work with 3 kinds of teams:

Engineering team - comprising of developers, testers and IT operations
Sales / Marketing team
Management team

The product manager needs to have different set of information - or rather information represented and expressed in different ways for the three different teams.

Engineering Team Focus:

Focus on what needs to be done.
Define clear milestones
Clearly communicate focus of the product and end user gain
Help take decisions to architect the product
Detail the product road-map from the engineering side

Sales/Marketing Team Focus:

Focus on what the product positioning needs to be
Map the competitive landscape and find out how we are different from our competitors
Clearly communicate the overall marketing / sales goals - with respect to details like channels, goal for the period
Detail out the communication plan with the end users and involve in every engineering milestone

Management Team Focus:

Focus on what the product brings on the table to the organization
Clearly communicate what is the product road-map is and what help we need from the organization
Layout the risks / opportunities along with the financials
Ask for help in getting help from other functions
Get a champion from the management team for internal / external positioning.

While this is not exhaustive, It is a sanity list for a product manager - things that we should never miss.

Comments

My Journey in Inquiry and Advocacy - An experience report

It is recently that I have consciously started practicing Inquiry. Let me explain. I am a consultant who constantly looks at the situation and comes up and implements the solution to progress from there. While I do that, I constantly use Inquiry as a means to progress - one of the key facilitation technique specifically in multiple stakeholder situations.

Principles for developing systems that are anti-fragile

I have been trying to make sense of what anti-fragility means and how do I use that in my day job. As a Business Principal, I tend to work with the abstract but orchestrate a program of work that needs details. This makes my job a little difficult in the terms of designing for more self-preserving systems that preserve the spirit of the abstracted strategy or vision. I came across an article from Daniel Russo on anti-fragility and his attempt at creating a manifesto similar to the manifesto for agile software development. For more reading on Daniel Russo, here is his profile: http://djrusso.github.io More reading from his paper here: https://www.sciencedirect.com/science/article/pii/S1877050916302290 This post is an attempt for me to understand what goes into developing a program that uses every opportunity to strengthen itself and achieve its objective - the vision. I liked the approach of principles for developing systems that are anti-fragile. It is a very valua

User Personas

User Personas are a very good tool for the product owners, business analysts or product managers to be able to co-create with designers. It is predominantly a product of the user research and should not be an amalgamation of demographic data. It is the best way for us to list all scenarios that a persona would take when they want to attain a goal. It is predominantly used to build empathy with user, focus the team and build consensus in a large diverse stakeholder group. The website I referred to is here: https://www.smashingmagazine.com/2014/08/a-closer-look-at-personas-part-1/

Life of a Business Principal in Consulting

Search This Blog