How I Killed Meetings with a Question and an AI

From "why do people even have meetings" to a 30-page corporate proposal. One session.

← All posts

This is a tutorial. Not what the system is — the case study covers that. This is how it got built. The process. The sequence of thoughts between a human and an AI that turned a complaint into a deliverable.

If you're learning YOU++, this is the pattern you should steal.

Step zero: The complaint

I was sitting in a meeting. Forty people. One person talking. Thirty-nine pretending to listen. I had this thought — the same thought every person in every organization has had since the invention of the conference room:

Why do we even have meetings?

That's not a rhetorical question. That's a decomposition prompt. Most people let it pass. I opened a terminal.

Step one: Ask the right question

I didn't type "how do I fix meetings." That's the wrong question. That assumes meetings are the right unit and they just need tuning. A shorter meeting is still a meeting. A meeting with a better agenda is still a room full of people optimizing for whoever talks the most.

I typed something like this:

What functions do meetings actually serve in an organization?
Not the stated purpose. The actual functions.
Reduce to the smallest set that covers everything.

That's it. One prompt. But look at what it contains:

• "Functions" — not "benefits," not "goals." Functions. I'm asking for the mechanical purpose. What does a meeting do?
• "Actual" — not the calendar invite description. The real reason people are in the room.
• "Smallest set" — I want the irreducible decomposition. No overlap. No redundancy. If two functions can merge, merge them.

Claude came back with a list. Some of it was right, some of it was corporate filler. I cut the filler. Pushed back on overlaps. We went back and forth. Three minutes. Four functions survived:

1. Status visibility — what happened, what's blocked, what's coming
2. Problem-solving — we have a problem, we need ideas
3. Decision-making — we have options, we need to pick one
4. Human connection — people need to see each other and build trust

That's the whole decomposition. Four functions. Everything a meeting has ever been for fits into one of these four boxes. If you disagree, try to find a fifth. You won't.

This is the YOU++ move. I didn't ask the AI to solve the meeting problem. I used the AI as a sparring partner to help me decompose the meeting problem. The decomposition is the hard part. The decomposition is where judgment lives.

Step two: One pattern per function

Now I had four functions. Each one needed a replacement — something that serves the same purpose but doesn't require forty people in a room pretending to listen.

I already had opinions. This is important. I didn't ask Claude "what should replace status meetings?" That would give me generic best-practices content. I told Claude what I wanted and asked it to formalize:

Status: async daily check-in. Five questions. AI synthesizes overnight.
Brainstorming: blind parallel input. Nobody sees anyone else's answer.
  Mandatory field: "why this might fail."
Decisions: written rounds. Named votes. Dissent preserved on record.
Human time: no AI. No agenda. Protected time. Non-negotiable.

That's the entire creative input. Four lines of English. The ideas — blind parallel input, mandatory failure analysis, named votes, preserved dissent — those are mine. They came from twenty years of watching meetings fail and knowing exactly why.

Claude didn't invent any of that. Claude couldn't. Claude has never sat in a meeting where the loud guy won and the quiet expert stayed silent and the wrong decision got made because nobody wanted to disagree on the record. I have. That's where the patterns come from.

Step three: Say "build it"

Now I said something like:

Turn this into a corporate proposal. Professional format.
Questionnaires for each pattern. Flow diagrams showing the pipeline.
Redefine the TPM role — they operate the system, not schedule rooms.
Give me a phased adoption plan. Make it real enough to hand to leadership.

And Claude built a 30-page document. Questionnaires with specific fields. A pipeline diagram showing how Pulse feeds into Forge feeds into Senate. A table redefining the TPM role function by function. A five-phase adoption timeline with parallel-run periods. Impact assessment. Risk analysis.

One session. Maybe forty-five minutes total, including the time I spent thinking.

What happened in those forty-five minutes

Let me be precise about who did what:

Without me, Claude would have produced generic meeting-improvement advice. Without Claude, I'd still have the ideas in my head and no deliverable on anyone's desk.

The pattern you should steal

This works for anything. Not just meetings. Here's the sequence:

1. Start with the right question. Not "how do I fix X" but "what is X actually for?" Decompose the function, not the format.
2. Reduce to the irreducible set. Push until you can't merge any further. If your list has overlap, it's not done.
3. Design one solution per function. Use your experience, your judgment, your opinions. Don't ask the AI what to do. Tell the AI what you want.
4. Say "build it." Give Claude the structure and let it produce the artifact — the document, the code, the proposal, the system.
5. Review and ship. You're the editor. You approve. Then it's real.

The whole thing takes less time than the meeting you're complaining about.

Why this matters

People think AI replaces thinking. It doesn't. It replaces the production work around thinking. I still had to know why meetings fail. I still had to decide that blind input beats live brainstorming. I still had to insist that dissent gets preserved. Those are human calls — judgment, values, experience.

What I didn't have to do is spend three weeks writing a 30-page proposal. I didn't have to format questionnaires. I didn't have to draw pipeline diagrams. I didn't have to write a phased adoption plan. The AI did all of that, in one session, from four lines of plain English.

That's YOU++. You think. It types. You ship.

Read the full case study →

← All posts