Building With AI Does Not Mean Creating Value With AI
In my AI fluency sessions with professionals and enterprises , I begin with three simple questions:
How many of you use AI regularly?
What do you use it for?
How confident are you?
The answers are usually encouraging. Many participants rate themselves around four out of five. They use AI to write emails, prepare presentations, ask questions, conduct research and brainstorm ideas. And they are right to feel positive. AI is helping them do these tasks faster and, often, better.
But when I speak with the CXO, promoter or senior management of the same organisation, I hear something different:
“We have bought the licences. People are using them. It may be improving individual productivity. But has it improved productivity across the organisation? We are not yet sure.”
Both perspectives may be correct.
Employees can experience real value in their daily work while the organisation sees little measurable change at the team or enterprise level.
This is the gap I have been trying to understand.
Adoption has happened. Value has remained local.
Most AI adoption I encounter is concentrated in relatively bounded tasks. The objective is reasonably clear, the context is contained, and a person can easily review the output.
Write this email. Summarise this document. Suggest an agenda. Help me research this topic.
These are useful applications. Research is also beginning to show measurable productivity gains from generative AI in real workplaces, although the gains vary by role, task and usage. A Microsoft study covering more than 6,000 employees across over 60 organisations found early evidence of productivity improvements from using Copilot.
The problem begins when we assume that better individual performance will automatically become organisational performance.
It does not.
Moving from individual assistance to team improvement requires a shared workflow. Moving towards enterprise value requires changes across processes, systems, roles, governance and measurement.
Meanwhile, organisational expectations are increasing. People are no longer being asked only to use AI for writing and research. They are being encouraged to build AI-enabled applications, automate workflows, develop internal tools and create agents.
The ambition has shifted from using AI to building with AI.
But our way of thinking has not necessarily shifted with it.
We are learning how to build before learning what to build
Building an AI-enabled solution has become remarkably easy.
Today, someone can describe an idea to AI, ask it to suggest the approach, connect a few tools and produce a working prototype. Courses teach us how to upload files, write instructions, add actions and assemble an agent or application.
All of this is useful. But it mainly answers one question:
How do I build it?
It does not adequately answer the questions that must come before it:
What is worth building? For whom? What outcome should it change?
I see the consequences when people begin testing what they have built:
“We did what AI told us to do.”
“It gave us a good result yesterday. Why is it giving something different today?”
“It works for one case but fails for another.”
“We gave it all the information. Why is the output still inconsistent?”
The immediate conclusion is often that AI is unreliable or the prompt is weak. Sometimes that may be true. But I increasingly believe the problem is deeper.
People have moved from completing a task to designing a product, workflow or system—without recognising that the nature of the work has changed.
Consider a simple expense-reimbursement system
Imagine an organisation wants to build an AI system that reviews employee expense claims according to company policy.
The task-first approach sounds straightforward: upload the expense policy, ask AI to read the receipt, and have it approve or reject the claim. Test it on five examples. If it works, the prototype is ready.
Then reality enters.
What if the receipt is unreadable? What if two policy rules conflict? What if the employee received prior approval? What if the spending limit varies by role or location? Should AI be allowed to reject a claim—or should it only flag the claim for a human reviewer?
These are not prompting questions. They are product and system-design questions.
But product thinking does not mean designing the entire system perfectly before building anything. It is also about solving the problem progressively—starting with the smallest use case that can create measurable value.
For the reimbursement example, the goal could be:
Reduce reimbursement time from five days to two without increasing incorrect approvals or adding work for finance.
Instead of immediately asking AI to build the complete reimbursement system, the team could use AI as a thinking partner:
Map why reimbursements take five days.
Identify the biggest and simplest bottleneck.
Build one low-risk intervention.
Test it on real claims.
Measure whether it improves the outcome.
Expand only after learning from actual use.
The investigation may reveal that the biggest delay is not approval. It is that employees submit incomplete claims and finance repeatedly asks for missing information.
So the first product need not be an “AI expense-approval agent.” It could simply be:
A pre-submission claim checker that reads the receipt, identifies missing information and tells the employee what must be corrected before submission.
This partly solves the problem, carries less risk and is easier to evaluate. If it works, the organisation could progressively add policy-eligibility checks, duplicate-claim detection and recommendations for finance reviewers. Eventually, it might automatically approve clearly defined, low-risk claims.
AI should not independently decide which use case is right. It can help decompose the problem and surface possibilities, but the team must validate those possibilities with employees, finance and real process data.
System thinking helps us understand the full problem. Product thinking helps us choose the smallest valuable part to solve first. AI helps us explore, build and learn faster.
This is more realistic than either blindly building the whole system or spending months designing it perfectly before testing anything. Value comes from how we frame, sequence and evaluate the work—not merely from what AI enables us to build.
This may be a thinking problem, not merely a prompting problem
Across such attempts, I repeatedly notice a few behaviours:
People jump to a solution before defining the problem.
They add more context when the output is weak instead of decomposing the problem.
Assumptions about users, data, decisions and exceptions remain unstated.
A coherent AI-generated answer is accepted without being adequately evaluated.
A successful demonstration is treated as evidence of value.
These are not isolated mistakes. They point to a larger mismatch:
People are applying a task-execution mindset to a product or system problem.
A task may have a relatively clear input and output. A system includes multiple users, decisions, dependencies, exceptions, consequences and feedback loops. It must work repeatedly, not just once.
Research supports part of this picture. The “jagged technological frontier” study found that AI improved performance for tasks within its capability boundary but could reduce performance outside it—even when the tasks appeared similar to people. A polished output is not always a reliable output.
My hypothesis goes one step further: when people move from using AI for a task to building an AI-enabled solution, they need capabilities closer to product and systems thinking than conventional task execution.
They need to ask:
What problem are we solving, and for whom?
What outcome should change?
How does the work happen today?
Which decisions should be made by rules, AI or people?
How will exceptions be handled?
How will we test whether the system creates value across many cases?
High performers redesign the work
This interpretation also fits what we are learning from organisations generating meaningful value from AI.
McKinsey’s 2026 global survey identifies only around 6% of respondents as AI high performers. Nearly three-quarters of these organisations report fundamentally redesigning workflows around AI, compared with roughly one-quarter of other organisations. The finding shows an association, not proof that workflow redesign alone caused their performance. But the difference is difficult to ignore.
The organisations creating value are not simply inserting AI into the way work already happens. They are reconsidering how the work should happen in the first place.
The same shift is reaching IT services
What is happening to employees inside organisations is also beginning to affect IT-services companies.
They will continue to be paid to design, build, integrate and maintain technology. But as applications, automations and agents become easier to create, the technology artefact alone will become less differentiated.
Clients will increasingly ask: What changed because of it? Did it reduce turnaround time? Improve accuracy? Increase revenue? Lower risk? Did people actually adopt it?
HCLTech describes this shift explicitly, saying that application services are moving towards measurable business outcomes and that workflow redesign is becoming a major lever for value creation.
The commercial model may not change overnight, but the expectation is already changing:
IT services are gradually moving from owning technology delivery to sharing responsibility for value delivery.
Whether you are an employee building an internal workflow or an IT-services company building for a client, the question is no longer simply, “Can you build it?”
The more important questions are:
Should it be built? How must the work change? What meaningful outcome will it create?
As building with AI becomes easier, knowing what to build—and why—becomes more valuable.
Building with AI does not automatically mean creating value with AI.
Stay grounded. Stay curious. The concepts aren't as hard as the jargon makes them sound.
-----
This is part of our ongoing work helping managers build an AI mindset—practical ways to think, decide, and work in the age of AI. It's not about mastering tools, but understanding how to work intelligently with intelligence. Looking forward to your feedbacks
Comments