Most of the companies I talk to are making AI decisions one feature at a time and calling it a strategy.
That's not a criticism of anyone. It's just what happens. AI work naturally organizes into two kinds of conversation, and both are useful. There's the feature conversation, should we build this thing, will people use it. And there's the plumbing conversation, APIs, MCP, how this talks to that.
What tends to go missing is the one in between. What does all of this add up to. Whether the things you've shipped belong together or just happen to share a company.
That question usually doesn't belong to anyone, so it doesn't get asked.
The problem is you can't fix that by scheduling it. "Let's think about AI more holistically" is not an agenda, it's an hour nobody enjoys. People need something concrete to react to, and somebody has to go make that thing first.
Here's what I use. It's deliberately simple, because complicated frameworks don't survive contact with a room full of people who didn't build them.
Three overlapping circles.
Inform. You ask it, it answers. Automate. It works on your behalf, you're not there. Act. You direct it, it executes.
Overlapping rather than separate, because plenty of real features do two of those at once, and the versions of this that force you to pick one bucket per feature lose that.
Then you put everything you've already shipped onto it. Not the roadmap. Not the ideas. The things that are live right now.
Two things I've found reliably happen.
The first is that the list is longer than anyone expects, and it's usually the first time it has existed anywhere. Not a doc, not a slide, not a dashboard. If AI arrived at your company the way it arrived at most, in bursts, by whoever had the appetite, there's a decent chance nobody has ever seen all of yours in one place.
The second is more useful, and it's the sort most people skip. Do it again, but sorted by persona. Same circles, now organized by who each thing is actually for.
That's the sort that finds the hole. A capability gap is a roadmap item, and you'd have found it eventually. But a whole user with nothing anywhere is a different kind of problem, and it's genuinely invisible when you evaluate features one at a time, because every individual feature has a user. Nobody decides to ignore a persona. It's the sum of a dozen reasonable calls made without a view of the others.
The nice part is that once you can see who's uncovered, the question shifts from what should we build to which of these could we point at them. That's a much cheaper question.
Once both sorts are done, you can finally ask the question the whole exercise was for.
Look at where things cluster. If three features sit in the same circle and serve the same persona, that's not three features. That's one product your users are currently experiencing as three, because three different teams built them at three different times. Your org chart is visible in your product and nobody outside your company should be able to see it.
Those are your consolidation candidates. Not because consolidating is inherently good, but because the person using them already thinks of them as one thing and is confused that they aren't.
Then look at the isolated points. A feature that's alone in its region, serving a persona nothing else serves, is usually telling you it should stay standalone. Folding it into a suite because everything else got folded in is how you end up with a platform that's worse at every individual job than the tools it replaced.
That's the decision the map is actually for. Not what should we build next. What of this belongs together, what stands alone, and which of those answers are we currently getting wrong.
You can't make that call feature by feature. It's only visible from above.