How this helps you
You stop arguing about what to build next; the backlog sorts itself by value and risk.
Go through [backlog] and score every open item: Reach (how many users it affects), Impact (1 to 3), Confidence (percent), Effort (days), and Blast radius (low, medium or high: how much could break). Score = Reach x Impact x Confidence / Effort. Sort by score, list the top 5 with one line each, and flag any high blast radius item as needing human review. Don't add new items unless they came from a real request.
Fill in: [backlog] is your Notion database, Linear project or Jira board.
What they did
Rob Shocks uses Grok Bot as the manager of his software work. Everything his Chief of Staff Bot picks up from Slack and his conversations goes into a backlog that the Bot saves to Notion (he says Linear or Jira work too). A second routine triages the backlog with RICE scoring (reach, impact, confidence and effort) plus a blast radius score, so a small job that helps a lot of people rises above a minor fix. He also has the agent mark each change by blast radius, meaning how much could break, and use that to decide the review level. He warns against two things: asking the Bot to be proactive just for the sake of it fills the backlog with busywork, and running loops like this hourly burns a lot of usage.
Who it's for: Founders, product people and small dev teams who get requests from many places.
Before you start
- A backlog in Notion, Linear or Jira, connected to your Bot.
- Slack or email connected, if requests arrive there.
- Agreement on what 'reach' and 'impact' mean for your product.
How to try it
- Ask your Bot to file requests it sees in Slack and your chats into the backlog, one item per request (we haven't verified this step for your tools).
- Add fields for Reach, Impact, Confidence, Effort, Blast radius and Score.
- Run the prompt below once by hand and check the scores on items you know well.
- Fix the scoring rules until the ranking matches your judgment, then make it a daily routine.
- Use blast radius to set review: low can go to an agent's review, high always needs a person.
What to expect
A table of open items with the five fields and a score, a short top five, and a list of high blast radius items marked for human review.
Common mistakes
- Letting the Bot invent backlog items. Only real requests go in.
- Running it hourly. Daily is enough and uses far less of your weekly usage.
- Trusting scores you never calibrated. Check them against items you understand.
Related tips
- Make your Bot the manager, not the coder: one rule and locked doors: Let your Bot plan and check the work while coding agents write the code. Start with one rule, and remember every Bot shares one computer and its logins.
- From support form to fix: a webhook, a Bot and a Cursor cloud agent: A support form posts to a webhook, a Bot picks up the ticket, and for bugs it starts a Cursor cloud agent that reproduces the issue, adds a failing test and opens a pull request for an engineer to review.
- How to trust your Bot's work more: Put most of your effort at the top: code structure, then lint/tests/CI, then prose rules, then human review.
Worth knowingCarved from a segment of this video starting at 12:04. Paraphrased by us; watch the original for the full walkthrough.
Learn more: Grok Bot Routines Not Working? Do It by Hand, Save a Skill, Then Schedule · All Grok Bot routines tips