1. PRODUCT COUNCIL
Dave Deitering & Lance Ellisor
For ProductCamp Austin
AUGUST 2014@LanceEllisor

3. What is Product Council?
Executive guidance committee for Product Management
–Fully empowered to make financially-impacting decisions
–Product Management does the research, makes evidence-
backed recommendations, and PC approves and advises
Cross-functional involvement in critical company decisions
A forum for setting common, company-wide expectations on
product priorities, status, and outlook
3

4. Why have a Product Council?
Where are we on
the update to the
ABC product?
Why is the 2.0
release behind
schedule?
We should build a
Confabulator for
our market
Our clients are
screaming for the
Flux Capacitor
feature. How do we
get it done faster?
Will version 3.3 run
on Firefox? or
Do we support IE6?
4

5. Who makes up Product Council?
Product Management, as leader/facilitator
Leadership team
–Voting rights
–A fully empowered individual from each key department,
typically: Dev/QA, Marketing, Sales, Support, Ops, Services
Non-voting attendees / interested parties
–SMEs, key account reps or project managers, etc.
5
Key lessons learned
• Product Council must be a decision-making body, fully
empowered to make big decisions; realistically, this
usually means the CEO or GM needs to be there
• Keep it small ; establish participation criteria upfront and
stand firm

6. How often is it held?
Depends on several factors
–Velocity of your market
–Expectation of capital
–How much you’re trying to manage
Biweekly or monthly are often best candidates
6
Key lessons learned
 Cadence must strike a balance between need for quick
decision-making and ensuring critical stakeholders attend
 Minimize reschedules; let the importance of the decisions
drive attendance

7. What specifically happens in Product Council?
Standard agenda items
Release dashboard review
Current program schedule review
New program approval
Less frequent agenda items
Prioritization change decisions
Product policy introduction or change
Roadmap approval
Allocation
7
Key lessons learned
 Follow a regular agenda for predictability and efficiency
 Anything really big or controversial should probably have
a dedicated “Ad Hoc" meeting

8. Release dashboard review
Review of the current status of
scheduled releases, with key
progress indicators by program
Clear visibility into the status of
releases, key risks and blockers,
and responsible people/teams
Should ensure 100% clarity across
the company regarding the next
release(s): the progress status, the
expected release date(s), key risks,
and the confidence level
8
What it is What it looks like
Key lessons learned
 Spend time upfront to understand
what key progress indicators are both
meaningful and practical to track
 It’s a dashboard: keep it as simple as
possible

9. A visual capture of the product
development work, both current and
scheduled
A reminder of where the approved
programs fall in the schedule
Based on the most recent approved
product roadmap
Should ensure 100% clarity across the
company as to what is scheduled to be
delivered
9
Current program schedule review
Key lessons learned
 Review this every time to remind all
that any changes or additions have a
cost
 Caveat all dates
What it is What it looks like

10. Presentation of business
case (or other decision
vehicle) for stage-gate
approval of a program
Ensures all new programs
are rigorously vetted –
qualitatively and quantitatively
– and inclusively approved or
rejected
10
New program approval
Key lessons learned
 Ensure no surprises; all key
parameters should be vetted by
the SMEs and key leaders in
advance
 Members should review material
and prepare questions/remarks in
advance of the meeting
What it is What it looks like

11. Proposal of – and decision
on – a change to current
schedule by changing
priorities
Release dates and/or scope
changes as a result
Confers some level of
corporate agility to change
priorities, while enforcing
notion of finite resources/time
11
Prioritization change decisions
Key lessons learned
 Limit scenarios to 2 or 3
 Ensure all scenarios are vetted in
advance by the resources who will
do the work
 Ensure the right resources are in
the meeting to respond to
questions
OR
What it is What it looks like

12. Product policy – change to, or
addition of, a product-related policy,
e.g. product support lifecycle,
supported platforms, backporting of
new features, etc.
Roadmap approval – formal
annual roadmap gates
Allocations – agreeing on product
work categories and allocation of
resources thereto to improve
prioritization
Ad hoc meetings – acquisitions,
partnerships, EOLing a product,
entering a new market, change of
scope or timing of a major release
12
Other occasional Product Council topics
Key lessons learned
 Remember the PC meeting is
for decisions and quick
updates only
 Education takes too much time
What they are What they look like

13. Practical & logistical lessons learned
Prepare, prepare, prepare
–Send out review material a few days in advance, but
–Present minimum in meeting (e.g. summary w/backing slides)
Clearly distinguish updates from decisions
–and ensure they know what they're deciding
Be careful with agenda
–Keep it light
–Order agenda in urgency order
Maintain focus on facts and figures over opinions and suppositions
–yet keep it simple and brief
Consistently follow up with meeting summary
–circulate & publish meeting notes, emphasizing decisions made and
action items
13

14. 14
Dave Deitering deitering@gmail.com
Lance Ellisor lance@ellisor.net @LanceEllisor