Cutting Through the AI Noise
This is the fifth and final article in a series that started with the acceptance that I was not entirely sure what I was doing with AI, and that finding a productive relationship with it was taking more deliberate effort than I had expected.
What followed from that starting point was an approach to thinking about AI that I have found useful across client work and industry conversations, and then a closer look at each of the five categories within it, which you can see linked at the end.
This article is a round-up of where that thinking has landed, and a reflection on why many of us are fearing being left behind.
Five Ways to Think About AI
The first two categories, Building AI Products for Customers and Building Products for Customers With AI, are where most of the public conversation sits.
They are also where most of the investment is going and where the boldest claims are being made. These are genuinely important and genuinely hard problems.
However, it’s not really the reality of where most people in product and technology spend their working lives, and conflating them with the internal adoption challenges that the majority of practitioners are actually navigating does not help anyone.
The third category, Building AI Into the Way You Work as an individual, is where most people are actually starting, whether they frame it that way or not. As I wrote in that article, the path from occasional use to something that genuinely changes your output is real but not short.
It requires intent, some investment in how you organise your own knowledge, and a tolerance for iteration that the tools’ interfaces do not always make obvious.
💡
“ The people getting the most out of AI tend to be the ones who approach it as a deliberate practice rather than a tool to try. “
The fourth category, Building AI Into How Work Gets Done at a team level, is where a lot of well-intentioned initiatives start to stall. The coordination cost is higher than it looks, the data quality problems surface immediately, and the human behaviour change required tends to be underestimated.
A tool that works beautifully for one person becomes an infrastructure and governance problem the moment you try to make it work for a group.
Product Ops has a real role here, both in building and in the adoption, enablement, and ongoing maintenance that determines whether anything actually sticks.
The fifth category, Building AI Into Your Organisation, is where the most complex and least glamorous work lives. It involves measurement frameworks, maturity models, AI champions, governance structures, regulatory compliance, and the kind of sustained leadership sponsorship that cannot be substituted with individual enthusiasm alone.
The organisations making genuine progress are not the ones making the loudest announcements. They are the ones doing the slower, less visible work of building the conditions for adoption to spread and hold.
🤔
What has been your biggest shift in how you think about AI over the past six to twelve months, and has it changed which of these five categories you are focused on?
Promote Honesty Over Hype
Across all of this, it’s not any particular tool or capability that has been most impressive, concerning or genuinely interesting.
In fact, it’s the gap between what is being said about AI and what is actually happening inside most organisations that surprised me the most. And, that gap is being actively, and unfairly, widened by people who have an invested interest in speeding up the pace of progress and the growth of AI across markets.
The noise that is being generated is not always cynical, but it is not always honest either.
A recent example I came across: A conference video recording from a well-known product leader was positioned on an article page under the heading “The Rise of AI in Product Roadmapping.”
The talk itself covered three things: working from principles, planning for outcomes, and using rapid prototyping. All good advice. None of it specific to AI. The talk did not meaningfully discuss AI in roadmapping at all.
It was a talk about good product practice, which is valuable, but the framing above it implied something that was just simply not there. For anyone already anxious about whether they are keeping up with AI in their field, that kind of positioning adds pressure without adding clarity.
This matters because the fear of being left behind is producing real consequences. People are reaching for tools before they have the foundations in place to use them well. Organisations are announcing AI strategies before they have the individual practice, team processes, or governance infrastructure to support them.
As I wrote in an earlier article in this series, the sequencing problem is not theoretical. There are documented cases of security breaches occurring because employees, under pressure to demonstrate AI capability, used unapproved tools that bypassed the controls their organisations had in place.
The pressure to be seen doing AI can push people into shortcuts that create genuine risk.
The more honest picture, based on the conversations I have had across this series, is that most organisations are somewhere in the middle of building AI into their own individual workflows, just beginning to think seriously about how shared team processes need to change around AI, and have ‘Building AI Into Your Organisation’ as a stated ambition with variable amounts of real infrastructure behind it.
And, that is not a failure.
It’s exactly where you would expect most organisations to be given how recent and how fast-moving all of this is. The problem is not where people are. It is that the noise makes it hard to see where you actually are, and therefore hard to make good decisions about what to do next.
The most useful thing I have found, both for myself and in the conversations I have had with others, is to get specific. Not about AI in the abstract, but about which category you are working in, what the actual problem is that you are trying to solve, and whether AI is genuinely the right tool for solving it or whether it is just the most available one.
That specificity does not make the work easier. But it does make it more honest, and in my experience, more likely to go somewhere useful.
