Define the Outcome Conditions Before the Meeting

Having a meeting and moving the work forward are not the same thing.

A meeting may be scheduled every week. The document may keep changing. People may gather, follow the agenda, speak carefully, and agree on the next date. From the outside, the work can look active.

But after the meeting, it can still be hard to explain what actually changed. What was decided? What remains open? Who is doing what next? If those questions are still unclear, the work may be in a state where it appears to be moving, but has not actually advanced.

This is not only a problem in formal work meetings. In my own household, we once tried to hold a light weekly lunch meeting that we called a “strategy meeting.” The idea was to talk about what each of us was working on, both in work and in private life, and to keep a rough shared view of what was happening.

In practice, it did not always work very well. We had time to talk, but we had not defined what the meeting was for. Was it a place to share updates? To make decisions? To adjust responsibilities? Without that definition, the meeting could end without changing anything.

The same thing happens in work. A meeting exists. Time is reserved. People are present. But unless the meeting has a role, it is difficult to know what should be carried out of it.

By “the state of the work,” I do not mean the number of pages in a document or the amount of discussion that happened. I mean whether unclear assumptions became clearer, whether something became ready for review, whether someone can now make a decision, or whether the next action is easier to explain.

A meeting is not only a place for discussion. It becomes useful when what was discussed turns into judgment, review, responsibility, or next action.

That is why a meeting needs more than an agenda. It needs outcome conditions.

Outcome conditions define what should be true after the meeting for the work to have moved forward.

Before using AI to summarize the meeting, draft the document, or organize the notes, humans still need to define what the meeting is meant to change. AI can help produce cleaner outputs. It cannot decide, by itself, what should count as progress.

The meeting exit is often discovered during the meeting

When meetings do not work well, the issue is not only the number of meetings. Often, the issue is that the exit of the meeting has not been defined.

In work involving multiple people, meetings naturally increase. There are more assumptions to check, more documents to update, and more audiences to explain things to. Bringing people together on a regular rhythm can be necessary.

The problem begins when the presence of a meeting starts to look like evidence that the work is moving forward. There is an agenda, a document, discussion, and a next meeting. The form of progress is there.

Imagine a recurring Tuesday meeting where the only preparation is, “Let’s review the material we will show the client next time.” Once the meeting starts, people open the document and begin asking whether it is for the client’s working team or for senior stakeholders, whether the goal is to agree on structure or content, and what should actually be decided that day.

At that point, the meeting is no longer only reviewing the work. It is trying to design its own purpose while it is already happening.

This is not simply a problem of participant skill or motivation. It is a problem of not placing the meeting exit in advance.

When the exit is undefined, the group has to search for it during the conversation. People may talk for longer, but the meeting may still end without a clear change in the state of the work.

The answer is not always to add another meeting. Often, the first step is to define the exit before the meeting begins.

Outcome conditions define the next state of the work

Outcome conditions describe what should remain after a meeting for the work to have advanced.

They do not have to be large deliverables. A useful outcome may be one decision, a clarified open issue, a direction for the next document, or a named reviewer for the next step.

The important point is to define what the meeting is meant to change.

“Discuss the proposal document” is usually too weak as an outcome condition. It names the object of conversation, but not the state the work should reach after the conversation.

A more useful version would be: “Agree on the direction of the proposal document, clarify the remaining open issues, and name the reviewers before the next client check.”

With that sentence, the next movement becomes easier to see. Someone updates the structure of the document. Someone reviews it by Wednesday. Open issues are carried into the Friday client discussion. The meeting is no longer just a conversation about the document. It becomes a transition point in the work.

This is not about controlling the meeting too tightly. It is about connecting the meeting to the work.

To define outcome conditions before a meeting is to define the next state of the work before people begin talking.

Documents also hold agreements

A document is not only something to fill in. It can also be a place where agreements are held.

During a project, a template, worksheet, or shared document often appears. When that happens, it is easy to focus on how to fill in each field. That may be necessary. But the role of the document is not only to remove blanks.

A team may need to revise a client-facing document by Wednesday. If it is unclear whether that document is for internal thinking, stakeholder alignment, or executive explanation, every revision can pull the document in a different direction.

This is not only a writing problem. It is a role-definition problem.

A document for internal thinking may need to show options and uncertainties. A document for alignment may need to separate agreed assumptions from open issues. A document for senior stakeholders may need to make the decision path easy to understand.

When these roles are mixed, the document may grow while the agreement remains unclear. Pages are added, comments are resolved, and wording improves, but no one can say what has actually been agreed.

Before creating or revising a document, it helps to ask what the document is meant to hold. What are we agreeing on? What are we leaving open? Who should be able to understand or decide from this document?

Without that role, a document stays close to a work product. With that role, it becomes part of the operating structure of the work.

More stakeholders make judgment and responsibility harder to see

The more stakeholders are involved, the harder it becomes to see where judgment and responsibility actually sit.

This is natural in complex work. Different people bring different expertise. There are more reviewers, more audiences, and more people who need to understand the result.

A common pattern is that creation, review, judgment, and explanation become distributed across people. One person prepares the material. Another reviews it. A lead makes the final decision. A client-side counterpart explains it upward. That flow may be completely reasonable.

But when no one has made the role boundary visible, everyone can be involved while the actual ownership becomes unclear.

This is not about blaming anyone. It is about noticing when the work no longer shows who is judging, who is reviewing, and who is moving the next step forward.

The answer is not always heavy management. Often, it is enough to place a few simple lines before the meeting: who prepares, who reviews, who decides.

For example, one person prepares the document, another checks whether the content is valid, and the responsible lead decides whether it is ready to share with the client. Even that small distinction can make the work easier to carry.

Defining roles is not about fixing people in place or pushing responsibility onto someone else. It is about making collaboration easier by showing where judgment, review, and support belong.

Before using AI, humans still need to define the work

Before using AI, humans still need to define the work.

AI can clean up meeting notes, summarize discussion, draft outlines, and identify possible gaps. These are useful capabilities. They can reduce the burden around meetings and documents.

But there is a subtle risk. Once the notes look organized, the work can appear more advanced than it is.

If you ask AI to summarize a meeting, it may produce a clean summary. But if the meeting was never defined as a place to decide the direction of a document, clarify open issues, or name the next reviewer, the summary may remain clean while the work remains unchanged.

This is not only a limitation of AI. It is a problem with the work definition given to AI.

AI can help handle ambiguity. It can also make it easier to continue operating inside ambiguity.

That does not mean everything must be perfectly defined before AI is used. But at minimum, humans need to hold the direction of the work, the condition for progress, and the place where judgment remains human.

AI-era meeting design is not only about tool use. It is also about where humans place the premises that the tool will work from.

Start by writing one outcome condition for the next meeting

When meetings do not connect to work, the problem is not only meeting volume. The exit may be unclear, the role of the document may be mixed, and judgment or responsibility may be hard to see.

If AI is also involved, unclear human premises can make the outputs look cleaner while the state of the work remains mostly the same.

Before building a larger operating system, it may be enough to write one outcome condition for the next meeting.

For example:

“The next meeting should align on the direction of the proposal document, clarify open issues, and name the reviewers before the next client check.”

One sentence like this can change the preparation. It becomes easier to see what should be written, what should be explained, what needs to be decided, what can remain open, and who should review the next version.

If one sentence is not enough, it can be split into a few small prompts.

• What should remain after this meeting?
• What are we not deciding today?
• What needs to be checked before the next step?
• Who reviews, and who decides?
• Where will the latest premise be kept?

This does not need to become heavy management. It can simply be a small support structure that helps the meeting connect to the work.

A meeting can be reviewed not by how much was said, but by how the state of the work changed.

That change starts before the meeting, by defining what the meeting is meant to leave behind.

What Fragment Practice works on

Fragment Practice works on making meetings, documents, judgment, roles, and AI-use premises easier to handle in practical work.

The themes in this note — meeting exits, outcome conditions, document roles, responsibility boundaries, and human premises before AI use — are all operating structures for moving work forward. The answer is not only fewer meetings or cleaner documents. The work needs conditions that allow it to move into its next state.

In Products, Fragment Practice organizes these themes into practical kits for handling meetings, roles, outcome conditions, review, and pre-AI work definition. When the issue depends on a specific team, client context, or operating situation, Services or Contact may be the better path.

If meetings are happening but judgment is not being carried forward, if documents are growing but agreement is not visible, if external roles are becoming unclear, or if AI use is difficult because the work itself has not been defined, those are valid starting points for a conversation.

Start by writing one outcome condition for the next meeting.

From there, a meeting can begin to connect more clearly to the work.