Starting with AI before understanding the need
In the story I heard, the ambition to do something with AI had come before a clear understanding of what it should solve. Ambitious figures who are keen to make a name for themselves have been stepping forward as the company’s “AI gurus” and driving initiatives before the teams have established whether anyone needs what they are making.
In my opinion, AI can help companies grow revenue and solve user problems better. Poorly executed AI initiatives can also seriously harm a company. But an initiative needs to start from an actual need, and the team should understand that need well enough to explain why the proposed solution is worth building.
I think there are two problems here that reinforce each other. The first is allowing the pressure to participate in the AI hype to drive product decisions. The second is assuming that being a capable Claude user is enough to lead the work, without giving enough attention to process, structure or which models are suited to the task.
When a team starts with the ambition to build something with AI, it can spend a lot of time looking for a problem that justifies that decision. People may still discuss user needs, but those conversations become less useful if the technology and direction have already been decided. Feedback that challenges the idea becomes inconvenient, even when it could save the team months of work.
Being a power user does not cover the whole job
People who evangelise Claude without understanding its weaknesses or the strengths of other models should raise a red flag. We choose different clothes for work, sport and sleep because each serves a different purpose. Why would we assume one AI tool or model is suited to every kind of work?
Model choice matters, but the workflow around it matters more. The team still needs a process for understanding the problem and deciding what to build, with enough structure to keep requirements, decisions and feedback connected as the work develops.
Tasks need to be broken down and sequenced, with a clear purpose, relevant context and instructions that account for the existing software. Quality assurance needs to be part of that workflow from the start, with verification checks that go beyond the examples chosen for the demo, including what happens when the model gives an incomplete or incorrect answer.
When development becomes a sequence of ad hoc prompts, the latest request can take priority over earlier requirements and decisions. Individual changes may appear to work while introducing inconsistent behaviour, duplicated logic or defects elsewhere. Being able to keep generating code does not mean the software is developing coherently.
AI can help with much of this work. It can make alternatives easier to explore and prototypes cheaper to test. My concern is that teams are using that speed to cut corners in analysis, verification and quality assurance, which can make the final product worse.
Keeping the work connected to the people using it
If we are unwilling to listen when users tell us that the proposed solution does not help them, we are building around our own interests. A convincing LinkedIn post or a new title may come out of that work, while the customer is left with the same problem.
I believe AI will help companies grow revenue and build products that serve their customers better. That is why it is frustrating to see the attention around it become a reason to skip the work that could make those outcomes possible.
If you are driving an AI initiative, is it coming from a need your users have, or from your own need to be part of the AI movement?