I learned something important recently, just in time for the company’s twentieth anniversary.
I was listening to a recorded customer interview regarding a case study. The customer, a federal law enforcement agency (which of course we can’t identify), was describing how they sent print jobs from their mainframe to our RPM Remote Print Manager® (RPM), which converted the print jobs to PDFs and routed the documents to users in various ways.
The customer referred to RPM as a “virtual printer.” However, since 1995 I’d been calling RPM a “print server” because that’s how it is implemented - as a print server running on Windows platforms. On the recording, our interviewer would call RPM a print server; nonetheless, the customer would say “yeah, a virtual printer.” Not to correct the interviewer, of course, but to clarify.
After the recording ended, I did a Google search on “define virtual printer” and landed on the Wikipedia page. Reading through the list of virtual printer features, I had a sudden realization: this is how people use our software. For each item in the definition, I could think of customer stories I’d heard or been part of which used RPM exactly for that; for converting print jobs to PDFs, printing to multiple printers, printing and archiving, etc. Regarding that task, printing and archiving, I thought back to a conversation with a document management company. The president and founder told us someone asked them about adding that feature to their product. He estimated it would take a five-figure sum of money to make that product change, or he could recommend our product...an interesting admission to say the least.
The moral of the story: for the company web site, I’ve captured the primary “virtual printer” features with some narratives about how our customers are using RPM in that way. RPM is still a print server, but that’s a detail of its existence. People tend to think of it as a virtual printer, and we’re starting to make that adjustment ourselves.