Once an organization has identified several potential AI opportunities, a new challenge appears:
Where should we start?
This decision matters more than it may seem.
The first AI project often shapes how employees and leaders view everything that follows.
If the first initiative is overly complex, expensive, poorly defined, or difficult to measure, the organization may conclude that AI is not practical.
If the first project is too trivial, employees may conclude that AI is interesting but not particularly valuable.
The strongest starting point usually lies somewhere in between.
It should be:
important enough to matter,
small enough to manage,
safe enough to learn from,
and
clear enough to measure.
That is the ideal first AI use case.
Do Not Start With the Biggest Idea
AI creates enormous possibilities.
Once organizations begin brainstorming, ambitious ideas often emerge quickly.
Automate the entire customer service function.
Predict every major operational risk.
Connect AI across all departments.
Build a company-wide AI assistant.
Create real-time predictive analytics across every product line.
Redesign an entire workflow around AI.
Some of those ideas may eventually be excellent.
They are often poor first projects.
Large AI initiatives tend to involve multiple readiness challenges at the same time:
data quality,
system integration,
employee adoption,
security,
governance,
training,
process redesign,
vendor management,
and organizational change.
That creates many opportunities for failure.
A smaller project allows the organization to isolate problems, learn quickly, and build capability before complexity increases.
The First Project Should Teach the Organization Something
A successful first AI initiative should create more than an operational result.
It should create organizational learning.
The organization should learn:
how to define an AI problem,
how to select a tool,
how to prepare data,
how employees respond,
what governance issues emerge,
what technical support is required,
how long implementation actually takes,
how results should be measured,
and what should happen next.
This learning becomes reusable.
The second AI initiative is usually easier because of what the organization learned from the first.
The third becomes easier still.
That is how AI capability grows.
Look for High Value
A strong starting point should solve a problem people actually care about.
Value can take many forms.
Time
Could AI reduce hours of repetitive work?
Cost
Could the organization eliminate unnecessary expense?
Revenue
Could AI help identify opportunities, improve forecasting, or strengthen customer retention?
Capacity
Could employees accomplish more without adding significant headcount?
Quality
Could errors or inconsistencies be reduced?
Speed
Could customers or employees receive information faster?
Insight
Could leaders see patterns they currently miss?
Employee Experience
Could AI reduce frustrating administrative work?
Customer Experience
Could service become faster, more accurate, or more personalized?
Risk Reduction
Could AI help identify problems earlier?
The project does not need to improve every category.
It should improve at least one in a meaningful way.
Value Should Be Visible
An early AI win should ideally be understandable to people who did not build it.
For example:
“This report used to take six hours every week. Now it takes two.”
“We can now identify customers whose purchasing behavior is declining.”
“Employees used to search through 200 pages of documents. Now they can find the relevant policy in seconds.”
“We reduced the time required to review these records by 60 percent.”
“We can now detect unusual sales activity earlier.”
Clear outcomes build credibility.
They help leadership understand what AI can do.
They help employees see practical relevance.
And they create momentum for future adoption.
Look for Low or Manageable Risk
Value alone is not enough.
Organizations should also consider the consequence of failure.
Ask:
What happens if this AI system produces the wrong answer?
If the result is merely inconvenient, the risk may be low.
If the result could harm a person, create a legal problem, expose sensitive data, interrupt operations, or cause a major financial loss, the risk is much higher.
A good starting project usually has consequences that are manageable.
That does not mean the use case must be meaningless.
It means mistakes can be detected and corrected without creating serious harm.
Human Review Can Lower Risk
One of the easiest ways to reduce risk during early AI adoption is to keep people in the process.
Instead of:
AI makes the decision.
Begin with:
AI makes a recommendation. A person reviews it.
Instead of:
AI sends the customer communication automatically.
Begin with:
AI drafts the communication. An employee approves it.
Instead of:
AI changes production schedules automatically.
Begin with:
AI identifies patterns or recommends adjustments. A supervisor decides what to do.
This approach allows organizations to test AI capability while maintaining human accountability.
Over time, some workflows may become more automated.
But early pilots often benefit from meaningful human review.
Start With Reversible Decisions
A useful way to think about risk is to ask:
If this goes wrong, can we easily reverse it?
Consider two examples.
An AI system generates a draft internal summary.
If the summary is poor, an employee corrects it.
The consequence is limited.
Now consider an AI system automatically rejects a job applicant.
That decision may have meaningful consequences for another person.
The second use case requires far stronger governance.
Early AI projects are easier when mistakes are reversible.
Reversibility creates room for experimentation.
Avoid Sensitive Data When Possible
Organizations can often reduce early risk by choosing projects that do not require highly sensitive information.
A first pilot using historical sales totals may be easier to govern than one involving employee medical information.
A project analyzing anonymous customer feedback may be easier than one involving personally identifiable customer records.
A document assistant using public-facing materials may be easier than one requiring access to confidential legal documents.
This does not mean sensitive data should never be used with AI.
It means organizations can often learn important lessons in lower-risk environments first.
Choose a Process That Is Already Understood
A first AI project becomes unnecessarily difficult when the underlying process is already chaotic.
If employees cannot agree on how the work is currently performed, adding AI can create even more confusion.
Strong early use cases often involve processes that are:
reasonably well understood,
repeated frequently,
performed consistently,
and supported by identifiable data.
This makes it easier to compare:
before AI
and
after AI.
Choose Data You Can Actually Access
A use case may appear extremely valuable but still be a poor starting point if the required data is inaccessible.
Imagine an organization wants to predict equipment failure.
That could create enormous value.
But if maintenance records are incomplete, sensor data is unavailable, and failure history was never documented, the project may require significant preparation before AI can help.
Meanwhile, another opportunity may rely on five years of clean sales data that is immediately available.
The second project may be the better starting point even if the first has greater long-term potential.
Readiness matters.
Favor Short Feedback Loops
Early AI pilots are easier to evaluate when results become visible relatively quickly.
Suppose an organization uses AI to improve a weekly report.
Within a month, it may have several opportunities to measure performance.
Now compare that with an AI project intended to predict an event that occurs once every two years.
It may be difficult to know whether the system works.
A short feedback loop allows organizations to:
observe results,
identify mistakes,
adjust the process,
retrain employees,
and improve quickly.
This accelerates learning.
Look for Frequent Tasks
Frequency can make modest improvements valuable.
Suppose an AI workflow saves 10 minutes.
That sounds small.
But if 30 employees perform the task eight times per week:
10 minutes × 30 employees × 8 uses
= 2,400 minutes
or
40 employee hours every week.
That is approximately one full-time workweek of capacity recovered from a seemingly small improvement.
Early projects with frequent repetition can create measurable results quickly.
Frustrating Work Can Be an Excellent Target
Some tasks create disproportionate employee frustration.
They may be:
repetitive,
tedious,
administrative,
manual,
or mentally draining.
These tasks can make excellent AI starting points.
Why?
Because employees immediately feel the benefit.
A project that eliminates an annoying weekly task may create more enthusiasm than an analytically sophisticated system employees rarely interact with.
That matters.
Early adoption is not only about proving technological value.
It is also about building employee confidence.
Find the Work No One Wants to Do
Ask employees:
“What task would you gladly never do manually again?”
The answers may reveal excellent candidates.
Maybe it is:
combining spreadsheets,
writing repetitive summaries,
reviewing hundreds of comments,
categorizing incoming requests,
transcribing information,
checking records for missing fields,
preparing routine reports,
or searching through documentation.
These tasks often share several useful characteristics:
they are repetitive,
easy to understand,
measurable,
and relatively low risk.
That combination can make them strong pilot candidates.
Look for Decision Support Before Decision Automation
Organizations are frequently attracted to AI systems that make decisions automatically.
Those systems can eventually create significant value.
But early in the AI journey, decision support may be a better place to start.
For example:
Instead of automatically deciding which customers require intervention, AI identifies customers showing unusual behavior.
A salesperson reviews the list.
Instead of automatically scheduling maintenance, AI identifies equipment with abnormal patterns.
A technician investigates.
Instead of automatically adjusting inventory, AI flags items with unusual demand.
A manager decides whether action is needed.
This structure combines AI's ability to process information with human expertise and judgment.
Use Historical Data Before Live Data
Another useful way to reduce risk is to test AI against historical information.
Suppose an organization wants to evaluate whether AI could improve sales forecasting.
Rather than immediately using AI to drive next month's business decisions, the organization can ask:
What would this model have predicted six months ago?
Then compare the prediction with what actually happened.
The same approach can be used for:
customer retention,
quality issues,
equipment failure,
financial anomalies,
and other predictive applications.
Historical testing provides evidence without immediately affecting live operations.
Compare AI Against the Current Process
AI does not need to be perfect.
It needs to improve upon the current alternative.
Suppose employees currently forecast sales with 70 percent accuracy.
If an AI-supported process produces 82 percent accuracy, that may represent meaningful improvement.
Suppose employees manually classify incoming requests correctly 90 percent of the time.
An AI system that achieves 88 percent accuracy may not be an improvement, even if the technology seems impressive.
The relevant question is not:
“How good is the AI?”
It is:
“Is this better than what we do today?”
That comparison keeps pilots grounded.
Establish the Baseline First
Before implementing the pilot, record current performance.
Depending on the use case, that may include:
hours required,
cost,
error rate,
response time,
forecast accuracy,
number of items processed,
customer satisfaction,
employee satisfaction,
or frequency of rework.
The baseline does not need to be perfect.
It needs to be good enough to support comparison.
Without a baseline, organizations can easily mistake enthusiasm for improvement.
Define Success Before the Pilot Begins
A pilot should not end with leadership asking:
“So, did it work?”
The criteria should be established beforehand.
For example:
The pilot will be considered successful if average report preparation time decreases by at least 40 percent while maintaining current accuracy.
Or:
The pilot will be considered successful if AI identifies a meaningful percentage of declining customer accounts earlier than our current process.
Or:
The pilot will be considered successful if employees can locate approved policy information in less than two minutes with acceptable accuracy.
Specific targets create clarity.
They also make it easier to decide whether to scale, modify, or stop the project.
Measure More Than Time Savings
Time savings are valuable.
But they are not the only measure that matters.
A pilot may also affect:
accuracy,
consistency,
employee workload,
employee satisfaction,
customer satisfaction,
quality,
risk,
revenue,
or decision speed.
For example, an AI-supported process might not save much time but could significantly improve the quality of information available to a manager.
That may still be highly valuable.
Organizations should measure what matters for the problem being solved.
Calculate Value Simply
Organizations do not need complex financial models for every pilot.
A basic calculation can often be useful.
Suppose:
20 employees save 2 hours per week.
That equals:
40 hours per week.
If the average fully loaded employee cost is approximately $35 per hour:
40 × $35 = $1,400 per week
Across 50 working weeks:
$1,400 × 50 = $70,000 in annual capacity value.
That does not necessarily mean the organization will reduce payroll by $70,000.
More often, it means employees have approximately $70,000 worth of capacity available for other work.
That distinction is important.
Time savings should be translated into organizational value thoughtfully.
Capacity May Be More Valuable Than Cost Reduction
Organizations sometimes evaluate AI only through headcount reduction.
That is too narrow.
Imagine an organization that is growing.
Employees are already overloaded.
AI allows the same team to handle 25 percent more work.
No jobs disappear.
But the organization may avoid hiring additional staff immediately.
Or employees may spend more time on:
customers,
innovation,
quality,
sales,
training,
or problem-solving.
That additional capacity can be extraordinarily valuable.
AI value does not have to appear as a reduced payroll line.
Select a Clearly Defined Pilot Group
Do not involve the entire organization immediately.
A smaller pilot group creates several advantages.
It is easier to train.
Easier to support.
Easier to observe.
Easier to collect feedback.
Easier to identify problems.
And easier to stop if necessary.
The pilot group should ideally include employees who:
understand the work,
are reasonably open to experimentation,
will provide honest feedback,
and represent the real users of the eventual solution.
Avoid choosing only technology enthusiasts.
A pilot needs to reflect practical workplace conditions.
Give the Pilot an Owner
Every pilot needs someone responsible for moving it forward.
The owner should be able to answer:
What are we testing?
Who is participating?
What does success look like?
What problems have emerged?
What data are we collecting?
What have employees learned?
When will we evaluate the results?
Without ownership, pilots can drift indefinitely.
They become experiments that never really begin or end.
Establish a Beginning and an End
A pilot should have a defined period.
Not necessarily a rigid timeline, but a clear evaluation point.
For example:
“We will test this for six weeks.”
“We will evaluate after 100 transactions.”
“We will compare three months of historical forecasts.”
“We will test with one department before considering expansion.”
An evaluation point forces the organization to review evidence.
Otherwise, temporary pilots have a tendency to become permanent systems without formal decisions.
Keep the Pilot Narrow
Scope creep can destroy an otherwise good pilot.
The project begins as:
“Let's use AI to help prepare the weekly sales report.”
Then someone asks:
“Could it forecast next month too?”
Another asks:
“Could we connect customer service data?”
Another says:
“Could we build a dashboard?”
Soon the small experiment becomes a major technology initiative.
Those may all be good future ideas.
Write them down.
Do not necessarily add them to the current pilot.
A pilot should answer one primary question:
Does this use case create enough value to justify doing more?
Separate Pilot Problems From AI Problems
When a pilot struggles, organizations should determine why.
Was the AI incapable?
Or was the data poor?
Was the process unclear?
Did employees receive insufficient training?
Was system access difficult?
Did the technology not integrate well?
Were expectations unrealistic?
Was the use case poorly selected?
These distinctions matter.
A failed pilot does not necessarily mean AI failed.
It may reveal a readiness gap.
That is valuable information.
Learn From Near Misses
Suppose an AI pilot works 95 percent of the time.
That may sound excellent.
But examine the remaining 5 percent.
What happened?
Were the errors random?
Did they occur under predictable circumstances?
Were certain types of records problematic?
Did missing data create failures?
Could human review catch the mistakes?
Are the failures acceptable given the use case?
Sometimes the exceptions tell an organization more than the successes.
Employee Feedback Is Evidence
Metrics matter.
So does employee experience.
Ask pilot participants:
Did this make your work easier?
Where did it create additional work?
Did you trust the results?
When did you ignore the AI?
What mistakes did you notice?
Would you continue using it?
What would make it more useful?
Did the training prepare you?
What surprised you?
Employees may identify operational problems that performance metrics miss.
A technically successful AI system that employees dislike using may struggle to scale.
Do Not Hide Pilot Failures
Organizations should share what they learn, even when a pilot does not succeed.
Suppose the organization discovers:
the available data is not reliable enough,
the tool is too difficult to use,
the cost exceeds the benefit,
employees require too much manual correction,
or the system cannot handle common exceptions.
That knowledge can prevent a much larger mistake.
The appropriate conclusion may be:
“This isn't ready yet.”
or
“This is not the right solution.”
That is responsible AI adoption.
Decide: Scale, Modify, Pause, or Stop
At the end of a pilot, there should be a decision.
Scale
The results justify broader implementation.
Modify
The use case appears valuable, but improvements are needed.
Pause
The idea may have potential, but the organization is not ready yet.
Stop
The evidence does not justify further investment.
All four outcomes are legitimate.
The only poor outcome is continuing indefinitely without evaluation.
A Simple Starting-Point Matrix
Organizations can evaluate candidate projects using two basic dimensions:
Value
How meaningful would success be?
Risk and Complexity
How difficult or consequential would implementation be?
This creates four broad categories.
High Value / Low-to-Moderate Risk
Strong starting points.
These deserve serious consideration for early pilots.
High Value / High Risk
Potentially important, but proceed carefully.
Build capability first or reduce the scope.
Low Value / Low Risk
Useful for learning, but may not create much organizational impact.
These can be acceptable experiments but should not become the entire AI strategy.
Low Value / High Risk
Poor candidates.
There is little reason to accept substantial risk for minimal benefit.
This simple framework can eliminate many weak projects quickly.
Characteristics of a Strong First AI Project
A strong early AI initiative often has many of these characteristics:
It solves a real organizational problem.
Employees care about the problem.
The problem occurs frequently.
Success would create visible value.
The process is reasonably well understood.
Required data is available.
Data sensitivity is manageable.
The technology can be tested without major infrastructure investment.
Human review can remain in place.
Mistakes are reversible or manageable.
Results can be measured.
Feedback can be collected quickly.
The pilot can remain limited in scope.
Someone clearly owns the project.
The organization can stop without significant disruption.
Success could eventually be scaled.
Very few projects will meet every characteristic.
The objective is to find a favorable balance.
First-Project Readiness Self-Check
Consider each statement based on the specific project your organization is considering, not what may become possible after additional preparation.
Select the response that most accurately reflects the proposed project today.
The project addresses a clearly defined problem.
The problem is meaningful enough that improvement would matter.
The problem occurs frequently enough to justify attention.
Employees who experience the problem support testing a solution.
We understand the current process.
We can measure current performance.
The required data is available.
The data is reliable enough for an initial test.
Sensitive information can be avoided or appropriately protected.
The technology can be tested without major infrastructure changes.
Human review can remain part of the process.
Mistakes during the pilot would be manageable.
The pilot can be limited to a small group or controlled environment.
We can receive meaningful results within a reasonable number of cycles or transactions.
Success criteria can be defined before implementation.
Someone clearly owns the pilot.
Employees participating in the pilot can receive appropriate training.
We know how pilot feedback will be collected.
We are willing to modify or stop the project based on evidence.
If successful, the project could create a pathway toward broader AI capability.
This use case may represent a strong starting point. The problem, process, data, risk, ownership, testing environment, and measures of success are reasonably well understood.
The project may be promising, but additional preparation is needed. Focus on the incomplete areas before expanding the scope or committing substantial resources.
This project may not yet be the best first pilot. Consider reducing its scope, addressing the major readiness gaps, or comparing it with a more manageable opportunity.
A strong first AI project should be meaningful enough to matter, but controlled enough to support learning. The objective is not to prove that AI always works. It is to help the organization learn how to evaluate, implement, measure, and govern AI responsibly.
A Practical Pilot Selection Exercise
Take the three most promising AI opportunities identified in Chapter 11.
Rate each opportunity from 1 to 5 across the seven criteria below. A score of 1 represents a weak fit, while a score of 5 represents a strong fit.
The highest-scoring opportunity does not automatically have to become the first pilot. Use the ratings to identify tradeoffs, expose assumptions, and compare practical implementation conditions before making the final decision.
Practical Next Steps
Once a starting point has been selected:
Define the problem precisely.
Make sure everyone understands what is being improved.
Document the baseline.
Know where performance stands today.
Define success.
Establish measurable targets.
Limit the scope.
Choose a specific department, process, dataset, location, or employee group.
Assign an owner.
Make one person accountable for coordinating the pilot.
Identify the risks.
Determine what could go wrong and how those risks will be managed.
Keep humans involved.
Especially when consequences matter.
Train participants.
Do not assume employees will automatically understand the system.
Collect quantitative and qualitative evidence.
Measure performance and listen to employees.
Establish an evaluation point.
Decide when the organization will review results.
Then make a decision:
Scale. Modify. Pause. Stop.
That is how a pilot becomes organizational learning.
Start Small Does Not Mean Think Small
The phrase start small is sometimes interpreted as a lack of ambition.
It should not be.
Starting small is how organizations learn without placing unnecessary resources, employees, customers, or operations at risk.
A small forecasting pilot can become a company-wide decision-support capability.
A simple knowledge-search tool can become an organizational knowledge platform.
A small customer-retention experiment can become a new way of managing customer relationships.
A workflow that saves one department five hours per week can eventually save thousands of hours across the organization.
The long-term vision can be large.
The first step does not need to be.
In fact, the organizations that eventually build the strongest AI capabilities may be the ones disciplined enough to learn before they scale.
Because the objective of the first AI project is not to prove that the organization has mastered artificial intelligence.
It is to prove that the organization can use AI to make something meaningfully better.
Then do it again.
And again.
Each successful cycle creates more knowledge.
More confidence.
More capability.
And eventually, greater organizational advantage.
Think strategically.
Start deliberately.
Prove value.
Then scale what works.