OPA Meeting (Opportunity/Problem Assessment)

A PM-to-PM forum for debating and validating problem spaces before solutioning

Annie Pearl
Behind the scenes of Calendly's rapid growth

OPA Meeting (Opportunity/Problem Assessment)

"It's a meeting where basically PMs... really debate and discuss with each other and spar around either areas and problems that they want to go investigate or after they've gotten data back or research back from evaluating an opportunity, deciding whether we actually want to move forward and go try to develop a solution." - Annie Pearl

What It Is

The OPA (Opportunity/Problem Assessment) meeting is a recurring forum where product managers present problem spaces to their peers for structured debate and validation. Unlike typical product reviews (which often include leadership), OPA is intentionally a peer forum where PMs can think through ideas openly without judgment.

The meeting serves two purposes:

  1. Before discovery: Debate whether a problem is worth investigating
  2. After discovery: Decide whether to move forward with solutioning

By removing leadership from the room, PMs can be more candid, take more intellectual risks, and genuinely help each other strengthen their thinking.

How It Works

Meeting Structure:

Element Description
Attendees PMs only (leadership intentionally excluded)
Frequency Regular cadence (weekly or bi-weekly)
Format Presentations + open debate
Outcome Go/no-go on investigation or solutioning

Two Entry Points:

1. Pre-Discovery OPA

  • PM presents a potential problem space
  • Peers challenge assumptions and add perspective
  • Group discusses whether investigation is worthwhile
  • Output: Decision to pursue discovery (or not)

2. Post-Discovery OPA

  • PM presents research findings
  • Group evaluates evidence quality
  • Debate whether opportunity justifies solutioning
  • Output: Decision to move to solutioning (or not)

Key Design Principles:

  • No leadership - Removes performance pressure, enables candor
  • Peer-driven - PMs help PMs think better
  • Need-based - PMs bring items when they need input
  • Safe to fail - Testing ideas doesn't mean defending decisions

How to Apply It

  1. Establish the forum:

    • Schedule recurring time (even if some sessions are empty)
    • Make it PM-only by design, not accident
    • Explain the "no judgment" principle explicitly

  2. Create simple intake:

    • PMs sign up when they have something to present
    • No formal requirement—purely opt-in
    • Both "should we investigate?" and "should we proceed?" are valid

  3. Structure presentations loosely:

    • Problem statement and initial hypothesis
    • Evidence gathered (if post-discovery)
    • Key questions the PM is wrestling with

  4. Facilitate constructive debate:

    • Challenge assumptions, not people
    • Add perspective from adjacent work
    • Surface risks and considerations PM may have missed

  5. Protect the culture:

    • Leadership should NOT attend (even if they want to)
    • Treat it as a thinking tool, not a reporting mechanism
    • Celebrate PMs who change their minds based on discussion

When to Use It

  • When scaling a PM team beyond 3-4 people
  • When PMs are operating too independently without peer input
  • When product decisions feel siloed within squads
  • When you want to improve the quality of discovery work

Signs you might need OPA:

  • PMs don't know what other PMs are investigating
  • Discovery work varies widely in quality
  • PMs feel isolated in their decision-making
  • Good ideas die quietly without peer review

Source

  • Guest: Annie Pearl
  • Episode: "Behind the scenes of Calendly's rapid growth"
  • Key Discussion: (00:46:59) - Describing the OPA meeting format
  • YouTube: Watch on YouTube

Related Frameworks

Back to Execution