We Let an AI Product Owner Triage Our Idea Backlog

The Backlog Nobody Reviews

Every product that lets users submit ideas ends up with the same problem. Submission is cheap and review is expensive, so the queue grows monotonically. Ours had a hundred and forty open ideas at one point, some of them eighteen months old, several of them the same idea submitted by four different people.

The work isn't hard, it's just slow. For each idea you have to read it properly, search for whether it already exists, decide whether it's worth doing, and - if you're rejecting it - write a reason the submitter can read without feeling dismissed. Ten minutes an idea, conservatively. A hundred and forty ideas is three days.

So it never happens. And an ideas board nobody reviews teaches your users to stop submitting, which is a worse outcome than not having one.

What We Actually Built

FlowBoard exposes its API through an MCP server, which means an AI assistant like Claude or Cursor can read and write your board directly. On top of that we added the four review actions - accept, reject, rework, place - plus scoring, and a prompt that turns the whole thing into a workflow.

You say "review my idea backlog". The agent then works one idea at a time:

1. Reads the workspace schema, so it knows your priority formula and custom fields
2. Pulls the open ideas queue, most-voted first
3. For each one: reads the full description and its comments
4. Searches your workspace for duplicates and related work
5. Presents the title, submitter, vote count, age and current scoring
6. Recommends exactly one of accept, reject or rework, with its reasoning and the exact reason text it would post
7. Stops. Waits for you.

Only when you confirm does it write anything. Then it moves to the next idea.

The Stop Is the Point

It would have been easier to build the version that just processes the queue. We deliberately didn't, and the reason is worth being explicit about.

Rejecting an idea is a message to a human being. Someone took the time to tell you what they wanted from your product, and the reply goes in their name-stamped comment thread. An agent that fires off a hundred and forty of those unsupervised will eventually send one that's dismissive, or wrong, or rejects your biggest customer's most-wanted feature because it superficially resembled something you shipped last year.

The economics also don't work the way people assume. The expensive part of backlog review was never the decision - it was the reading, the duplicate hunting, and the drafting. The agent does all three. You keep the ten seconds of judgement that actually needs you. That turns three days into about an hour, which is a big enough win that you don't need to gamble the rest.

The Rubric Is the Whole Game

Out of the box, an agent judging your ideas will produce reasonable-sounding generic product management. It will like things that are popular and dislike things that are vague. That's not useless, but it isn't your product strategy.

So the criteria live in a rubric you control - a Markdown file the agent is given before it looks at anything. Ours says things like which customer segments matter, what we've decided not to build and why, what "too vague to action" means for us, and that an idea with three votes from one company is different from three votes from three companies.

If the recommendations feel consistently wrong, that's a rubric problem, not a model problem. Every time we disagreed with a recommendation and worked out why, that reason went into the rubric. After a couple of rounds we were agreeing with it most of the time - and the disagreements got more interesting, because they were about genuinely debatable ideas rather than about the agent not knowing us.

What It Turned Out to Be Good At

Duplicate detection. This was the biggest surprise. A human reviewing idea number ninety has forgotten idea number twelve. The agent searches every time, and it found clusters we'd have never spotted - four separately-worded requests that were obviously the same feature once you saw them side by side.

Writing the rejection. Drafting a reason that's specific, kind and short is genuinely tiring, which is why rejections tend to be either terse or postponed forever. Having a draft to edit removes the activation energy almost entirely.

Noticing stale context. Ideas that were reasonable when submitted but have since been overtaken - by a feature you shipped, or by a decision you made. A human reviewer skims the title and misses it.

Proposing implementation cost. Impact and client demand come from submitters and shouldn't be overwritten by an agent. But tech ease is an engineering judgement, and it's the score most often left at its default. Having something propose one with a stated reason is a real improvement over a field everyone ignores.

Where We Overrode It

Being honest about this matters more than the success stories.

It systematically undervalued ideas from a single high-value customer. Vote counts are a democratic signal and one enterprise account is not democratic. We fixed that in the rubric, but it's the kind of thing you have to catch.

It was too willing to call things duplicates. Two ideas that use the same vocabulary aren't necessarily the same request, and merging them loses the distinction. We now treat every duplicate recommendation as a prompt to look, not a conclusion.

And it has no access to the conversation you had in the corridor last week. Roughly one idea in ten got a decision that was correct on the available evidence and wrong given context that only existed in someone's head. That ratio is exactly why the confirmation step exists.

The Audit Trail

Anything an agent changes leaves a record. Scoring writes append a before-and-after comment on the task naming each changed field, so six months later you can see what was changed, what it was before, and that an agent did it. Set the user email in the configuration and decisions are attributed to your account rather than to an anonymous API key.

There are guardrails on the write side too. Idea review only operates on tasks that are genuinely on your ideas board - point it at a flow task and it fails with an explanation instead of quietly editing the wrong thing. Custom field values are validated against your configured fields rather than written blindly. And if a scoring update wouldn't actually change anything, nothing is written at all.

Trying It

You need the FlowBoard MCP server connected to your AI tool, and an API key with the Review Ideas scope. That scope is off by default on every key created before it existed and can't be added to an existing key - you generate a new one. It's a small annoyance that exists so no key silently gains the ability to close your users' ideas.

Start with a single idea rather than the whole queue. Read what it proposes, disagree with it, and see whether you can articulate why. That answer belongs in your rubric, and after three or four rounds of it you'll have something that reviews your backlog the way you would on a good day.

Get started with FlowBoard, or read about the MCP server and agentic project management.

Frequently Asked Questions

Does the AI make decisions on its own?

No. It researches and recommends, then stops and waits for your confirmation before calling any write tool. It also won't run ahead to the next idea before the current one is resolved.

Which AI tools does this work with?

Any MCP-compatible client - Claude Code, Claude Desktop, Cursor, Windsurf and others. FlowBoard provides the MCP server; you connect it to the tool you already use.

Can I change how it judges ideas?

Yes, that's the intended way to use it. The review rubric is a Markdown file you supply. Replace the bundled default with your own product criteria and the recommendations change accordingly.

Will it overwrite the priority scores my users voted on?

Impact and client demand represent reported demand, and the convention is that an agent proposes changes to them rather than making them silently. Tech ease - an implementation judgement - is the one it's most useful for it to set. Every change is recorded with its previous value.

What happens to rejected ideas?

They're closed with a required reason, posted as a comment the original submitter can read. Rejecting without an explanation isn't possible, because an idea closed silently teaches people to stop submitting.