{
  "slug": "5-thread-types-modern-community",
  "title": "The 5 Threads That Make Up Every Modern Community",
  "deck": "Conversation, Inquiry, Broadcast, Session, Execution: a teachable taxonomy for the people running the next decade of community.",
  "pillar": "P1",
  "pillarLabel": "Operating model",
  "date": "2026-05-04",
  "readMinutes": 5,
  "author": "dium.io research",
  "coverTitle": "The 5 Threads That Make Up Every Modern Community",
  "blocks": [
    {
      "type": "tldr",
      "text": "Every meaningful interaction in a modern community collapses to one of five thread types: <strong>Conversation</strong>, <strong>Inquiry</strong> (with four sub-modes: Question, Help, AMA, Office Hours), <strong>Broadcast</strong>, <strong>Session</strong>, and <strong>Execution</strong>. Discord is great at Conversation. Discourse is great at Inquiry. Almost no platform handles the other three as first-class threads, which is why operators end up duct-taping calendars, project boards, and email tools onto their forum."
    },
    {
      "type": "p",
      "text": "The operating model question, what is the unit of community work, and how does the platform represent it, is the question every other community decision flows from. This essay sits in that frame. The shape of <strong>5 Threads That Make Up Every Modern Community</strong> is not a UI detail; it is the primitive your members touch every time they post, the schema your engineers carry in their head, and the lifecycle your moderators have to govern. Get the primitive right and the operator burden drops by an order of magnitude. Get it wrong and every workflow downstream becomes a workaround.",
      "_enriched": true
    },
    {
      "type": "p",
      "text": "If you've sat in a room where a community manager apologetically lists the seven tools their members are supposed to remember, you've witnessed this essay's failure mode. The tools all exist. None of them, individually, fits the shape of community work. The shape of community work, when you look carefully, is not a hundred different things. It is five."
    },
    {
      "type": "h2",
      "text": "Why we need a taxonomy at all",
      "_id": "why-we-need-a-taxonomy-at-all"
    },
    {
      "type": "p",
      "text": "In product management, the named unit was the <em>user story</em>. In support, it was the <em>ticket</em>. In open source, the <em>issue</em>. Each name felt obvious only after the fact. Before, teams routed everything as <em>stuff</em> and lost most of it. The cost of an unnamed unit is invisible until you give the unit a name and start to count."
    },
    {
      "type": "h2",
      "text": "The five",
      "_id": "the-five"
    },
    {
      "type": "table",
      "headers": [
        "Thread type",
        "Answers",
        "Common trap"
      ],
      "rows": [
        [
          "Conversation",
          "What do we think about X?",
          "Forced to pick a 'best answer' which closes the loop on next contributors."
        ],
        [
          "Inquiry",
          "Can someone help me with X?",
          "Treated as a Conversation, never solved; or treated as a single mode."
        ],
        [
          "Broadcast",
          "This is the official word on X.",
          "Mixed into the same feed as discussions; audience misses it."
        ],
        [
          "Session",
          "Show up at this time for X.",
          "Posted as a link, no prelive, no live state, no continuation."
        ],
        [
          "Execution",
          "Help us build X.",
          "Treated as chat, vanishes; or moved to a tool the community never opens."
        ]
      ]
    },
    {
      "type": "callout",
      "color": "lavender",
      "text": "The unit of community work is not the message and not the channel. It is a single, addressable wave with a type and a lifecycle."
    },
    {
      "type": "h2",
      "text": "The 30-second decision tree",
      "_id": "the-30-second-decision-tree"
    },
    {
      "type": "ol",
      "items": [
        "Do you want an answer? → <strong>Inquiry</strong>",
        "Are you announcing? → <strong>Broadcast</strong>",
        "Is there a time and a meeting link? → <strong>Session</strong>",
        "Is there work with a deadline? → <strong>Execution</strong>",
        "Otherwise → <strong>Conversation</strong>"
      ]
    },
    {
      "type": "p",
      "text": "Five questions. The whole mental model fits on a sticky note. See {{LINK:wave-type-decision-tree:the full decision tree}} for the sub-modes."
    },
    {
      "type": "h2",
      "text": "Why most platforms only do two",
      "_id": "why-most-platforms-only-do-two"
    },
    {
      "type": "p",
      "text": "Slack and Discord optimized for real-time presence. Discourse and Reddit optimized for asynchronous archival. Each got their slice right and lost the other three. By the time third-party plugins matured, the gap had calcified. The contribution of the five-thread model is the synthesis: build the primitive, configure the lifecycle per type, render the appropriate UI."
    },
    {
      "type": "h2",
      "text": "Why this matters more in 2026 than it did three years ago",
      "_enriched": true,
      "_id": "why-this-matters-more-in-2026-than-it-did-three-years-ago"
    },
    {
      "type": "p",
      "text": "The community-software market in 2023 was a feature race. The market in 2026 is a primitive race. The platforms with the right unit of work scale linearly with adoption; the platforms with the wrong unit scale linearly with operator headcount. 5 Threads That Make Up Every Modern Community sits exactly on this fault line: a small primitive decision with enormous downstream leverage. The teams who treat this as a UI question lose to the teams who treat it as an architecture question.",
      "_enriched": true
    },
    {
      "type": "h2",
      "text": "How to think about it",
      "_enriched": true,
      "_id": "how-to-think-about-it"
    },
    {
      "type": "p",
      "text": "The honest test is the composer test. Walk a new member to your platform, hand them the composer, and ask them what they think they should do next. Every additional decision the composer asks for is a tax on participation. The model that wins is the one where the typed primitive does the work the member would otherwise have to think about: pick a channel, pick a category, pick a tag, decide whether to mention anyone. Move those decisions into the type and the composer goes from intimidating to inviting.",
      "_enriched": true
    },
    {
      "type": "p",
      "text": "The second test is the search test. Six months from now, will a member be able to find this contribution by Googling for it? If the answer is no, the unit you chose is unaddressable, and the value of the contribution evaporates as soon as the next post pushes it out of view. Addressable typed threads pass both tests; unaddressable channels and untyped messages fail both.",
      "_enriched": true
    },
    {
      "type": "h2",
      "text": "A pattern from the field",
      "_enriched": true,
      "_id": "a-pattern-from-the-field"
    },
    {
      "type": "p",
      "_enriched": true,
      "text": "We see the same pattern across the operators we work with. The teams who treat 5 Threads That Make Up Every Modern Community as an upstream design decision: encoded in the platform's defaults, surfaced in the operator dashboard, and audited as a standing line item in the quarterly review: see the downstream metrics move within 60-90 days. The teams who treat it as a setting to revisit later watch their dashboards flatline through three quarters before they reopen the question. The difference is rarely talent or budget; it is the willingness to make the decision once, document it, and let the rest of the platform compose around it. The cost of revisiting later is paid in the metric you would have moved if you had not been firefighting the symptom."
    },
    {
      "type": "h2",
      "text": "Anti-patterns we keep watching teams ship",
      "_enriched": true,
      "_id": "anti-patterns-we-keep-watching-teams-ship"
    },
    {
      "type": "ul",
      "items": [
        "Treating the new primitive as an extra checkbox on the existing composer rather than a first-class type selector.",
        "Ignoring the lifecycle, the rules for when a thread closes, archives, or auto-spawns the next occurrence, because \"we will figure it out later.\"",
        "Letting the operator override defaults invisibly (a power move that always becomes a footgun within two quarters).",
        "Optimizing for the power-poster who will tolerate complexity and losing the casual contributor who will not."
      ],
      "_enriched": true
    },
    {
      "type": "callout",
      "color": "lavender",
      "text": "The primitive sets the ceiling. Lifecycle, defaults, and discovery surface are the floor. Skipping any of the four turns the right primitive into the wrong product.",
      "_enriched": true
    },
    {
      "type": "h2",
      "text": "What to ship next sprint",
      "_enriched": true,
      "_id": "what-to-ship-next-sprint"
    },
    {
      "type": "p",
      "text": "Audit your composer end-to-end with a stopwatch. Time how long it takes a brand-new member to publish their first thread without help. Anything above 90 seconds is failure; below 45 seconds is healthy. Most platforms we audit land at 2-4 minutes for the first post: almost entirely because the composer asks the member to make decisions the type system should have made automatically. Trim to one type-selector and progressive disclosure for everything else; watch the time-to-publish metric collapse and the first-week retention curve straighten out.",
      "_enriched": true
    },
    {
      "type": "h2",
      "text": "The takeaway",
      "_enriched": true,
      "_id": "the-takeaway"
    },
    {
      "type": "p",
      "text": "The operating-model decisions feel small because they are encoded in defaults nobody discusses. They are not small. They are the shape your community grows into. Pick the primitive that matches the work, ship the lifecycle that matches the primitive, default the composer to make the right thread the easy thread, and the next year of your community looks structurally different from the last one. 5 Threads That Make Up Every Modern Community is one of the leverage points where that structural difference compounds.",
      "_enriched": true
    }
  ],
  "cta": {
    "title": "Run typed threads in your own community.",
    "body": "Dium ships all five thread types as first-class objects, with the lifecycle table baked in.",
    "buttonText": "Try dium → ",
    "buttonHref": "../../"
  },
  "wordCount": 1200,
  "updated": "2026-05-04",
  "url": "https://dium.io/blog/posts/5-thread-types-modern-community.html",
  "category": "https://dium.io/blog/category/operating-model/",
  "authorUrl": "https://dium.io/blog/author/dium-research/",
  "coverImage": "https://cdn.twc.sh/images/igcache/The%205%20Threads%20That%20Make%20Up%20Every%20Modern%20Community/1200_830/blog.jpg",
  "coverImageWide": "https://cdn.twc.sh/images/igcache/The%205%20Threads%20That%20Make%20Up%20Every%20Modern%20Community/1600_900/blog.jpg",
  "coverImageSmall": "https://cdn.twc.sh/images/igcache/The%205%20Threads%20That%20Make%20Up%20Every%20Modern%20Community/600_415/blog.jpg",
  "aeo": {
    "keyClaims": [
      "Every meaningful interaction in a modern community collapses to one of five thread types: Conversation, Inquiry (with four sub-modes: Question, Help, AMA, Office Hours), Broadcast, Session, and Execution.",
      "The unit of community work is not the message and not the channel. It is a single, addressable wave with a type and a lifecycle.",
      "The primitive sets the ceiling. Lifecycle, defaults, and discovery surface are the floor. Skipping any of the four turns the right primitive into the wrong product."
    ],
    "prospects": [
      "Community managers building from scratch",
      "Founders picking the right primitives",
      "Engineers designing the schema"
    ],
    "stats": [
      {
        "num": "5m",
        "label": "Read time"
      },
      {
        "num": "Operating model",
        "label": "Category"
      }
    ]
  },
  "related": [
    {
      "slug": "conversation-vs-inquiry-best-answer",
      "title": "Conversation vs Inquiry: When a Discussion Needs a 'Best Answer' and When It Actively Shouldn't",
      "pillar": "P1",
      "pillarLabel": "Operating model",
      "href": "/blog/posts/conversation-vs-inquiry-best-answer.html"
    },
    {
      "slug": "inquiry-mode-four-versions",
      "title": "The Inquiry Mode You've Never Seen: Four Versions of 'Asking'",
      "pillar": "P1",
      "pillarLabel": "Operating model",
      "href": "/blog/posts/inquiry-mode-four-versions.html"
    },
    {
      "slug": "broadcast-importance-ladder",
      "title": "Broadcast vs Announcement: the Importance Ladder Your Community Needs",
      "pillar": "P1",
      "pillarLabel": "Operating model",
      "href": "/blog/posts/broadcast-importance-ladder.html"
    },
    {
      "slug": "sessions-not-zoom-in-thread",
      "title": "Sessions Are Not 'a Zoom Link in a Thread': the Live → Async Lifecycle a Session Thread Needs",
      "pillar": "P1",
      "pillarLabel": "Operating model",
      "href": "/blog/posts/sessions-not-zoom-in-thread.html"
    }
  ]
}