The queue · Decision within ten business days
Every request, every decision, in public.
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.
From a post to a shipped change
The six stages every request moves through, and what you can see at each one.
Stage 1
Request
A member posts a problem in the product’s category. The AI team asks its clarifying questions in the thread within hours.
What you see
The thread, the questions, the answers
We commit
First response within one business day
Stage 2
Decision
The steward reads the thread and the usage evidence and marks it Under review, Planned or Declined, with the reason.
What you see
The status and the reason, in public
We commit
Decision within ten business days
Stage 3
Build
The AI team implements the change in a branch behind a flag.
What you see
A build log: what was read, what was written, what was run
We commit
Started within the published sprint
Stage 4
Verify
Automated regression, layout, accessibility and data-consistency checks, then a small member testing cohort.
What you see
The check results and the testers’ notes
We commit
No release without a passing check
Stage 5
Ship
Flag on for testers, then for everyone. The changelog entry names the member who raised the problem.
What you see
The changelog, the help article, the flag
We commit
Weekly release window
Stage 6
Tell
A short changelog video and a monthly community call walk through what changed and why.
What you see
The video, the call, the recording
We commit
Weekly video, monthly call
The queue · live
What members asked for, and what we did about it.
| Product | The problem | Raised by | Status | Decided in | Shipped |
|---|---|---|---|---|---|
| Velocity | Expired meeting proposals could still be approved and sent, so a prospect could receive an invitation full of past dates. | LSI Media LLC | Shipped | 1 day | 5 Sep 2026 |
| Producer Studio | A release recording has long stretches of a terminal scrolling, and the script treats them as evidence and narrates them. | LSI Media LLC | Shipped | 3 days | 8 Sep 2026 |
| LevelUp | Decision notes never show up in the weekly review, so the same question gets re-decided twice and the reason is lost by Friday. | LSI Media LLC | Shipped | 3 days | 4 Sep 2026 |
| Publisher | The changelog article needs the member’s name and the request thread in a fixed place, and drafts keep putting them in different paragraphs. | LSI Media LLC | Shipped | 3 days | 9 Sep 2026 |
| LevelUp | The daily digest lists bills due but not the budget categories already over for the month, so I find out at the weekly review, a week late. | LSI Media LLC | Building | 4 days | behind a flag |
| Publisher | Social variants go out the moment an article publishes, but the changelog video renders an hour later, so the posts have no video. | LSI Media LLC | Building | 4 days | behind a flag |
| Velocity | Members who went quiet get the same re-engagement copy as cold prospects, and it reads wrong to someone who already paid us. | LSI Media LLC | Shipped | 5 days | 8 Sep 2026 |
| Producer Studio | Every weekly changelog video needs the same cold open and close, and I re-type the brief each time. | LSI Media LLC | Shipped | 2 days | in 0.2: team templates |
| Velocity | Let the engine skip the daily send cap for a campaign that is converting. Declined by the steward: daily caps, warmup and suppressions apply to every sender and no mode removes them; the charter says so in one line. |
LSI Media LLC | Declined | 1 day | – |
Every request gets a decision within ten business days. Declines are public, with the reason. Shipped entries name the member who asked.
Statuses
What each one means, and what you can see while a request is in it. The colour of a status follows it through the queue.
Under review
The steward has read the thread and is weighing it against the charter and the usage evidence.
What you can see
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.
What you can see
The decision and its reason, the sprint
Building
The AI team is implementing it in a branch behind a flag.
What you can see
The build log: what was read, written and run
Testing
Checks passed. The member testing cohort has the flag on.
What you can see
The check results and the testers’ notes
Shipped
Flag on for everyone in the weekly release window.
What you can see
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.
What you can see
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.
Members can ask for
- 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
Outside the charter
- Team chat
- Payment initiation
- A website builder
- Workspace-wide visibility for admins
Members can ask for
- 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
Outside the charter
- 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
Members can ask for
- 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
Outside the charter
- An ads module
- White-labelling
- In-app credits
- A publish path that skips the gates
- AI-generated brand differentiators
Members can ask for
- A template look
- A narration voice
- A text preset or caption style
- An effect or transition
- An export format or preset
- A brief field
- An editor control or shortcut
Outside the charter
- AI presenters or avatars
- Public video hosting and analytics
- Credits or metered AI inside the app
What keeps the queue honest
Against bloat
Against fragility
Against capture
Against over-promising
Have a problem worth solving?
Post it in the community. Say what it costs you, not what to build.