SM: What was the problem the digital media companies were facing that you wanted to solve?
MM: I knew it was a problem in application layer networking, which was something I had always had an interest in. I liked the theoretical underpinnings of it. I could see there was a layer which was unsolved. They needed to move their data. They were not changing network drivers OS or putting in new boxes. They needed a software layer that would allow transfer of data between sites over distances.
SM: Was the problem large file transfer?
MM: At that point and time, all of the applications I saw it used were large data files. Media companies had large video files they needed to move. As I thought about it more, the solution began to clarify. Nothing crystallized immediately. I took that inclination and started on a path that was more focused on workflow to address this. I thought the transport existed; I had been through companies that claimed they had solutions for this. I also thought there were open source ways to address this with UDP transports, peer-to-peer streams, and parallel stream transports.
In my mind, the technical solution was solved and the problem was in the upper layer of the workflow. I did a project where I built a small software application and took it to NAB in a science fair/interoperability demo. I asked the people if I could show it and was able to do so. I used it as a marketing exercise. It became a little prototype that I could show. I found out that this file transfer problem was affecting more companies in the industry. I went around the show and talked to a bunch of people about their opinions. They did not know who I was.
A second event occurred which reinforced my idea. A salesperson who was very successful in our prior company came to me and said, “You know, we really needed to have a software-based transport that would allow us to move large files that have these characteristics”, and he put it in salesman lingo. This was all reinforcing and validating my concept. I do not feel like I initiated any of this. It all lined up. That I decided to do it was the function of my liking entrepreneurship, having an epiphany moment, and having a strong desire to not work for someone else again. I could not psychologically go work for someone else again. I know it sounds crazy, but it is the absolute truth.
SM: Necessity is the mother of all inventions.
MM: I went along this path for about four months. This started in November, and NAB was in April. I came back and talked to Serban. He is my co-founding partner, my best friend, my engineering mentor and the person I knew could answer all of these questions. I told him the situation, and I described the shared problem and the gap all companies faced. I felt we needed to look at the fundamental problem and see if it was solved. I was still not working. Everybody who knew me thought I was nuts because I had no employment and I was not doing anything other than pursuing this.
SM: How where you financing all of this?
MM: I lived off savings; I lived off very little for a year. My dad kicked in $20,000.
SM: In early-stage startups $20,000 is very useful.
MM: It sure was! That was all I needed for this type of thing. I then did an independent study of what Serban and I thought were the ways of solving this problem. I evaluated what was available from other companies and what was available via open source. The deeper we looked, the more we found there was nothing which solved the underlying transport problem at the technology level, and that was the piece we thought had been solved. We had been brainwashed as engineers that there were competing forms of technology which addressed the issue.
We analyzed everything and set out a certain set of design criteria that we wanted the transport to be able to do, and it did not measure up. I then started to look at the specifics as to why, and then we set up a set of experiments that looked at network delay and packet loss. This was all done out of my house, completely in the background without any structure. I was doing it, and Serban helped me structure it.
By the time we were part way through this it was clear to me that we should simply focus on this problem. We found the best open source incarnation of what we wanted to do, found its weaknesses, and that became the base. The specific weakness that it had in terms of dealing with delay and packet loss was an unsolved problem.
This segment is part 4 in the series : From Laid-off Engineer To Successful Startup CEO: Michelle Munson of Aspera
1 2 3 4 5 6 7