Community · First reply within one business day
Members post problems. Practitioners decide.
The changelog names you.
The community is where the loop starts. Post the problem that costs you the most time, in your own words. The AI team asks its clarifying questions within hours, a steward replies within a business day and decides within ten. If it is built, the changelog credits you. If it is declined, you get the reason.
Post a problem, not a feature
Watch the decision
Test it first
Join the call
Who does what
Four roles. Each has clear authority and clear limits.
Members
Bring problems, not feature requests. “I lose an hour every Monday reconciling replies across three inboxes” is evidence. “Add a unified inbox” is a guess at a solution. Members also test, use, and tell the community what changed for them. Their weight comes from participation, not volume.
Practitioner stewards
One per product. A working marketer, seller or founder who uses the product daily, holds its point of view, writes its routines, accepts or declines requests in public, and is the person who says no. Without a steward, member-driven development becomes the sum of every request.
The AI development team
Does the work between decision and release. Intake: reading the thread and asking the clarifying questions. Analysis: checking how that part of the product is actually used, with consented data only. Build. Verification: regression, layout and data-consistency checks. Documentation: the help article and the changelog entry. Fast, tireless, non-interactive. It does not decide what to build and it does not release.
The release gate
A human. Nothing reaches all members without a person confirming that verification passed, the change matches the decision, and the help content is ready. The same rule the products themselves follow: AI acts, a person is at the gate.
What happens after you post
| When | What happens | What you see |
|---|---|---|
| Within hours | The AI development team reads your thread and asks its clarifying questions. | The questions, in the thread. Answer in your own words. |
| Within one business day | A first human reply. | Who is reading it, and whether it is going to the steward as written. |
| Within ten business days | The steward marks it Under review, Planned or Declined, with a reason and the charter line it serves or breaks. | The status and the reason, in public. |
| Within the published sprint | The AI team builds it behind a flag. | The build log: what was read, what was written, what was run. |
| Before release | Regression, layout, accessibility and data-consistency checks, then the testing cohort. | The check results and the testers’ notes. |
| The weekly release window | Flag on for everyone. | The changelog entry with your name, the help article, and the week’s video. |
How to write a problem
Say what it costs you, not what to build.
- What happens. The situation, in a sentence or two, as it actually occurs.
- How often, and what it costs. An hour every Monday. Three missed follow-ups a week. A number if you have one.
- What you tried. And why it did not work.
- Which product. If you are not sure, say so.
- One problem per thread. Two problems get two decisions.
Community norms
- Problems, not features. A feature request will be turned back into the problem behind it before it is decided.
- A public decline is a decision about the product, not about you. The reason is the useful part.
- No pay-to-prioritise. No tier moves a request up the queue, and no one can buy a decision.
- Testing cohort notes are published with the change. Say what broke, plainly.
- Enterprise work never enters this queue. It has its own path.
The testing cohort and the call
The testing cohort
Office hours
The monthly call
Usage intelligence, with consent
“We analyse how the apps are used” is a strength or a liability depending on one decision: whether members chose it.
- Telemetry is opt-in, per workspace, with a plain list of what is collected.
- Data is aggregate. No member’s content, contacts, keys or money is ever part of it.
- Findings are published to the community in the same form the stewards see them.
- Every analysis that led to a change is linked from the changelog entry, so members can see what their usage taught the product.
Post a problem
Say what it costs you, not what to build. A steward replies within one business day and decides within ten business days, in public, with a reason either way. If it ships, the changelog names you.
Every request is checked against the product’s charter: accepted requests cite the line they serve, declines cite the line they break.
The first ninety days
The community opens to everyone only after the loop has run in public with a founding cohort. Here is the order.
- Recruit a founding cohort of up to fifty practitioners who already use at least one product.
- Pick one real problem per product from the cohort, each fitting its charter.
- Run the loop in public: thread, decision with reasoning, build log, verification results, flagged release, changelog with the member’s name, changelog video.
- Publish the scorecard from month one, even when the numbers are small.
- Hold the first community call.
- Write the charters with the cohort and publish them.
- Open the community to everyone, with evidence on the wall.
Not a member yet?
One membership covers all four products, the queue, the changelog and the call.