Don't Throw the Structure Out with the Bathwater: Jill Wiggins on AI at CNH
Jill Wiggins shares a decade of AI lessons at CNH: the work behind Watson, why structured data still matters, what dealer journey maps reveal, and how to make automation useful for the people doing the work.
In 2016, Jill Wiggins was asked to predict the future of technical publications for an AEM audience. She went away, had a big think, and came back with a forecast: natural language AI was coming, but it would be a librarian, never a technician.
It would find you the book. You would still have to find the answer.
Ten years later, she's happy to admit she was wrong.
I appreciate that. Especially in technology, where some people would rather rename their prediction than admit it didn't quite work out.
Jill has spent 19 years at CNH, much of that in technical publications. Her work now includes technology development, strategic technology adoption, and responsibility for the learning ecosystem. She has been doing the difficult work of making information useful since long before every software product suddenly needed an AI button.
She's also a friend, a fellow AEM committee member, and somebody who has helped push my career in a good direction. This conversation was a chance to talk about what she's learned, what she's excited about, and what we probably shouldn't lose while we're busy upgrading everything.
An English literature major walks into heavy equipment
Jill didn't start out planning a career in agricultural and construction equipment. She studied English literature and thought she might become a lawyer.
Then, early in her time at CNH as an on-site contractor, she was given an opportunity to join a safety committee. Part of her introduction was a trip to an AEM conference in Pittsburgh. It was close enough to drive.
That was around 2008. It turned into a lot more than a training trip.
Through AEM, Jill discovered careers within manufacturing she hadn't known existed. She found people to learn from, opportunities to volunteer, and room to develop leadership skills that weren't always available through her day job.
In 2024, she became the first woman to chair the conference in its 33-year history, according to CNH's announcement.
That's one of the reasons I value these industry organizations. Yes, there are presentations. Yes, there are committees. Occasionally there is a meeting about another meeting, because apparently we cannot help ourselves.
But there are also relationships that change the direction of your career. Jill is one of those people for me.
“We need AI” still isn't a project plan
We got into the same question I keep coming back to with customers: what are you actually trying to improve?
Jill's approach starts with the person using the system. Where are they getting stuck? What takes too long? What makes an already difficult job harder?
She described work her team did after a roadmap engagement I had done with CNH. Working with a user-experience colleague, they mapped the training journey across the dealer experience, held focus groups, and listened to dealers describe the pain points. Then they did the same thing internally.
They are still working through what they learned.
I love that detail. The value of a roadmap isn't that you finished the workshop and now have a very impressive document. The value is that it helps you decide what to do next.
Sometimes the next step is an agent. Sometimes it's a better connection between systems. Sometimes it's fixing a process that nobody has stopped to question in years.
You have to understand the problem well enough to tell the difference.
Jill described a similar discipline in CNH's Copilot rollout. Selected employee groups tried it, met with Microsoft about every two weeks, and discussed what worked and what didn't. She recalled that process running for at least six months before broader adoption.
The message she appreciated was about helping employees get better results and making their work easier. That's a much more useful starting point than handing everyone a new tool and waiting for productivity to happen.
Nobody became a writer to copy and paste
One part of this conversation got both of us going: the amount of repetitive work still hiding inside technical documentation.
A specification changes. A standards reference needs updating. The same information appears in multiple places. Somebody has to find it, change it, and make sure nothing was missed.
And then do it again.
Jill made a point that deserves more attention: technical writers are still writers.
They care about making something understandable. Choosing the right term. Using active voice. Getting the reading level right. Explaining a complicated task in a way the person doing it can actually follow.
The copy-and-paste marathon takes time away from that.
She described earlier work using XML components to manage common information, including units of measure, standards references, fluids, and lubricants. Managing those pieces centrally helped with consistency, localization, and keeping information current.
That work didn't become irrelevant when generative AI arrived. It gives the next tool something better to work with.
We talked about the potential for agents to handle more of the repetitive update process, with a technical writer reviewing the changes and applying the organization's terminology and judgment. Particularly with safety and compliance content, getting the words into the document is only part of the job.
But I also pushed on something that bothers me about how we describe human oversight.
If the result of automation is that somebody spends all day checking boxes behind a computer, have we actually improved their work?
A human in the loop needs a meaningful role. The ability to question an output, understand the context, and change the decision. Otherwise, we may have replaced one boring task with another and given it a much better marketing name.
Watson wasn't wasted time
Jill's AI experience goes back to that 2016 AEM presentation and the work that followed with Watson.
This was not a matter of uploading a folder and asking a few questions. She described two years of effort to get the system live, including people populating spreadsheets with intents, entities, and synonyms.
A lot of deliberate work went into teaching the system what people meant and how the information connected.
And it worked.
Jill said the team achieved its goal, and she described the earlier system's results as comparable to what their newer version was doing. That's her assessment from the work, not a claim that every older AI system performs like every newer one.
The point that interested me was how much knowledge the team built along the way.
It's easy to see an older platform and focus on what you'd like to replace. It's harder, and more valuable, to ask which parts of the implementation already solved a problem you still have.
The technology can change. Your understanding of the customer, the terminology, and the relationships in your information should come with you.
Please bring the structure with the text
This was the heart of the conversation.
Jill's advice was direct: don't just import the text. Import the structure.
Product hierarchies, codes, classifications, and managed components exist because somebody spent time thinking about how the information relates. Those relationships help a system understand which pieces belong together.
For a simple example, imagine two procedures with nearly identical wording that apply to different configurations of a machine. The words matter. So does knowing which configuration each procedure belongs to.
That's the kind of context you risk losing when you treat everything as interchangeable text.
Jill described encountering the argument that a model doesn't need the existing structure. Her response was that, in her experience, making use of it could help produce better results faster.
I agree with her instinct here. The question is bigger than whether today's tool can answer today's question without a particular field.
What happens when the next use case needs it? Or another team still relies on it? Or somebody asks a question six months from now that wasn't part of the original project?
You don't have to send every piece of information into every model request. You do need to understand what you're removing before you remove it.
The fact that we don't need something for this task does not mean nobody needs it.
Those two reports might not be the same report
Jill gave a practical example from her team's move from Qlik to Power BI for some learning records.
Because the migration wasn't urgent, the team had time to listen. They spent the summer talking with stakeholders about their KPIs, data, and reporting.
That surfaced a problem that's easy to miss: two reports can look similar while tracking something in slightly different ways for different reasons.
Before combining them, you have to understand the formulas, the underlying structure, and what the people using them are trying to measure.
Otherwise, you can make everything look cleaner while quietly removing something important.
Jill's concern was discovering six months later that a critical KPI hadn't been tracked, especially if the missing history couldn't be recovered.
That is a very expensive way to find out the “duplicate” wasn't a duplicate.
This is why I like assessment work so much. You get to slow down long enough to ask why something exists. Sometimes the answer is that nobody needs it anymore. Sometimes the answer changes your entire implementation plan.
AI doesn't remove the need for that conversation. You still need to know what's in your data, what it can tell you, and what it can't.
The dealer doesn't need to care about your orchestrator
Jill also described CNH's work on an agentic technical assistant, including orchestration and an iterative development approach. She sees potential for information across parts, service, warranty, and learning to become more connected.
That opens up some interesting questions. What could a person accomplish if finding the right information didn't depend on knowing which system held it, or which colleague knew where to look?
But the detail that stayed with me came from a company town hall.
Jill recalled hearing three dealers say CNH had become significantly easier to do business with than it had been three years earlier.
She didn't present that as proof that one AI tool had caused the improvement. It was feedback about the broader experience, and she was clearly proud to hear it.
That's the outcome to pay attention to.
I can happily talk about agents and orchestration all afternoon. Most customers would prefer to finish the task and get on with their day. Fair enough.
You can like technology and still be tired
We also talked about change fatigue.
Jill was open about the uncertainty. A few years ago, she felt she had a clearer picture of where things were heading. Now, the possibilities are expanding faster than anyone can comfortably sort through them.
I understand that, even as somebody who builds this stuff for work and then goes home and builds more of it for fun.
Apparently I have chosen a hobby with the same support requirements as my job.
Jill recalled a point from her CEO about how the skills he began his career with had become obsolete without making him obsolete as a person.
That distinction matters. Experience includes judgment, relationships, and the ability to learn. A particular task changing does not erase all of that.
It also doesn't make people's concerns disappear. Adoption takes more than telling everyone to be excited. People need time to understand what is changing and how they fit into it.
Our discussion of privacy came from that same place. Helpful tools still require decisions about access, boundaries, and what information we're willing to hand over.
Sometimes the useful part is just less paperwork
I shared a more personal reason I care about this technology.
My father has Parkinson's and is a veteran. Trying to navigate benefits and paperwork while helping him has been exhausting. I've used agents to help with repetitive forms and follow-up, and to keep records I could go back and validate.
That didn't fix the system. It made some of the work more manageable.
Those are the examples that make this conversation real for me. Giving somebody time back when they're already stretched thin matters.
Jill connected with that side of it too. We talked about the potential to reduce barriers for people and small organizations that don't have a staff available to work through every form.
Useful automation can give people more capacity for things they already care about. That's a goal I can get behind.
Tip of the Cap
Jill's Tip of the Cap went to YWCA York in Pennsylvania. With our conversation taking place during Domestic Violence Awareness Month, she recognized its work supporting people who need safety and help.
It was a reminder that the people behind these job titles have lives and communities that matter well beyond the next technology project.
And my tip of the cap goes back to Jill. For the conversation, the friendship, and the willingness to look at something she once predicted and say she learned something different.
I'm excited about what agents can do. I also think the people who understand the work deserve a much bigger role in deciding how we use them.
Before you replace the system, talk to the people who know why it was built that way.
And before you throw out the structure... make sure you know what it's holding together.
Sources
This article draws primarily on my Hat in the Loop conversation with Jill Wiggins. Descriptions of CNH's internal projects and rollout experience reflect what Jill shared in that interview.
