Managing stakeholder expectations via Product Council

Published by

gopalshenoy

July 26, 2010

From time to time, when I talk to other software product managers about their biggest challenge, they often say that managing internal stakeholder expectations is their biggest challenge. Yes, of course. After all, product management is like herding cats. Sales goes and makes promises to customers without asking the product group, marketing wants their projects done first, your development team has their own pet projects, customer support wants customer’s burning issues fixed first, professional services want projects that will make them do implementations faster. And all of this needs to be done in a short time with limited engineering resources.

So is there a way to manage these expectations and make sure there is a clear product direction? I have been using Product Council meetings to successfully do this. Product council is a concept I picked up from Marty Cagan’s Inspired: How To Create Products Customers Love book. I strongly recommend this book to all product managers.

So what exactly is a product council meeting and how do you run it?

Product council is a meeting with the executive management (including the CEO) once a month to review the product strategy and the product roadmap and resolve any conflicting product priorities that are currently in play. You as the product manager or head of product management should run this. This way, everything is presented in an impartial way and the whole group is presented with the projects that the product and engineering team is currently working on and need to work on in the future. If there are conflicting priorities, you present the pros and cons of the priorities and ask for a resolution from the product council. Make sure that the stakeholders whose priorities are creating the conflict are in the meeting. Be clear that you want a resolution at the end of the meeting (not afterwards) because the product team needs to start working on the right project(s) based on the decision. Force a decision by the end of the meeting.

I often hold these meetings once a month for an hour. It is a standing meeting that is on every stakeholder’s calendar. The agenda is typically the following:

Review the product strategy
Update since the last product council (what have we done since then)
What are we currently working on?
What is ahead of us?
Review product roadmap
Presentation of any conflicting priorities
Final decision on prioritization

It is important that you as the product manager or as head of product management help the executive management see the conflicts and lead them through a prioritization exercise. Once a decision is reached, there should be consensus from all stakeholders because it is an educated decision made based on review of pros and cons of each priority and more importantly facts (instead of someone’s opinion or support for pet projects).

So are you done after product council? No. You have to make sure that you keep the product council abreast of progress being made on the new priorities. If the project hits a bottleneck because of some unforeseen technical or business related reason, you need to immediately raise it to the product council rather than waiting till the next meeting. Communication is key to managing stakeholder expectations. If you do this well, you should be able to effectively reduce your stress level as a product manager.

Thoughts? How are you as a software product manager managing stakeholder expectations?

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader or by subscribing by email via the text box in the column on the right.

6 responses to “Managing stakeholder expectations via Product Council”

HCG Levels in Early Pregnancy

October 9, 2011

HCG Levels in Early Pregnancy Thanks for writing this, it was very handy and helped me quite a bit…

Thanks for writing this, it was very handy and helped me quite a bit…

Reply
Prachi

August 29, 2010

Hi Gopal

I’m interested in knowing if and how an MBA education helps one get from a engineering degree and software delivery (in product delivery) work experience to a product manager. That is almost crossing over from the person taking product specs to execute, to a person who defines and handles portfolios. Does a MBA education help in a considerable way?

A post on this would be very useful.

Reply
Don Sedota

August 17, 2010

Great article Gopal. I’m a big proponent of Product Council meetings and have found them to be very effective (and great stress relievers as you mention). Per your third to last paragraph, from my experience it has been much more efficient to present the priorities that the product team has come up with (given the logic, market, data, etc.) and ask for objections to those priorities during the meeting as opposed to trying to go through a prioritization exercise with all attendees at the meeting. That way, your providing much more guidance and you’ll get through many more decisions in a short amount of time. I once made the mistake of going with the latter strategy and you end up with a lot of debate and not a lot of consensus at the end. I’m sure this varies from company to company as well.

Reply
Bill Cohn

August 4, 2010

I used a similar concept at my last company — we called it a “Product Cabinet”. It was a regular meeting of the functional group heads — generally director-level, but not VP-level — and it was intended both for communication of activities as well as joint strategic thinking. The key to making this work was for me (the PM) to engage all participants in the process so they were invested in the outcomes. It also made it easier to delegate tasks, as the cabinet members held responsibility for completing tasks assigned to their functional group. You could say this is just like any core team, but it was product not project-oriented.

Again, the key to its success was an openness to the conversation. While I would generally do a lot of the talking, I made conscious efforts to engage all members and to push them to contribute to the strategy, even for questions outside of their area of focus. As a result, most of the time we left the meeting energized, better informed, and more committed to our now-shared direction.

– Bill Cohn

Ipswitch, Inc.

Reply
Nitesh Gandhi

July 28, 2010

Very well written. HAving a product council and involving the management is a good approach. The trickle up effect is a nice and soft approach to get the message communicated.

Personally I also communicate at every opportunity available with the various teams whose team heads are involved in the Product council. This helps in building up the awareness and leads to a more result oriented meeting.

Keep writing.
Nitesh

Reply
Jim Holland

July 26, 2010

Gopal – great insights. I agree with the product councils. When led by product management and participated by the executive team, it keeps strategy, alignment and communications in sync. I have experienced several different approaches similar to those used by you.

My favorite is the “Trickle Up” effect. Starting at the product/product line level, their was a product advisory team that met regularly (more than monthly) and representation from development, sales, sales engineering, support, QA, etc was required to be there. Who mandated the attendance? The VP of Development had a big influence. The goal was to allow product management to “lead” the team and occasionally have VP-level stakeholders there to listen and afterwards provide input.

This “trickled up” to a Product Management and Marketing council where we reviewed product strategy and the roadmap that provided guidance to marketing and its execution.

The final phase was as you mentioned. We held quarterly product council-type meetings where the E-team was present and the Product Management leader conveyed an update. They were supported by all the stakeholders and it was an instant success that built stronger relationships, kept sales in check and supported the executive team with valuable information.

Reply