The queueDecision within ten business days

What members asked for, and what we did about it.

Every request is a problem a member posted. A steward decides in public within ten business days, with a reason either way. Accepted requests are built behind a flag, checked, and shipped weekly. Declined requests stay here with the reason, so the queue is a record of the product’s direction, not just its backlog.


1 · Request

Post a problem, not a feature, in the product’s category. The AI team asks clarifying questions in the thread within hours. First response within one business day.

2 · Decision

The steward reads the thread and the usage evidence and marks it Under review, Planned or Declined, with the reason, in public. Decision within ten business days.

3 · Build

The AI team implements the change in a branch behind a flag. You can read the build log: what was read, what was written, what was run.

4 · Verify

Automated regression, layout, accessibility and data-consistency checks, then a small member testing cohort. No release without a passing check.

5 · Ship

Flag on for testers, then for everyone, in the weekly release window. The changelog entry names the member who raised the problem.

6 · Tell

A short changelog video every week and a community call every month walk through what changed and why.

The queue · live

What members asked for, and what we did about it.

Product The problem Raised by Status Decided in Shipped
Velocity [Problem statement as the member wrote it] [Member name] Shipped [3] days [date]
Producer [Problem statement as the member wrote it] [Member name] Building [2] days behind a flag
LevelUp [Problem statement as the member wrote it] [Member name] Planned [4] days [sprint]
LevelUp [Problem statement as the member wrote it]Declined by the steward: [the reason in one sentence, citing the charter line it breaks]. [Member name] Declined [6] days –

Every request gets a decision within ten business days. Declines are public, with the reason. Shipped entries name the member who asked. The first entries appear as the founding cohort posts its first problems.

How the queue works


Statuses

What each one means, and what you can see while a request is in it.

Status What it means What you can see
Under review The steward has read the thread and is weighing it against the charter and the usage evidence. The thread, the clarifying questions and your answers
Planned Accepted. The entry cites the charter line it serves and names the sprint it starts in. The decision and its reason, the sprint
Building The AI team is implementing it in a branch behind a flag. The build log: what was read, written and run
Testing Checks passed. The member testing cohort has the flag on. The check results and the testers’ notes
Shipped Flag on for everyone in the weekly release window. The changelog entry with your name, the help article, the video
Declined Not built, with the reason and the charter line it would break. Declines stay in the queue as a record of the product’s direction. The reason, in one sentence, in public

How a decision is made

Usage evidence and thread volume, weighed in public.

The steward reads the thread and, with consent, how that part of the product is actually used. A request that fits the charter gets built quickly. A request that breaks it gets a decline that cites the line it would break. Decisions weigh usage evidence alongside thread volume, so a vocal minority cannot dominate the queue, and the steward’s reasoning is public. A decision that cannot be explained in a sentence is not made.

Writing a problem that gets a fast decision

  • Say what happens, not what to build. “I lose an hour every Monday reconciling replies across three inboxes” is evidence. “Add a unified inbox” is a guess.
  • Say how often it happens, and what it costs you in time or money.
  • Say what you tried, and why it did not work.
  • One problem per thread. Two problems get two decisions.
  • Name the product. If you are not sure which one, say so; the AI team will ask.

What fits, by product

Each charter says what members can ask for and what falls outside it. Requests outside the charter still get a decision and a reason.

    • A Home widget
    • A report template
    • A sheet or slide template
    • A review routine improvement
    • A sync with a task or calendar tool you already use
    • A Money report or agent
    • Team chat
    • Payment initiation
    • A website builder
    • Workspace-wide visibility for admins
    [/fusion_tab]
    • A new reply class
    • A new autopilot that starts in Approve
    • A report or dashboard
    • A sending or enrichment provider
    • A workflow-rule trigger or action
    • A fit-scoring signal
    • A ticketing queue
    • Removing an approval gate from any send path
    • A mode that bypasses suppressions or LinkedIn limits
    • An assistant that sends without a confirm card
    • A new network
    • A new gate or check
    • A new motif
    • A report block
    • A CMS export format
    • An Optimize finding type
    • A research source
    • A video-studio step
    • An ads module
    • White-labelling
    • In-app credits
    • A publish path that skips the gates
    • AI-generated brand differentiators
    • A template look
    • A narration voice
    • A package output such as a vertical cut
    • An input format
    • A verification check
    • A brief field
    • A Studio control
    • A live-action editing timeline
    • AI presenters
    • Generated footage
    • An agent that renders or re-voices on its own
    [/fusion_tabs][/fusion_builder_column]

    What keeps the queue honest

    Against bloat

    The charter is the guardrail. Every accepted request cites the charter line it serves. Once a quarter the steward reviews usage and proposes removals, and removals get changelog entries like additions.

    Against fragility

    The Velocity test report from August is what fast building without verification looks like: data that disagrees across modules, a critical send path unguarded, a mobile layout that does not work. The verification stage exists so that never happens to a community-shipped change. Regression, layout, accessibility and data-consistency checks run on every build. Releases go behind flags. Rollback is one action.

    Against capture

    A vocal minority can dominate any queue. Decisions weigh usage evidence alongside thread volume, and the steward’s reasoning is public. A decision that cannot be explained in a sentence is not made.

    Against over-promising

    The commitments in the loop table are the only promises. The site never says “we build whatever you ask.” It says “we decide in ten days and tell you why.”

    Have a problem worth solving?

    Post it in the community. Say what it costs you, not what to build.

    How the whole loop works