I love customers — listening to their stories, answering their questions and helping them succeed. It wasn't always that way. Here’s how I became a customer superfan.
Confessions From the Phone Room
When I was in high school, I worked weekends in the classified ads phone room of the local newspaper. We would take incoming calls, closely monitored by our supervisor, from people interested in placing ads. Our customer engagement tools were a PBX phone system, a typewriter and a cheery disposition.
Early PBX technology could be very unreliable. There were lost calls and disconnects. Though, oddly, those things seemed to happen most often during customer complaint calls.
As a phone room worker, I made commission based on the number of ads I captured, so it was a disappointment when an incoming call was a complaint instead of a new ad placement. Indeed, the last thing any one of us in the phone room wanted to hear after our greeting was “I have a problem” or even “I have a question.” We were simply not interested.
And if customers wanted to change ad copy after we had captured it (in triplicate, with special carbonless order forms that did not respond well to edits), we mentally placed them on the bad customer list.
We were clearly limited by the tools we used, but we were also singularly focused on speed, because working faster meant bigger commissions. I was to later learn that speed was important for another reason — to better serve the customer.
Related Article: The Digital Experience Starts With Customer-Centric Design
Surviving a Hackathon Fail
In college, I learned to program. At the time, it was part of my theoretical mathematics curriculum. In a class hackathon exercise, we were challenged to code in a language called Lisp, and the winner would be the one who solved the problem the fastest with the fewest lines of code. There were some elegant and creative solutions produced that day. I came in dead last.
I realized that the exercise was too theoretical for me — if I couldn’t put a face on a problem, I couldn’t manage to care about solving it. Full disclosure: It is also highly likely that as a programmer I would make a great business analyst.
This suspicion proved to be true when I began programming a few years later for my first customer, a financial analyst for GE’s large steam turbine unit. I found myself fascinated by how my customer’s business operated, and by his role in the business.
At the time, one of the technologies I used was called a 4GL report generator, a system whose claim to fame was its ability to produce results quickly. It did just that, but what was most interesting was the division of time it engendered. I would spend 80 percent of my time in discussions with my customer to understand the business problem he was trying to solve and just 20 percent “coding” the solution. When I delivered the solution, I felt pride in the impact it would have on my customer’s business.
I realized that I had genuinely begun to care about my customer.
Related Article: Customer-Centric Companies Sweat the Details
Adopting a Customer Worldview
That interest in the customer stayed with me throughout my career. While I moved quickly from programming to management, and eventually to marketing, I never forgot my early customer experiences — both bad and good. Over time, the good memories prevailed, and my interest expanded to how technology could help my customers’ businesses compete in their industries.
My worldview was complete — and it began and ended with the customer.
Fortunately, the technology for delivering solutions to customers improved over the years, and that helped to fuel my customer worldview.
Now we are fortunate to have low-code application development platforms. These platforms enable designers to quickly and intuitively take an idea and turn it into a new business application.
Ideas are expressed visually as drawings, and the platforms translate the drawings into software. Consequently, the business intention of an idea is captured in an application more quickly than it would be with traditional methods, because we don’t have to code the application line by line. And because low-code applications are essentially written by the translation layer of the low-code platform, the richness and quality of the application rests on the sophistication of the translation layer.
It is finally possible to get the speed I sought so long ago in the phone room and the customer business impact I learned to love during my early programming days. And because the best low-code platforms are agile, they easily allow for changes as the business changes.
Just don’t ask me for too many changes, or you might get placed on my bad customer list.
Learn how you can join our contributor community.