Hemant Shah recalls founding RMS from his apartment, shipping the first product on floppy disks written in Fortran 77, and running improvised conference calls to seem professional while the company nearly ran out of money. Early customer work and failed experiments taught the Stanford team what earthquake risk modeling could actually sell.
Chapters
But the early days of RMS were pretty seat-of-the-pants. The first office that we had was my apartment, and we used to play some games with our early customers, who hopefully aren't watching right now, where when we get phone calls to my apartment that involved any sort of technical challenge, we'd have this system set up where I would have a phone where I could have two lines, page my co-founder Weimin Dong, who was the brains of the operation, conference call him in and patch him into the client to create the impression that we had a proper firm that could answer their questions. And it was this kind of craziness. Another kind of example of the early chaos and improvisation was we had an early prospect, who wanted to take a look at our software. They were domiciled in the US East Coast and we didn't have enough money to make the trip over to the East Coast to set up shop and give them a proper extended workshop and demo. So being very naive, we said, well, tell you what, if you want to take a look at our software, why don't you advance us some money so we can fly out to visit you, run the workshop, and if you decide to buy the software, we'll credit it back against the purchase price. So it's a lot of crazy stuff like that. At one point we basically ran out of money and one of our early colleagues, another Stanford grad, turned up for work and I had to inform him that we really couldn't pay him very much anymore because we're running out of money, but he could move into my apartment free of charge in order to provide him the ability to still work at the company. The early days were wonderful for a lot of reasons, not the least being the great team. I'd say of the first 25 people, I'm going to call out a couple of my early colleagues who are here in the audience today, I think about 80% of us of the first 25 people were all Stanford grads. They were either friends of mine from the class of '88 or '89, they were friends of friends who also were Stanford grads, they were part of my father's network of grad students, postdocs, research associates. So there's a real kind of Stanford ethos, camaraderie, and sense of shared mission that got us through a lot of those crazy days. We used to pull lots of all-nighters like every startup does, and we used to have staff meetings. The big choice of whether we have the staff meeting at the Stanford Pub, Rich, remember, or 42nd Street. I don't know if any of you remember 42nd Street, which was a great— bar in downtown Palo Alto where we used to have some of our staff meetings. Now when we first got started, we did have a version 1 of our product. This is what it looked like. It shipped on these 17.5.25 floppy diskettes coded in Fortran 77, but we understood even back then, we had the intuition to recognize that this this is really a proof of concept. And what we needed to do in these early days was experiment and engage in actual work with real customers to really understand what was the product that we could deliver that would really solve concrete use cases and add concrete business value. So in the early days, what we set out to do was a lot of experimentation. Rather than saying we had our V1 product, now we're going to take it to market, We spent a lot of time essentially even though we knew very clearly that we were a software company, a lot of the early engagements were essentially consulting projects, signing up customer by customer on the concept that an earthquake risk model could add value, but really engaging with them the consultative work to figure out how this really could be made useful to a specific business problem. We spent countless hours and days holed up with our customers, understanding how they did business, understanding their vernacular, what kind of data did they capture, how did they make an underwriting decision, how did an insurance loss control engineer go into the field to collect data about a piece of property to make a recommendation to the insurance underwriter, how could we deliver a piece of software that might facilitate that decision, and so on and so forth. So it was a period of great experimentation to really learn the use cases of our customers, get paid for doing so in order to get to a place where we could say that we understood what the product strategy needed to be. Now some of this experimentation got a bit crazy. One of the more wild experiments that we did, because you get distracted when you're 23, 24 years old, is that we thought, how— what if we constructed, offered a product which was an earthquake report that we could sell to homeowners in Palo Alto in order to help them as consumers assess their risk to earthquake damage. And we got off on this crazy tangent where we were constructing consumer brochures, buying mailing lists, mailing out brochures, collecting information by fax about homeowners' homes, running reports— it's like the old days of e-commerce when you order the sneakers, somebody goes, runs out, buys a pair of tennis shoes and ships it to you, we would get the fax in, we would type it into our computer, we compile a report and send it and charge $100. A complete disaster and certainly something that we learned the hard way not to build a business-to-consumer business around our earthquake risk analytics. But a lot of experimentation is learning not only what does work, what doesn't work.
