Chat prompts need a product graduation queue
In short: Repeated chat requests are useful product evidence only when a team owns the decision to graduate them into workflows or retire them.
On 9 October 2026, Atlassian's Sherif Mansour described a product portfolio with more than 20 apps, six built in the generative-AI era and over 5 million AI users. The surprise was not that chat won. It was that chat exposed requests worth removing from chat.
My rule is simple: repeated chat prompts need a product graduation queue. A team should either turn a proven pattern into a constrained workflow with an owner and acceptance metric, or record why it stays conversational or gets retired. Otherwise prompt telemetry becomes a shadow backlog nobody has agreed to build.
Atlassian used chat to discover dedicated workflows
1/ Atlassian nearly skipped chat because a blank box is a poor interface for many tasks. Mansour's direct SaaStr account says the company had to build a conversational backend across its portfolio anyway, so it shipped chat and watched what customers attempted.
2/ In Confluence Whiteboards, users repeatedly asked chat to group sticky notes into themes. Atlassian turned that request into a selectable feature. Users also tried to move brainstormed cards into Jira backlogs through elaborate prompts, so the team built a human-controlled workflow for that handoff.
3/ That pattern is stronger than a generic feature request because it contains a desired input, action and destination. It is still not proof of value. Prompt repetition can mean genuine demand, a missing control, user confusion or one enthusiastic cohort making noise.
A product graduation queue turns prompts into decisions
4/ This is my editorial proposal, not an Atlassian process I inspected. For each repeated prompt cluster, record six fields: who owns the decision, which users repeat it, what dedicated surface could replace it, what permission boundary applies, which acceptance metric matters and when the team will decide to graduate or retire it.
5/ The acceptance metric must match the job. For grouping sticky notes, measure whether people keep or substantially edit the groups. For creating Jira work, measure accepted issues, corrected fields, duplicate creation and reversal. Chat volume measures attempts; it does not measure finished work.
6/ Graduation should narrow the action. A free-form request can become a button, form, preview or approval step that makes inputs and consequences inspectable. Keep chat for the long tail and exceptions. Pull the stable, repeated path into an interface that can be tested and governed.
What I would test in a mature AI product
7/ I have not deployed this queue at Trigent or for a client. My labelled judgment is to run it first on four weeks of de-identified prompt clusters, exclude sensitive text, and ask one product trio to classify the top patterns as graduate, keep conversational, investigate or retire. Review the raw examples behind every cluster before accepting the label.
8/ The scale makes this discipline relevant. Atlassian's 5 February shareholder letter said Rovo had passed 5 million monthly active users. On 1 July, Atlassian reported more than 5 million MCP tool calls per working day, with nearly one third as writes. Those are company-reported activity figures, not evidence that a particular graduated feature improved retention or revenue.
What's in it for you
- Give exploratory chat a route into product work without promoting every clever prompt.
- Replace prompt-count theatre with accepted-work measures and explicit permission checks.
- Keep a visible decision for patterns the team will not build, so the backlog cannot grow by implication.
Chat is a useful discovery surface because people can ask for what the product does not yet expose. Its output becomes a roadmap only after somebody owns the graduation decision.
Do not count repeated prompts as demand; graduate them into a measured workflow or close the request.
