The Product Council Guide
How to establish an effective Product Council
What’s a Product Council?
Popularised by Marty Cagan in his book, Inspired, the Product Council is a forum which includes key business stakeholders. The purpose of the Product Council is to set the strategic direction of the product, allocate necessary resources and provide insights into how the product is performing.
Whilst its name may sound a little over-dramatic, the Product Council is a useful tool, particularly in larger product organisations, as it works as a mechanism to solve problems and make decisions.
The problems a Product Council solves
It may be that you don’t feel you need a Product Council in your organisation, and that’s fine; not all companies need a Product Council. Here’s some problems that a Product Council might solve, so if you do experience these, you might want to consider instating a Product Council:
- Priorities keep changing – you know when you’ve agreed some priorities for the quarter, you’ve scoped out the work and the team are halfway through the second sprint’s worth of work and a senior exec or a stakeholder has a new pet project that needs to be prioritised above the work that you’ve already started? That’s annoying. And a Product Council can help to reduce the frequency of these types of annoyances.
- The strategic direction of the product is unclear – what are we building and why? Who are we building it for? What problems is our product solving? In what way is our product different? A solid strategy will answer these questions. The Product Council acts as the forum where the strategy is agreed upon so that all key decision makers understand what decisions are being made about the direction of the product and why.
- Stakeholder expectations are unrealistic – bringing stakeholders together into 1 forum helps stakeholders understand that there are competing priorities and that the items on their wishlist are part of a larger set of priorities which need careful consideration and prioritisation. Physically being sat together in the same room makes it clear that not everybody is going to have everything they want and that compromise must happen.
How to run a Product Council
Every company is different and every company will have a different way of running its meetings – including a Product Council. However, there are some guiding principles which might be useful if you’re thinking about establishing a product council in your organisation.
- Select Council members wisely – Not everyone who has an opinion is a stakeholder. Sure, ideas can and do come from everywhere, and as a product manager you should be open to exploring ideas from all kinds of different people in your organisation. This doesn’t mean that everyone in your organisation is a decision maker, however. Your Product Council should comprise the people who actually make decisions in your organisation. Aim to keep your numbers low (below 10) to ensure the council is a place where discussion can be had without it descending into chaos. If attendee numbers get over 10, the council will descend into chaos.
- Meet regularly – the frequency of your Product Council meetings is dependent on the lifecycle of your business. In larger organisations a quarterly meeting should suffice, in smaller organisations you’ll probably want to meet more regularly, depending on where you’re at in your product lifecycle.
- Time limit the sessions – you’ll be covering a lot in the Product Council sessions which means you’ll need to pencil in a decent amount of time to get through all the things you want to cover. This doesn’t mean, however, that you need to pencil in an 8 hour meeting. Limit your sessions to a maximum of 45 minutes as this is the higher limit of the human attention span. 2 x 45 minute sessions should be more than enough to cover the most important aspects of your council.
- Pick a format that works – ideally, have all Product Council members sit in the same room. Close physical proximity will likely reduce conflict and help you to communicate your message clearly. If this isn’t possible, get everyone on a call but still book a room so that physical attendees in 1 location can still meet together. Get yourself a whiteboard so that if concepts need explaining you’re able to quickly doodle a diagram.
Before the meeting
1. Decide what you’d like to achieve
Before you get together with your stakeholders in your Product Council, be clear about what it is you’d like to achieve during your Product Council.
Maybe you know there’s a conflict between 2 stakeholders regarding what tools you should be using for reporting and you’d like to use this opportunity to make a final decision.
Maybe you know that it’s likely that some of your stakeholders will disagree with the priorities you’ve set out for the next 3 months but you’d like to convince them otherwise.
Or maybe you just know that 1 stakeholder is going to be difficult and disagree with everything because you know – as everyone else does – that they are an arsehole.
The important thing is to have prepared for at least some of this and to have clearly identified some of your desired outcomes, with the knowledge you have about your stakeholders. Be specific about what you’d to achieve in your Product Council.
2. Prepare your persuasion tactics
Your Product Council is an opportunity to persuade council members why you should or shouldn’t be building something or moving in a specific direction.
When preparing your materials for the session, use framing to clearly articulate your position in a persuasive way. Framing techniques can include the language you use, the diagrams you use to illustrate your point of view and data points which back up your suggestions.
Shouting emotionally-driven statements about why you must do something is sometimes, but not always an effective way of persuading people by itself. We like to think of humans as rational beings who respond best to facts and data but this isn’t true. We respond to emotions just as much as we respond to data, if not more. Framing your points of view using a combination of emotional language, data and visuals is usually more powerful than either emotion or data alone, but it does often depend on the stakeholder you’re trying to persuade.
For example, rather than just showing an NPS graph showing your NPS increasing or decreasing month on month, show the graph, along with a photograph of 1 customer and their personal story or reasons why they scored you in this way.
If you know your stakeholders well, you’ll know what persuades them on an individual level. Some stakeholders will be persuaded by graphs, charts and data, others will be persuaded more by an emotional story about a user who loves an idea. Use the appropriate tool, or a combination of tools, for the stakeholders you’re trying to influence in order to maximise the chance of getting the results you want.
3. Send around your agenda
On a basic practical level, send around the Product Council agenda a week before your council meeting. This gives your attendees a chance to review the agenda and come prepared with thoughts and feedback. In theory at least.
The Product Council Agenda
You’ve done the necessary prep, you’ve pinged around the agenda and you’re sat in the best meeting room you could find for your Product Council.
The first thing you’ll need to do is to establish some presence by setting the context of the council and establishing personal presence.
Techniques for establishing personal presence
You know how some people have ‘presence’ in a room? Some of this is down to physical presence. Have you noticed how some people often appear to be more dominant in meetings simply because they’re physically larger? One option for creating a strong physical presence is to walk into the room on a pair of stilts. Here are some other options:
- Voice frequency – a 2012 analysis of 120 financial spokespeople found that passion and voice quality were more important factors in determining the gravitas of an executive than the content actually being spoken. Varying your pitch and creating a soothing voice rather than a shrill are effective ways to create a sense of presence. If you’re unsure how you sound, record yourself on your phone (in private) and play it back to see how you sound. If you sound dull, try changing the pitch of your voice as you speak to make yourself sound more interesting.
- Body language and props – since you’re going to be interacting with execs, adopt powerful body poses and grab yourself a prop to use throughout the meeting if possible.
- Priming – before you begin your session (or indeed any important meeting), priming is a tactic that can be used to shift your emotional state. Make a list of the times where you felt particularly powerful in the past. You may recall a time where you gave an excellent presentation, impressed a colleague or simply felt good about yourself. Write these memories down and rehearse the scenes in your head. Rehearsing previous success in this way will shift your current emotional state to match your previous state and this is known as priming.
Once you’re feeling confident, set the context of the session by giving a brief overview of some of the things you’ll be covering in this Product Council session and the overall goal of the session.
Part 1 – The Product Review
Having set the context, it’s time to get into the meat of the session.
Strategy, OKRs and Metrics
Part 1 of the Product Council can be dedicated to communicating what’s been achieved so far. You can use this time to review your product goals and your strategy. If you’re using frameworks like OKRs, review the key results you’ve achieved so far and explain reasons for successes and failures. A traffic light system is often used to signal the health of each key result and the likelihood that you’ll achieve them.
For example, a KR due for the next quarter might be to achieve 5000 additional API customers. If you’re tracking at 2500 and there’s 2 months to go, you might mark this as green (on track). If it’s the end of the quarter and you’ve ended it with a KR of 2500 vs. a goal of 5000 this’ll be red with a final result of 2500.
If you’re not using the OKR framework, re-engage with some of the product and business goals you’re working towards and articulate how the product is helping move towards these goals. If you don’t have product goals, get some.
Aside from goals and OKRs, pick out some key metrics to review that are important for the stakeholders present. These might include lifetime value (LTV), monthly active users (MAU) or revenue per user (RPU). The metrics will clearly be different for your product, but the important point is to ensure the metrics you demo are relevant and interesting for the stakeholders present in the Product Council and for the overall business. Less relevant and more granular metrics can be left aside for other meetings if necessary. High level detail with tangible examples is best.
Demo 1 feature that matters most
Review the Product Roadmap together and talk through some of the challenges and successes since the previous Product Council. Demo specific 1 feature that’s been released since the previous Product Council and make it explicitly clear how this links back to your overall goals and strategy and how you’re measuring its impact on the business.
For example, if you’ve launched a refer a friend scheme, demo how this works and explain clearly why you built it in the first place: to increase the number of users who refer a friend and to reduce your CPA. Then explain whether or not this has impacted your CPA.
Don’t be afraid to highlight product failures as well as successes. The Product Council is a forum to communicate some of the reasons why a particular idea or feature set didn’t shift the metrics or create happy customers in the way you thought it might.
If you’re not sure where to start with your roadmap or what kind of roadmap template to use, take a look at some of our Product Roadmap Templates to find one that suits your needs.
Part 2 – Product Opportunities and Priorities
The second half of your Product Council can be focused on product opportunities and priorities. You’ll discuss the items you could be working on in the future but have not necessarily yet committed to working on (opportunities) and you’ll decide what items you will work on (priorities).
Exploring opportunities
Start by using your roadmap to articulate the product items, features and initiatives you have shortlisted. You may be using a roadmap template which includes a discovery track. If this is the case, you can report back on what’s been discovered during this phase, which will help you to decide whether to proceed with the items shortlisted for discovery.
Explain what opportunities and priorities you think should be prioritised and why, using customer insights, user feedback and data to give your propositions some credibility. Make it explicitly clear how your suggestions link back to the overall goals of the business.
It’s at this point that you’re likely get feedback from stakeholders. Since stakeholders are humans it’s likely that you’ll encounter disagreements which will ultimately need to be resolved. These may be disagreements between you and your stakeholders or indeed between stakeholders themselves.
How to deal with stakeholder disagreements
There is no 1 way to deal with disagreements, but there are some guidelines you can follow to help you move away from disagreements and closer to agreement:
- De-personalise; often stakeholders will see features and priorities as an extension of themselves. A reporting tool becomes ‘Customer Service Team’s Reporting Tool’ or even worse ‘John’s Reporting Tool’. Your role is to try to de-personalise feature requests and initiatives by talking about them in the wider context of the business and the goals of the business. Where possible, avoid naming items in personalised ways. Once an item becomes personal, telling a stakeholder it’s not likely to get prioritised is akin to telling them that their children are going to be taken away.
- Timebox emotion; everyone loves a good screaming match sometimes. And some companies (including Amazon) actively encourage slightly aggressive disagreements since there’s nothing worse than passive aggression. However, excessive emotion can mask the problem you’re trying to solve. 1 solution is to timebox it; if the shouting has been taking place for over a few minutes minutes, call a break and give it a few minutes and come back to it later.
- Identify the point of disagreement: often, emotions will mask what the real point of disagreement is. Once you know what the point of disagreement is, summarise it clearly – ideally on a whiteboard – and then work towards a solution. Working towards a solution may require further work, such as checking data, speaking to another department or team member, but the important point is to make sure you clearly identify the point of disagreement first. Once it’s identified you can work on ways to resolve it.
How to make decisions
If you’re struggling to decide between 2 competing priorities, use some of the more well known product development models to help you to decide which competing priority to choose. Examples of some of the most common models for making decisions include: Impact vs. Effort, Impact vs. Goals, Impact vs. Value Proposition and The Kano Model.
In his recent note to shareholders, Lord Jeff Bezos refers to 2 types of decisions:
- Type 1 decisions are not reversible, and you have to be very careful making them.
- Type 2 decisions are like walking through a door — if you don’t like the decision, you can always go back.
If the decision you’re making is a Type 1 decision, make sure you have all the necessary research and risks identified before you make the decision. If the decision is Type 2, it’s less important to have each of the risk and scenarios identified beforehand since you can easily backtrack.
- Type 1 example – pivoting the product from consumer ecommerce model to SaaS model
- Type 2 example – changing a button color on the homepage from blue to red
Reserve your Product Council for Type 1 decisions which are likely to need input and decisions from across the entire business.
Dealing with decision stalemate
The worst outcome of any meeting is to finish up, close your laptop, wait for people to leave and then turn to your colleague and say ‘so what did we decide?’. You’re clueless about what needs to happen next and your colleague was talking on Slack for most of the meeting so they also have no idea.
One of the most important purposes of a Product Council is to make decisions. If you’re not sure what decisions have been made in the Product Council, you’ve failed miserably. If you do know what decisions have been made, summarise them at the end of the council session. If you’re stuck in decision stalemate, with no clear way to make a decision, here are some techniques to getting towards a decision:
- Put together new options – if a decision is currently framed as a choice between A and B, come up with a series of new options that contains parts of A, bits of B and a little bit of an as yet undiscussed C. Be creative and don’t assume that the options available today are the only options that exist.
- Delay the decision until more information is gathered – it may be that you don’t have the full, clear picture on something in order to make an informed decision. If this is the case, be clear about what specifically is missing which prevents you from making the decision and defer the decision until this piece of information is in place.
- Escalate – often, decisions will ultimately get escalated until the HiPPO makes the final call. Your job is to ensure the highest paid people make decisions you agree with and the best way to do this is to ensure you’ve made your best case possible to influence the outcome using data, insights and persuasion.
If sizing of projects is required, T shirt sizes of projects is more appropriate in the Product Council setting than more granular, item-specific sizing such as fibonacci. If you’re unable to roughly size items on the fly, bring along a team member from engineering who can assist you.
Resourcing
If you’ve agreed on a set of priorities for the next quarter (or whatever timeframe is appropriate for your business), the Product Council will often discuss resourcing.
Some questions you might ask include:
- Does the product team have the resources necessary to deliver the work required?
- Are the teams split in the best ways to ensure we can deliver the features necessary?
- Are non-product teams resourced appropriately to deal with upcoming product releases?
If you’ve decided to push ahead with a new initiative, this may be a good opportunity to analyse what resources you have today and how best to use them for the new priorities. This may involve shuffling teams around based upon skillsets, hiring new staff or assessing whether existing members of staff are best placed for the future priorities.
A Product Council checklist
Here’s a list of things to check before and after your Product Council meeting:
- Do stakeholders know what we’re working on and why?
- Is everyone clear what the strategic direction of the product is?
- Is there broad agreement on what to work on next?
- Are there still unresolved issues that need to be resolved? Is it clear how these will be resolved?
- Do we have the resources necessary to build what we need?
Is a Product Council right for my company?
A Product Council isn’t necessarily right for every organisation and whether or not you use a Product Council will often depend on a number of different factors:
- Your business size / maturity – if your business is still in the early stages and you’ve yet to find product market fit, you may be better placed on focusing on finding product market fit before introducing a tool such as a Product Council. In smaller companies, it’s likely that you’ll be physically sat next to decision makers day to day which makes bringing
- Your level of conflict / clarity – if the leadership team at your business is clear and aligned on the product strategy, with conflict a rarity, you may not need a Product Council after all.
- Your decision making capabilities – Do you find that your company is stuck with indecision paralysis? If decision making is a slow, difficult process, you’ll likely benefit from establishing a Product Council. If decisions get made efficiently, you may be fine without one.
An alternative to Product Council
If you do come to the conclusion that a Product Council isn’t right for you, there are alternatives ways to get some of the benefits of a Product Council.
One way is to create a cross-functional stand up.
The cross functional standup is similar to your daily standup, except instead of it being a product team standup only, it’s a standup where key stakeholders from across business comes along and briefly tells the group 1 or 2 of their key priorities. Since you’re stood up, the meeting is unlikely to go on beyond 20 minutes and it’s an excellent way of getting the communicative benefits from Product Council in a less formal environment.
The cross functional standup helps your engineering team to understand the non-engineering work that is happening across the business in order to bring product initiatives to life and it highlights to the business stakeholders the complexity of the work involved from an engineering perspective. It’s not something you’ll do every day, but pencil 1 in on a monthly or fortnightly basis for 15-20 mins max and you’ll be sure to get some value out of it.
The Product Council isn’t the answer to all the challenges you face on a day to day basis in product management, but it will go some way to making life a lot easier. If you think you’d benefit from one, set up your first council and crack on with it. Just be sure to think twice about who gets an invite.
Podcast
Product Stacks Podcast by the Department of Product. A deep dive into the tools, frameworks and processes used by product managers from top companies.
Product launches, news and analysis delivered to your inbox. Weekly.
