How to prioritise AI use cases when every department builds

Ask around a company today and you will find people who have built a calculator for the sales team, an AI agent that reads tenders or a small dashboard for customer service. Some of these are worth a lot to the company. Most are worth a lot to one person or a small team.

This guide is for whoever decides which of them get time, money and an owner. It gives you some ideas for a process to choose which use cases to build properly.

The queue outside IT

Some IT departments now see a new kind of request. Once people can build, many of them knock on the IT door with an idea they want built out, connected to company data or rolled out to their team. The queue grows faster than any IT department can hire.

It can be tempting to say no when the queue gets long. That risks killing the engagement and the explosion of ideas that companies have wanted for years. So companies need a new way to filter bottom-up innovation, the agents and apps that people across the organisation now build.

The goal is to keep that energy and still choose well.

The AI innovation process, before and after

In many companies the pipeline for new ideas started on paper. An idea became a business case, the business case went to a steering group, and only after a yes did anyone build. This typically took months. The first thing people could try came at the very end.

With AI tools the order flips. The prototype comes first, the decision comes after it, and the people deciding look at something that works.

J.P. Eggers and Sarah Ryan of NYU Stern and Asha Dinesh of Miro write in Harvard Business Review that building has become the easy part and choosing the hard one.

So the decision stays, and it moves to after the prototype. The meeting where that happens is the betting table, a name we borrow from Shape Up.

What a bet is. A bet gives an idea a fixed amount of time and resources, for example two people for six weeks. Shape Up uses the word because you cannot know that it will pay off, so you cap what you risk. When the time is up, you decide again. The betting table is where bets are placed.

You can bet on almost anything people now build themselves.

In my previous job I ran product as Chief Product Officer. We built software with Shape Up, the method Ryan Singer wrote down at Basecamp. The shaped pitch went to a betting table, where we chose what to spend the next six-week cycle on. It is a good method, and I would use it again.

Good ideas come forward more easily

When people can build, they can show an idea instead of describing it. The person with the idea can prototype the solution, or a page that explains it, and show it. That used to take ten rounds on a whiteboard and many meetings. The vibe coding playbook for beginners shows how to build that first version.

Building also makes people better at ordering work. Someone who has made a first version knows what to ask IT or a supplier for, and can show what it should do.

From prototype to a tool the company owns

Five steps take an idea from one person's prototype to a tool the company owns, and most prototypes never need more than the first two.

• Build freely with the approved tools, on approved data or dummy data.
• Show it in a fixed demo slot the week before the betting table.
• Betting table every six weeks. The group sets a time budget, how much time the company will spend, before work starts.
• Build properly in six weeks. If it is not done by then, it stops. The six weeks and the hard stop come from Shape Up.
• Own it or retire it, with a stop rule and a review date agreed in advance.

What to bring to the table

Bring the prototype itself and one page that answers five questions.

• Whose job it helps. Name the progress a person is trying to make, what Clayton Christensen, the Harvard professor, and his co-authors call the job to be done.
• Why it is valuable. What it saves in time or money, or what it makes possible.
• How often the job happens, and how many people do it.
• Which data it touches. This decides how heavy the road to a company tool is.
• Who owns it the day the builder changes jobs.

The table reads the same page and asks two more things, whether other teams could use the tool as it is, and how much time it is worth.

Three outcomes for an AI prototype

Every prototype that is shown ends in one of three places.

Keep it yourself. A personal tool that saves one person an hour a week. No bet is needed, and this is a good outcome. Most prototypes should end here, and the table's most useful sentence is "that is yours, keep it".

The team's. A light bet, where the tool gets an owner in the team and a shared folder, and the team decides how it changes. We wrote about that step for skills in Skills in Claude Cowork, where one person's skill is shared so the whole team works to the same standard.

The company's. This is a real bet. The tool gets six weeks of work, a security review, access to the right data and documentation. Few prototypes get here.

Who sits at the table

Keep the group small, with someone who knows the daily work in the teams that build, someone with a budget, and someone from IT and security who can say what the data rules allow. Leaders alone do not know the jobs, and the builders alone cannot commit the money. The builder of each prototype joins for a 15-minute pitch.

When an idea touches strategy or the whole company, someone from C-level joins too.

It has never been more valuable to gather nerds and domain experts in one room, with superpowers from Claude Code.

Simon Sebergsen

Beside the process you already have

The betting table works beside the idea process you already have, and it changes where the first real decision sits.

The big bets still go through strategy, which How to tackle big company bets with AI covers.

Before the first round

Start with dummy data. Data that is approved for use works too, and you do not need a system integration or live data to get started. Claude can make fictional data for the prototype, and a prototype shows what it is worth without being connected to a system.

Time to build. If building happens only after hours, you only see the enthusiasts' ideas. An hour or two a week, agreed with each manager, is enough to start.

One owner. The betting table needs an owner who sets the dates, gathers the pages and sends the reminders. Who that is varies from company to company. It can be someone in IT, business development or strategy, or one of your AI ambassadors. The process often dies after the first round when it belongs to everyone.

A first round

Open the betting table to everyone in the company. Good ideas come from every department and every role, often from the people closest to the work.

Pick a date six weeks from now, with a demo slot the week before. Ask everyone who has built something to bring it with one page. With the people who know the work, look at what comes in and bet on two. For everything else, say "keep it" and mean it.

Write down what the company learns, as How to build AI capital describes.

Through the year

The first round is a start. After that the betting table is a rhythm, every six weeks. Put the dates in the calendar for the whole year, so people who build know when the next chance comes.