Last month I was privileged to travel with our partner, SMH Technologies to visit major customers in the Midwest. The SMH group was led by their president, Claudio Stefani. We met with several customers and prospects, addressing questions and presenting the new SMH FlashRunner 2.0. Between meetings there was a lot of travel time where we had a chance to exchange ideas.
For several years IQ has been both a user and distributor of SMH products. We had selected the FlashRunner as our Flash programmer of choice after some experience with alternative sources and a survey study of available competition. We have been consistently pleased with our selection. When we had the opportunity to represent SMH in the Midwest, we jumped at the chance. We have continued to be a user and become familiar and confident in getting the various units to perform well.
As a sales rep for SMH, one of the questions I’ve always had is “Why is the FlashRunner better than the competition?” I had my own answers. IQ develops programs and test fixtures as our core business. We wanted a programmer that we could use in our production test solutions. Even more, we wanted a machine that could address a wide variety of devices from various manufacturers. We wanted a standard user interface so we weren’t continually spending time learning a new machine. We wanted a powerful unit that could do more than just load firmware. Because we had selected the FlashRunner I knew there were reasons why the FlashRunner was better. I was surprised by Claudio’s answer when I asked.
I had expected the same marketing spiel that would work for almost any sales scenario. Stuff about the company, the people, quality and all that jazz. Claudio started with a statement that “all device programmers can program the target device”. “You could even take development system tools and program a device. Programming isn’t the issue. The issue is programming in a production environment.” He went on saying that what is important is programming in an environment where a few minutes of downtime might cost more than the programmer. Reliability is the issue. Not just hardware that doesn’t fail, but an entire process that doesn’t fail. This requires a real tool, a tool designed from the ground up to be a production programmer. It requires a process that has the flexibility to do a wide variety of tasks like programming variable data, skipping erase if the device is blank and running a device specific routine when triggered either by command or a pulse.
Still, Claudio was just warming up and his passion was marvelous. The process has to include a means of setting up the programming task that is both flexible and useable. It has to include tools for analyzing errors and generating reports. And in spite of all the diversity in device architectures the process has to have a consistent look and feel so that the user can quickly bring up the next project. And before he launched into the value of the team he had assembled to handle sales, tech support and development he talked about the hardware and the need to build in robust well protected circuits. I remembered then that although we have sold dozens of FlashRunners that are used daily, field returns are rare. By the time Claudio had finished, I was feeling a sense of pride. I was proud to be on this team. I had listened and learned a lesson from a master.
You can imagine my reaction when a week ago one of my competitors was offering a regular customer a programming solution based on a JTAG development tool and said “no, it’s not a FlashRunner, but it does everything a FlashRunner does.”