Pre-Meeting Problem Definition Matrix
Quick tool for leaders & teams to set a clear agenda before giving up valuable time in a meeting.
Guiding Check | 1. Do we know what type of meeting this is? | 2. Can we state the focus in one clear sentence? | 3. Is this a symptom or a root problem? | 4. Why does this matter now? | 5. Who owns the outcome? | 6. What must be prepared before the meeting? | 7. What does a good outcome look like? | Summary |
|---|---|---|---|---|---|---|---|---|
Update Meeting | Clarify: are we just sharing information? | "We are updating on X project so all functions stay aligned." | Not relevant. | To keep teams aligned + avoid duplication. | Each team member updates only on what they're responsible for. | Send updates in writing beforehand if possible. | Everyone leaves informed, with key actions logged. | |
Decision Meeting | Clarify: what decision must be made today? | "We must choose between A, B, C options for supplier." | Ensure decision relates to root issue, not noise. | To move forward without stalling projects. | Confirm: who makes the final call (CEO, ops lead, team vote)? | Circulate decision options + criteria. | Clear decision made + next steps assigned. | |
Review Meeting | Clarify: are we evaluating performance / outcomes? | "We are reviewing sales results vs. targets." | Note if results show symptoms of deeper issues. | To improve future performance & accountability. | Assign owners to follow-up actions from review. | Share performance data in advance. | Lessons learned + improvement actions agreed. | |
Problem-Solving / Innovation Meeting | Clarify: what problem are we here to solve? | Problem statement = gap between current & desired state.E.g. "Our packaging costs are rising 15% above budget." | Ask: "What's behind this?" Not sure? Run a 5-Whys meeting instead. | To prevent wasted effort / capture opportunity at right time. | Appoint a problem "sponsor" who will carry actions forward. | Share problem statement draft + background data for feedback before meeting. | Agreed problem statement + next experiment / test defined. |
/image
Stage | Purpose | How to Prepare | How to Run the Meeting | Outcome |
1. Define the starting problem | Establish a shared starting point. | Draft a symptom/problem statement (e.g. “Sales dropped by 10% last quarter”). Share with stakeholders in advance. | Write it clearly on a board/slide at the start. Ask, “Do we all agree this is the problem we’re investigating?” | A single agreed-upon symptom to explore. |
2. Gather stakeholder perspectives | Bring in different insights from across the business. | Ask each stakeholder to reflect: Why might this problem be happening? Encourage them to do quick research or bring data. | Use working alone together: everyone writes down their reasons individually (sticky notes, Miro, index cards). | A pool of initial “why” ideas. |
3. Apply the Five Whys | Dig past symptoms to possible root causes. | None beyond initial reflection. | For each idea, ask “Why?” up to five times. Capture answers visually in a simple tree or ladder format. | Potential root causes identified (not just surface symptoms). |
4. Align on most likely root cause(s) | Build team agreement. | — | Use dot-voting or another quick prioritisation method to highlight the most likely/impactful root causes. | Consensus on 1–2 priority root causes to test further. |
5. Identify knowledge gaps | Recognise what you don’t yet know. | — | If no clear agreement: decide what information is missing. Could be market data, process analysis, or customer feedback. | A short action list of “what to find out before we can be sure.” |
6. Close the loop | Ensure clarity on next steps. | — | Confirm: Who will own follow-up research/actions? When will we reconvene to finalise the root cause? | Clear next actions + an owner. |