Product Council & Decision-Making Governance

A Product Council is not a weekly status meeting or a product review forum — it is an executive decision-making body that convenes specifically to make hard calls. Structure principles: Membership: the minimum quorum for legitimate product decisions. Typically: CPO or VP of Product (chair); CTO or VP of Engineering; CEO (for major strategic decisions); and function leaders who are materially affected by the decision (VP of CS, VP of Sales, or CFO as relevant to the specific agenda item). Limiting membership: every additional participant adds coordination cost and slows decision-making. The council membership should be as small as possible while including everyone whose buy-in is required for the decision to be effectively executed. Meeting cadence: quarterly for strategic roadmap alignment (annual plan → Q1/Q2/Q3 roadmap confirmation → Q4 annual planning kick-off); ad hoc for major unplanned decisions (platform architecture pivots, major customer commitments that affect the roadmap, significant competitor moves requiring product response). Not weekly — a council that meets weekly becomes a status meeting rather than a decision body. Decision authority: the council defines which decisions require council approval, which can be made by individual function leaders, and which are delegated to product teams. This decision rights map prevents both over-escalation (trivial decisions requiring council approval) and under-escalation (consequential decisions made unilaterally without the right input).

Meeting quality determines decision quality — a Product Council that arrives at decisions through unclear discussion, incomplete evidence, and no explicit accountability produces low-quality outcomes regardless of the seniority of participants. Pre-meeting preparation requirements: all council agenda items must include a one-page brief (problem statement, data evidence, options with tradeoffs, recommended decision, and the specific ask of the council) distributed 48 hours before the meeting. Council members who haven't read the brief may not receive briefing time in the meeting — the meeting is for discussion, not for information transfer. During-meeting practices: designate a meeting facilitator (Product Ops role) separate from the chair who manages time, ensures all voices are heard, and surfaces dissenting views that might otherwise be suppressed by hierarchy. Document decisions in real time — a designated note-taker records the decision made, the rationale, and the specific action items with owners and due dates. Every agenda item resolves to one of: Decision Made (clear outcome with owner), Decision Deferred (explicit reason, new date, additional information required), or No Decision Required (agenda item was informational — recategorize to avoid using council time). Post-meeting: decisions communicated within 24 hours to all affected teams — through the CPO or VP of Product's weekly written update. No one who will be affected by the decision should learn about it indirectly through the grapevine.

Product Council decisions that aren't documented become invisible — teams implement based on their recollection of what was decided, which diverges over time, producing the frustrating experience of re-litigating decisions that were supposedly made months ago. Decision register: Product Ops maintains a searchable decision register (in Notion, Confluence, or Coda) where every Product Council decision is logged with: the date, the decision made (one sentence), the rationale (3–5 bullets), the alternatives rejected and why, the decision owners, and the decision review date (if the decision was time-limited or conditional). This register is the canonical reference when anyone asks "didn't we already decide this?" or "why did we decide X?" — instead of relying on the memories of the individuals who were in the room. Decision review cadence: decisions older than 12 months are reviewed annually — are the circumstances that informed the original decision still accurate? Has the competitive landscape, customer feedback, or technical reality changed in a way that warrants revisiting? Decisions that are no longer accurate should be formally revised with the same rigor as the original decision, not quietly reversed without documentation. Architecture decision records (ADRs): the engineering equivalent of the Product Council decision register — technical architecture decisions are documented in the same format (decision, context, options considered, rationale, consequences) and stored in the engineering repository alongside the code they govern. A mature Product Ops function connects business decision documentation (product council records) to technical decision documentation (ADRs), creating a complete traceability map from business intent to technical implementation.