Download - PCA13 Product Camp - Product Council
PRODUCT COUNCILDave Deitering & Lance Ellisor
For ProductCamp Austin
AUGUST 2014@LanceEllisor
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
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
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
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
What specifically happens in Product Council?
Standard agenda itemsRelease dashboard reviewCurrent program schedule reviewNew program approval
Less frequent agenda itemsPrioritization change decisionsProduct policy introduction or changeRoadmap approvalAllocation
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
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
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
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
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
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
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