TBM 1/52: Product Manage Your Meetings

This a short post to kick off the year. I’ll get warmed up again. I’m enjoying having no job to go to for the next three weeks.

I’ve gotten emails to re-share this mini book (~40 pages). Here it is:

How to think about Bets, Success Metrics, and Roadmapping

You might also be interested in these class notes (~15 pages) I wrote covering concepts like inputs and outputs, proxies, vanity metrics, leading and lagging indicators, and standard vs. bespoke models.

Measurement/Metrics Foundations

---

On to the post…

The typical company invests tons of energy (and money) in designing and delivering their "product"—the product they sell to the world. 

But most companies treat meetings as an afterthought. If the meeting were a product, no one would buy or renew. There's no product-market fit, and it doesn't solve a problem. People show up at meetings, get no value, complain about the meetings, and treat the whole thing like an intractable Gordian knot.

The idea of designing meetings is not new but is often overlooked. People—managers especially—are just expected to know how to do it. But what if meetings were product features owned by product managers and designers? How would they approach meetings differently? The first thing they'd do is realize that meetings are a How and not a Why. A meeting involves two or more people interacting synchronously and investing their time and energy to achieve mutually beneficial outcomes. You could call it a session, interaction, or collaboration—multi-player mode engaged.

Like any product, we should consider the desired outcome. I sat down with a team today, and we quickly brainstormed some intended outcomes for various meetings. I started with the question:

Think about [specific meeting]. What would we observe if this meeting was working as designed? What would increase? What would we notice happening more or less often?

Here are some examples from a cross-section of meetings.

Increase:

• The probability that we raise red flags before committing to an effort (when they are easier to address). Why? Beat sunk-cost bias, and rework.

• The probability that team members resolve issues at the optimal time—not too early, before they need to, but also not too late (when it is more costly). Why? Lower risk, improve upside.

• Our understanding of customer pain-points. Why? So that we can address them gracefully and effectively, with minimal extra complexity.

• The level of buy-in and commitment to address critical areas of improvement in the next couple of weeks. Why? Fewer false starts and middling efforts.

• Awareness of any critical, time-sensitive information.

• Flow and bring work-in-progress levels down to a manageable level. Why? More finishing, less starting. Why? Sanity!

• The breadth and depth of the options we consider when brainstorming. Why? Less confirmation bias and better choices!

• The likelihood that team members will borrow promising ideas from other teams instead of feeling like they need to roll their own solution. Why? Re-use saves time and energy. 

• Awareness of important strategic context. Why? To improve overall decision quality without concurrently adding dependencies.

• Increase confidence in the leadership team regarding improvement efforts triggered by the engagement survey. Why? Trust, retention, and commitment. Lead by example, and show we care and listen.

Even though these meetings had agendas and "goals", no one had documented the intended outcomes and design decisions. The agendas were lists of activities, and meeting goals covered the desired "output", not the eventual outcomes.

• Standup goal: "review blockers!" 

• Product review: "to review stuff!" 

• All-hands: "to get together as a community!"

The essential questions were left unanswered. Why? Why now? Towards what outcome? For who? What will we observe if this meeting is working? What will we observe if this ISN'T working? How else might we achieve these outcomes? The team hesitated to criticize the meetings because the outcomes needed to be more explicit and transparent.

Then we jumped into describing the “motion” of the meetings. Did the design of the meeting match the meeting motion? For example, if the goal was to generate ideas, were they creating an environment conducive to generating ideas? Or were they catching people at the end of a long day, swamped with work—offering an idea or two to just make it stop?

By clarifying objectives and motions, people felt more confident that could at least TRY to improve the meetings and felt more empowered to call out meetings that weren't doing their job. There was already talk of combining, redesigning, and killing specific meetings.

Action Item

Do an inventory and outcome catalog similar to the above activity. 

Assign each meeting a "product manager". Yeah, yeah, I know people OWN meetings. But how often do they OWN they outcomes vs. OWNING the invite?

The meeting PM’s job is to develop a clear understanding of the desired meeting outcomes and then maximize the probability that the "good" outcomes will happen and damaging effects will not. It is their job to make the interaction worth everyone's time. 

In many cases, a meeting isn't the best tool for the job. Like any good product manager, they shouldn't assume the meeting is necessary. There may be far more effective ways to achieve the desired outcomes. It's a feature, and features do a job.

The meeting PM may need the help of a good meeting designer. Good meeting designers have experience in facilitation, decision-making, group dynamics and psychology (including power dynamics), creating "safe" spaces, conflict resolution, etc. In many cases, the worst person to design the meeting is someone with a strong perspective and singular need. A good meeting designer can counteract that.

Regularly (and objectively) review your feature-meetings; if the desired outcomes are lacking, redesign the meeting or kill it.