How to Prioritize a Hundred-Item AI Wish List

A retirement planning firm now keeps a wish list of roughly a hundred agents, sorted into fourteen categories.

Seven months ago the whole conversation was about one agent, the one another firm had quoted at $42,000.

That is what happens when things work. Every system that ships teaches someone what else is possible, and they come back with two more requests. It is the best problem a client can have. It is still a problem, because at the pace so far, ten agents in about seven months, a hundred items is the better part of six years of work.

So a hundred-item list is not a backlog. Nobody should plan a hundred things. You plan the next few, and you keep the rest honest.

Here is how.

Count what is already running

Before you rank anything new, write down what exists. Each live system on one line: what it does, who uses it, who owns it, what it costs to run, and what it depends on.

At ten agents this feels like paperwork. At thirty it is the only way anyone knows what they have. It also stops the most common waste on a long list: requesting something that already exists, or two thirds exists, under a different name.

Sort by what each item stands on

Wish lists arrive sorted by department, because that is how people think about their work. Marketing wants these, operations wants those, the advisors want the rest. That is a fine way to collect ideas and a poor way to rank them.

Rank by what each item stands on instead.

At this firm the CRM is mirrored into a database the builds read from, and the sales tracker refreshes from the CRM every hour. Anything that reads that data is now cheap. A new scorecard, a new report, a new alert: the hard part was done once, for the first build, and every later build on the same data reuses it. We also built a single sign-on landing page, so each new tool can sit behind the same front door rather than arriving with its own login.

That is what I mean by Stack Don't Scatter. Each build should make the next one cheaper. If it does not, all you are doing is collecting tools.

The items that need a data source not yet in the stack are different. Each one hides a data project inside it. Do not let them in one at a time. Wait until several items need the same new source, then open it once, for all of them together.

Three questions and four piles

For each remaining item, ask three questions.

How often does the work happen, and for how many people? Frequency beats irritation, as I have written before. The job done six hundred times a year beats the one everyone dreads four times a year.

Is the data already in the stack? Yes makes it cheap. No makes it part of a data project.

Is there a named person who will judge the output within a week of seeing it? If nobody will look at the first version and say what is wrong, it will sit unused however good it is.

Then put every item in one of four piles.

Now. Frequent work, data already in place, a judge who is ready. No more than three in flight at once. More than that and every one of them moves slowly.

Next. The coming quarter. Ranked, but not started.

Waiting. Items blocked on something specific, with the blocker written next to them: a data source, a decision, a missing owner, a review. Waiting without a named reason is just a polite way of saying never.

Not building. With the reason written down. Some ideas are worse than the work they replace, and the list is healthier for saying so.

What usually waits, in a firm like this one: anything that speaks to a client without an advisor reading it first. Anything whose value you could only read once a year. And anything that needs a new data source to itself.

Two names on every item

Every item gets two names. The person at the firm who asked for it and will judge whether it is right. And the person on our side who builds it.

The list as a whole gets one more name: the person who decides the order. At this firm the natural choice is the chief technology officer, who already sits in the demos and asked for most of what is live. The builder proposes the ranking. The owner decides it. That split matters. A builder who ranks his own backlog will drift toward the interesting items, and the interesting items are rarely the frequent ones.

One sitting

Take your list, however long it is, and do this in one sitting.

1. Write down what is already live, one line per system.
2. Next to every item on the wish list, write the data it needs and whether that data is already in your stack.
3. Ask the three questions. Put every item in one of the four piles.
4. Cap Now at three.
5. Put two names on everything in Now and Next.

Then re-rank once a month, in the same meeting where you look at what shipped. New ideas join Waiting until they have been through the three questions. And anything that has sat in Waiting for ninety days with nobody asking about it can come off the list. If nobody missed it, it was only ever a wish.