When I read about new technologies, I often think of the movie “Field of Dreams.” The protagonist builds a baseball field in the middle of a corn field because he hears a voice. “If you build it, they will come.” In the movie’s case, “they” are ghostly baseball players. For technology companies, “they” are businesses or consumers.
I’m referring to what’s often called “solutions looking for a problem.” Technology companies have been pursuing this concept for some time. I remember going to data conferences 10 years ago, attending presentations about blockchain. The presenters raved about blockchain as a “distributed ledger.” And how smart contracts were going to revolutionize … well, something. But actual use cases, outside of Bitcoin and cryptocurrency, were scant.
Today’s Big Tech GenAI applications come with a similar story. GenAI will change the world and revolutionize everything. Tech firms proclaim foundational models like ChatGPT as the “be all/end all.” They tell potential customers to try doing anything with these products. Or just ask the chatbots.
I am unmoved by these sales pitches. I have been pondering why, and looking back at my relationship with technology.
My first business job was at The Travelers. It was 1986. Dana Carvey, Kevin Nealon, and the late, great Jan Hooks and Phil Hartman were about to join SNL. Desmond Tutu became the first black bishop of South Africa. The Iran-Contra affair made the headlines. And the Mets beat the Red Sox in seven games. I lived outside of Hartford, Conn., then and actually cheered for Boston. A fruitless endeavor. (I switched my loyalties to the Yankees as soon as I began working in NYC in 1998 – a rewarding decision.)
Back to Travelers. The mammoth insurance company had a huge data processing department. Computer programmers automated many business processes. But my department, Group Contract, had nigh a computer in sight. We assembled group insurance policies and certificates (“certlets”) from paper forms. We selected forms based on the customer’s benefit plan, their state of incorporation, and other parameters.
The forms themselves had checkboxes for us to select which paragraphs applied. We filled in blanks with the customer’s name, the plan deductibles and coinsurance, and so on. I worked on a team dedicated to large customers with unique plans. That meant heavy editing and handwriting custom language on strips of paper we taped on to the forms. Yes, we didn’t even have a typewriter!
Once finished, we sent these thick, messy hardcopies off to the Travelers Print Center. The Print Center did have some degree of automation. If you were updating an existing certlet, you could mark up the booklet instead of pulling new forms. The Print Center could create a copy of the original, update it, and send you a proof back the next day.
So that was life in the trenches of the Contract Department. But change was coming. One day PCs appeared on our desks! These were Microsoft DOS machines with huge monitors. I remember that at first, we had nothing we could do with them – no software, no email. So, I entertained myself by learning to change the menus and execute basic DOS commands.
The leadership of Contract had a problem to solve. This manual process was cumbersome and slow. The Legal team, which created the base forms, had to make sure updates got to the right stacks on the right shelves. Otherwise, contract analysts like me might pick the wrong forms. And with our largest customers, those handwritten flaps grew longer. Sometimes they extended from my desk to the floor.
I wasn’t part of the team that developed the solution. Looking back, I understand their approach – automate the existing process. The developers built a LAN-based application, the Contract Analyst Workstation (CAW — I even remember the acronym!). Then they integrated the CAW with a desktop publishing application, Ventura. Legal created each form in Ventura, saving them as separate files. Contract analysts like me would use the CAW to select the base forms needed. Click a button, and the CAW concatenated the files which we then edited in Ventura. Relevant instructions would pop up as we worked through the editing process.
And no more carrying a 100-page hardcopy with flaps blowing in the wind over to the Print Center! Instead, we’d send the final version electronically. Printed copies shipped out the next day!
I had picked up computers instinctively (thanks to my musical background, I am sure). Soon I became the department’s CAW expert, responsible for gathering requirements for and testing new features. I worked closely with the technology team, always based on “what problem do we want to save next?” Never on “hey, there’s this cool new software — what can it do for us?”
Flash forward to the early ’90s, when Travelers and MetLife made a deal. They each spun off group insurance divisions, merging them and creating a new company. Something called “MetraHealth.” “Met” plus “Tra.” Get it? I’m sure a consulting firm made a princely fee coming up with that name.
MetLife had its own version of the CAW. Well, three such systems. They were much more decentralized technologically than us.
Senior management gave me the role of working with each of the contract teams to decide which existing system we’d go forward with. But comparing these systems without understanding each group’s processes, each group’s requirements, didn’t make sense to me.
I remember holding requirements meetings. Everyone would come into the room anxious to see the systems the other teams were using. And I would say, “Let’s start with requirements.” Again. And again. Eventually people started talking about what they did, how they did it, their current pain points, and what they wanted.
With this information, I built a case for a new system. All the existing systems, including my beloved CAW, were old and limited. And they had all been designed to automate existing processes more or less verbatim. I believed this time we would need to revamp the process itself.
And that’s what we did. We decided that instead of managing hundreds of separate baseforms, we could use conditional text instead. And to manage documents efficiently across the country, we’d need true document management. We chose new software to deliver the new process.
As I look back now on what I learned from the first decade of my business career, I reflect that I became technology-oriented in a business role. The idea of technology for its own sake never occurred to me.
Some years later, I took a role at Merrill Lynch and for the first time worked in a technology department. I had a business analyst/project management role. This was not too different from what I had done before. I found myself in unfamiliar territory. My new team of very sharp developers and engineers spent what seemed to me a good chunk of their time trying this or that new technology. When I asked what business team they were working with, they often replied with the answer “None …yet.”
What I learned this meant was that the technology teams would decide on which technologies were the best at doing this or that. Then they would show the winner to various business teams and ask the business to think about how they could use the software. Sometimes, business happened to have a need the hot new software met. But other times, the businesspeople would be so impressed by the new toy that they’d demand its implementation ASAP … and then not use it at all.
Since those early days at Merrill Lynch, I’ve spent more time on the business side than the tech side. But throughout, the tendency for new technology to be a solution looking for a problem has persisted. With AI, it’s become omnipresent. Take foundational large language models (LLMs) like Open AI’s ChatGPT. The sales pitch is that business can apply their content generation capabilities to any use case. They are truly solutions looking for problems.
Again, this can work well if a businessperson happens to have a problem that a GenAI tool can solve. But there’s a large degree of luck involved. And one of the dangers of GenAI is that it presents well. So convincing is its human-like output that a person might think it solves a problem when in fact it does not.
All the more reason when dealing with AI, you need to start with a clear understanding of the problem to solve. You need to decide what your target state looks like. And you need to define your requirements for solving the problem and getting to that target state.
Most of all, to the extent possible, you need to explore solutions without preconceptions. I thought of this when I read about Reid Hoffman and his new AI startup Manas AI. This is using AI to “accelerate the drug discovery process, starting with new treatments for aggressive cancers.”
I would love Manas AI to make progress. Three of my friends, all great people, died in the last several months from cancer. They were all around my age.
But I wonder: Will Manas AI prove that an AI-focused company can achieve treatment breakthroughs? Or will we learn that the millions of dollars invested into this startup might have been spent better? By giving the money to researchers whose goal is to advance treatment of cancer by whatever means necessary? I’m sure AI can be part of the solution. But I fear this could be another case of jumping to a solution before defining the problem.
I hope I’m wrong. Sincerely. But I don’t plan to change my approach to technology. It’s a tool. Never an end in itself.
