AI-First Doesn’t Mean AI-Must
A couple of months ago, I completed the Becoming an AI-First Product Leader course on LinkedIn Learning. It was an excellent program — full of practical insights on how to adopt AI product principles, reimagine user experiences, and shift leadership mindset from the top. I’ve already found many of its lessons valuable in practice.
But there’s one nuance I think deserves more emphasis:
👉 AI-first does not mean AI-must.
The Temptation of “AI Everywhere”
When we hear AI-first, it’s easy to misinterpret it as always use AI. The hype is real. As product and engineering leaders, we sometimes feel pressured to impress stakeholders or executives by putting “AI” into every roadmap item.
But here’s the truth: just because AI can solve something doesn’t mean it should. Often, deterministic or rule-based solutions are faster, cheaper, and easier to maintain.
When AI Wasn’t the Best Choice
Here are a few situations where AI added more complexity than value:
- Estimator Systems (my experience): I once considered using AI for an estimator system that calculated results based on a few parameters. In reality, the logic was deterministic and explainable. AI would have added unnecessary variables and opacity. A rules engine worked far better.
- Inventory Reordering: Another classic example: a retailer invested in AI for stock reordering, but their sales patterns were seasonal and predictable. A simple threshold rule (“if stock < X, reorder Y”) was faster, cheaper, and required almost no maintenance. In my own work building a smart oil delivery system (digitizing analog gauges), I was tempted to use predictive models that considered usage patterns, weather, and oil readings. While promising, I realized most oil delivery companies preferred the traditional “K-factor” method — simpler, reliable, and proven.
When AI Was the Right Call
On the flip side, there are problems where rules collapse under complexity, and AI shines:
- Trash Can Trip Detection (my experience): When I was mentoring my daughter working on smart trash buddy project detecting trash can “tip over” events using if-else rules on a microcontroller. It was inaccurate and hard to maintain. Upgrading to a microcontroller that could run TensorFlow Lite allowed me to use a small ML model, which handled noisy sensor data much more robustly.
- Named Entity Mapping: When I first built Officebot, I relied on regex to map user intent. Very quickly, I ran into its limitations. Replacing regex with NLP-based entity mapping made Officebot far more flexible to real-world user commands.
And of course, there are countless other use cases — fraud detection, spam filtering, predictive maintenance — where AI is not just useful but essential.
What I Learned
Being “AI-first” means considering AI from the start, but also being disciplined enough to evaluate:
- Alternatives: Is a rules-based or deterministic approach sufficient?
- ROI: Does AI’s added value justify the cost and complexity?
- Transparency: Can I clearly explain why AI is or isn’t the right fit?
As technology leaders, our credibility comes not from sprinkling AI everywhere, but from making honest, customer-driven technology choices. Sometimes the most innovative choice is the simpler one.
Closing Thought
AI is transformative, but it’s not always necessary. “AI-first” should mean exploring AI as an option with rigor and honesty — not blindly applying it everywhere.
Real leadership lies in knowing when not to use AI.
👉 Have you seen a case where AI was overused — or where it made all the difference?
About Me:
I’m a hands-on engineer passionate about building scalable AI infrastructure, developer tools, and cloud-native systems. I share practical guides, real-world architectures, and open-source projects to help teams move faster with confidence.
https://www.linkedin.com/in/connectmithundas/
Co-Creator and Co-Founder of Officebot
