The most common objection to building an ideas pipeline is "we already know what we need to build". Sometimes that is even true - for a quarter or two. Then the obvious projects are done, the pipeline is empty, and the AI programme quietly becomes a maintenance contract.
The Ideas pillar of the GIVE framework exists so that never happens. It is not a suggestion box. It is a menu of techniques, from nearly free to fairly involved, for surfacing the opportunities that are already in the business but invisible to the people who could act on them.
The short version: ideas hide in the things people have stopped noticing - shared mailboxes, hand-rebuilt reports, workarounds that get copied between teams. The techniques below surface them, ordered lightest to heaviest. You do not need all of them; you need the one that fits how your organisation actually behaves.
The menu, lightest to heaviest
The shared-mailbox audit. The cheapest technique and often the highest yield. Most organisations run whole processes out of shared mailboxes - requests arrive, someone triages, someone acts, nobody measures. Mining one mailbox for a month of traffic tells you the volume, the patterns, the handoffs and the exceptions. One law firm we work with receives around 100 lease contracts a week into a single shared mailbox - that one observation became their entire first use case.
The intake form. A form with best-practice fields - what is the problem, who does it affect, how often, what does it cost you today - gives everyone in the organisation a place to put an idea. The volume will not be huge. That is fine. The form's real job is signalling that ideas have somewhere to go, because capturing nothing eventually loses people.
Out-of-the-possible sessions. Point us at a department, give us their pain points, and we run a 45-minute session showing what is possible against those specific problems. The ideas that come out are pre-qualified - they belong to the people who own the pain, which is precisely who you need sponsoring them later.
Ideathons, hackathons and in-a-day workshops. Heavier, but they pull problems out of teams who would never raise them in a meeting, and they build capability while they do it.
The idea catalogue. We bring a catalogue of use cases we have already delivered for organisations like yours. It is a shortcut, not a substitute - the best entries are prompts that make someone say "we have that exact problem, but worse".
The citizen-developer signal. At the far end: let people build, and watch what they build. When the same small tool keeps getting copied between teams, you have found a real problem worth solving properly. This one needs governance around it, which is why it sits at the heavy end.
Opting out is allowed - once
Here is the part that surprises people: the Ideas pillar has no non-negotiables. A client can legitimately decide their ideas will only come from the technology team or the strategy. Some do.
What we hold firm on is that the decision is made deliberately and owned by governance - if ideas do arrive anyway, the AI council owns them rather than losing them. An explicit, governed no is fine. A default no, where ideas die because nothing exists to catch them, is how pipelines run dry.
What good looks like
The definition of done for this pillar is not a number of ideas. It is a working answer to one question: when someone in your organisation spots an opportunity, where does it go, and who decides what happens to it? If the answer names a mechanism and a decision-maker, the pillar is standing. The deciding part belongs to the Value pillar - because a full pipeline with no filter is just a different way of being stuck.
Sources and further reading