Ep. #24, Enterprise Analytics with John Whaley of UnifyID

Grant Miller: All right, John. Thanks so much for joining.

John Whaley: Yeah. Thanks for having me.

Grant: Great. Let's just jump right in. Tell us a little bit about your background and how you got into enterprise software.

John: Let's see, I did my undergrad at MIT. I did my undergrad and my masters there, and then I worked at IBM Research for a while on compilers like Java compilers.

This is back in the late 90s to 2000s. Then I started my PHD at Stanford, and then at Stanford that's where I really got into security.

I was always into security before that, just in terms of being very interested in security and hacking.

I would participate in various, like capture the flag, and these type of events and stuff.

But that's where I really got into security, and then through--

The biggest area of need in security is really on the enterprise side. Individuals don't really think that much about their own security, but for enterprises that's a real issue and that's something that costs them a lot of money.

So that's how I got into Enterprise, I was doing my PHD there.

We had a research project that we then spun out into a company called Moka5, and that was back in 2005, I worked on that for ten years and that eventually got acquired.

Then I left there and started a new company, UnifyID, which is where I am currently.

Grant: Cool, OK. You studied computer science in undergrad, and then you said you worked about a year at IBM?

John: Yeah, I did some summer internships and then I worked about a year there at IBM Research.

This was IBM Research, so it was very research-focused.

That's really-- The community that I came from was really this academia research, we would publish papers and do these type of things.

That's where my original background is from, and then it was really when--

After starting the company back in 2005 what had happened was that I was originally planning to be a professor and go into academia.

I had some interviews and I didn't get the faculty jobs that I was really going after, so that's where I took a step back and said "What's really important to me?"

It was really all about impact, and then I had an opportunity at that point to help start a company.

I thought, "That's a cool opportunity," and I decided to jump on in and take it. I haven't looked back since then.

I did go back to Stanford for a bit to become a lecturer, and since then I've just been very much in enterprise software.

Grant: Cool, OK. You're at Stanford. You said you worked on some compiler stuff at IBM, so not really in the security context yet.

Then you went to Stanford, and what triggered your interest in security while you're at Stanford?

John: I was always generally interested in security, not so much in the enterprise context, but just in terms of security of systems, because I was very much into systems.

Everything, networking, operating systems, etc. Much of my research area was in-- I was doing static analysis, which is basically you analyze code to help find bugs.

One of the areas you also use it for is for to find security holes, things like sequel injection attacks or buffer overruns, or these other type of things and bugs.

Which are very important, and were becoming increasingly important to be able to catch, because as we became more and more reliant on these software systems the cost of these bugs and the potential impact of having a security hole was really growing.

I think I was interested in it from a technical side, and then the top use case was around doing this type of static analysis to help find these type of security holes in software.

So, that's really how I got into that area. My first company, Moka5, this is basically based on a research project at Stanford called the Collective.

The basic idea is that we wanted to build this next generation computing utility. Rewind back, this was probably in the early 2000s.

I was the go-to IT guy for all of my family and friends and everyone else I knew, it was like "You're doing your PHD in computer science. You can definitely fix my printer."

Grant: "You're a computer person." And you're like, "Oh. Yeah."

John: I myself, I was struggling with "How do I manage desktop windows?"

Things like that, "How do I keep things patched and up to date? Installing software?" All of these things, and it was just a nightmare. So we envisioned this idea of--

Grant: So, you're saying as the IT guy for friends and family, you have 20 folks in your organization that are relying on you to patch their systems and manage everything. That's funny, OK.

John: I would sit down on my parents computer and it was like, "Oh my God, what did you do to this thing?"

Grant: "Why do you have so many Yahoo! toolbars in your Internet Explorer? You can't even see the window."

John: Yeah, so I became the go-to IT guy. This is the basic idea behind that project, was we wanted to make computing more like a utility.

You just turn it on, just like you pick up the phone and you get dial tone. Really make computers work a lot more like consumer electronics work.

You turn it on, it just works. You don't really have to think about patching and updates and these type of things.

The interesting thing is that a lot of ideas from that, like when you look on the mobile landscape, like in terms of the way that the mobile ecosystem has gone.

They've really taken a lot of these ideas and incorporated on the mobile side.

The way we got started on that side was trying to do this for desktop computers. We did it using virtualization, using virtual machines.

Two doors down office was Mendel Rosenblum, who is the founder of VMware, they were doing a lot of VMs for server consolidation, these type of things.

I thought, "OK. Maybe we could use VMs to help solve desktop management." That was really the premise behind it.

Of course, the first time around we made lots and lots of mistakes, in terms of founding the company and in terms of how we approached product, and all of these other things.

But we eventually did find this niche, which was we were riding this wave of "Bring your own device."

It really started with Mac and MacBook Air, when MacBook Air came out that was the hot thing everyone wanted to use.

But then in the enterprises, they are all Windows shops.

The exec would come by and he's like "Here's a MacBook Air. I want to use a MacBook Air."

Then the IT department would say, "That's not-- We're a Windows shop, we're a Microsoft shop.

You can't use this." But they were at such a level that, they weren't asking, they were telling.

It's like, "No. I don't want to be the only sales guy in this group that doesn't have the MacBook Air. I want the Mac Book Air."

The IT departments are then faced with that, and so that's where virtualization came in.

But you also had the security angle there as well, like in terms of "Yes, but how do you keep those things secure?" And everything.

We found a niche there, and we later on found a niche for a similar thing for tablets and phones. Like the iPad and iPhone, these type of things that didn't have all of those enterprise security features but still users wanted to use them.

So in general, we rode this trend from "Bring your own device."

Which now it's very commonplace, at that time we called it "Consumerization of IT," where we took these consumer products and that was really what was driving IT and IT spends.

Through that experience there, I heard a lot about it from our customers and IT departments and CISOs and security professionals around some of the challenges that they had.

It's tension between security and user experience, and I heard this all the time.

Because we made a product that was designed for end user use but it was really an enterprise product.

We had to go and sell to the enterprise, often it would be the security team or the desktop management teams there, b ut end users would touch this product every single day.

That dynamic really informed a lot of the way you think about enterprise security and especially the enterprise user, that enterprise end user and what their experience was.

I have lots of great stories from that time period, in terms of customers that we had interacted with and just jaw-dropping situations where --

Just very creative ways that users would find their way around security protocol.

But one of my one of my favorite stories is also, it's related to the stuff that we're currently doing now with all the authentication.

So we talk with one team at an enterprise company, and they had a set of users that wanted to share an account for VPN access.

They had one account for VPN access, they had instituted mandatory 2FA via physical token, like one of these RSA secure ID tokens.

This was fairly common, this would have probably been about 2010-2011, around that timeframe.

Pretty common for VPN access as a high risk access, it requires 2FA.

But there's a group of users, they just wanted to share an account, so what they did was they set up a webcam that pointed at the physical token so that they could then share their account.

Whoever wanted to log in they could go to this URL, they could see what the current code was, and they could type it in.

That was their low tech solution to getting around the challenge and the friction involved into 2FA.

Grant: Brilliant. You're probably not authenticated.

John: Nope, it's just a random URL. It's more secure than having nothing, but that was probably not what the IT department intended when they said "You need to use 2FA."

The interesting thing is, the realization came that "You can't blame the users in these cases, because you designed-- As IT you designed a system that didn't allow the people to be productive or do what they wanted."

I think people just find a way around it, and it reminds me of how there's so many companies--

It used to be a really big thing where it's like "We're going to put a box in your network, and we're going to have all this DLP, and we're going to be this man in the middle proxy.

We are going to decode all of your traffic and we're going to figure out if people are trying to steal IP or personal information," or these type of things.

Grant: The CASB space?

John: Yeah, exactly. So what do people do?

They get these lockdown machines and they can't even go to YouTube, or they can't even go to these other places.

What they do is they'll get a 4G modem and they just plug it into their computer, and then all of your millions of dollars that you spent securing your perimeter and all this, that all goes out the window because you completely just bypass it by just plugging in a 4G modem into the--

Grant: A MiFi, or whatever.

John: Yeah, a MiFi or whatever. There's just time and time again you see these cases.

Another entertaining case I remember, we were working with Intel who is very privacy conscious.

I mean, very conscious around IP and around leaking of IP. I remember being in, I think it's one of their boardrooms, and overhearing a conversation of one of the executives there.

They had recently allowed iPhones, so for the longest time Intel was a hold out.

They didn't want to allow people to have email on their iPhones because they did not have all the security features of BlackBerry.

To be able to say "It's encrypted," they didn't have all the security features. But there was such a demand from the employee side, from the end users, "No. We want to use iPhones."

So eventually the IT department relented and they said, "OK. We will allow you to have email on the iPhone, but we're going to strip all the attachments.

We'll allow the email through, because the really sensitive stuff is in the attachments. We're going to strip out all the attachments."

So that's what they had implemented, and I'd overheard this call where he's talking to someone and he's like "Could you send over that presentation? Wait a second, I'm on my iPhone. Could you send it to my Gmail account instead?"

Again, just completely bypassing the security protocols.

Again, you can't blame the user in this case because they're not trying to be malicious, they're just trying to be productive.

Grant: So when you were at Moka5, did you have enterprise software chops?

I know you were a co-founder, did your other co-founders, had they been in enterprise software companies or was this the first for everyone?

John: No, first. It was the first for everyone. I mentioned we made a lot of mistakes through that whole experience, and we did a lot of things wrong.

I learned a lot from that experience, but none of us had any enterprise experience.

In fact, when we when we started the company we weren't even thinking around enterprise.

We were thinking about, "This would be a product your cable company would do."

It's the same way that you could call up and say, "I want HBO."

We want to say, "You should be able to call up and say 'I want Photoshop' or 'I want Microsoft Office,' and then it would just be a box that they would give you just like the cable box, and that would be your computer.

They would backup all your data, they would keep track of everything for you on your computer, and then you don't have to worry about installing software."

It was before really software as service became big, and that was the world that we envisioned.

We thought, "Who are the people that are going to want this?"

Clearly, it's telcos and carriers and your cable company, and these type of things, because that's the future.

That's the way you're going to get your computing in the future.

We're very naive, in terms of trying to understand how that market worked, so we quickly realized that although all of the carriers claim that they didn't want to be dumb pipes, they ultimately weren't really innovating--

They weren't the innovators in that space and we stumbled upon this use case in enterprise.

It started with these areas, and the big impetus there was around "OK. People are starting to bring Macs into the enterprise, but the enterprises didn't support Mac, but they did have security needs."

So we fell backwards into the enterprise space.

Grant: OK, so you're at Stanford.

You decided to start this with-- Were your co-founders also Stanford folks that you worked with, or how did you know your co-founders?

John: It was basically our research group at Stanford.

It was my advisor and my professor, and then my other co-founders were other people in my research group.

Grant: OK, so you had this founding team and you were all at Stanford, and when you raised some seed money from Khosla or A? What was--?

John: Yeah, I guess it was an A. Technically it was an A.

Grant: It all changed, like every--.

John: It was $3 million dollars. At that time--.

Grant: Today, a normal seed. At that point, a pretty solid A.

John: Yeah, a solid A. We really had no clue.

The only reason I knew Vinod Khosla is because his photo was outside my office, because he was one of the founders of Sun.

I saw him on the Midas list and things like that, and I was like-- Then he invited us to his office and I was like, "That's pretty cool."

I go and talk with him and the next day he basically sent a term sheet that says, "I want to invest in your company." And we're like, "What company? We don't have company."

Grant: Funny.

John: But, it was like "Here's $3 million dollars, go do something cool."

I thought, "That is an awesome opportunity and I'm not going to pass that up." So that's how I got started on that side.

Grant: At that point, you had $3 million bucks and you're like "What we're going to do is give cable companies the ability to deliver software into--"

Was it supposed to be a box that sat in your house? Or was it going to be somebody that they managed remotely?

John: This was before the whole remote execution stuff was really feasible, so this was, again, it was the idea that you would not actually buy your own PC.

You would just rent the PC the same way you do with a cable box, things like that. That's the basic idea.

Then you don't worry about, like they would manage it for you and they would also back it up and they would also hold onto your data.

It would be really sticky, so you wouldn't-- Like, now it's going to be really hard to move over because it's like "They're managing everything for me and they keep track of my data," things like that.

That was the premise of it. Now the interesting thing is that the PC market didn't go that direction.

But if you look, that's very much the way that the phone market went.

Because if you think about, often you don't buy your own phone, you're financing it across because I signed a two year contract, these type of things.

You can call them up and you don't really think that much about updates and downloading software.

You can go to an app store and you can just decide what you want to download. Everything is kept isolated, and these type of things.

That was really our vision around there, we just chose the wrong platform. But that was the basic idea, and of course we had grand visions at the beginning.

That was really the background of how we got started there. Then again, that was not panning out.

These type of organizations that would be able to provide that type of service were not really moving in that direction or interested in that.

At that point, we had a really cool technology, which was "OK. I can run these desktop virtual machines and I can keep--"

Like, it was basically that we have layering and other type of things.

This is all very similar to Docker and the way that these work, but it was for Windows and desktop management.

We had a lot of cool technology around that side, and then we were hunting around looking for "What are we going to do with this?"

Then the Mac and enterprise happened, so that's where we really started to get traction on the enterprise side.

Grant: Then this is when you raised your series B?

John: We raised the series B prior to that, by this time we were at a series C.

Again, we had some missteps along the way.

I think when we raised our B, the story was still like that computing utility, next generation computing utility.

Because we raised three million initially, and that lasted us pretty good.

Maybe the first two and a half, three years I believe. Something like that.

Then I think our B, if I remember correctly, it was around $18 million or something like that.

That was raised on that initial premise, and during that time frame is where we found "OK. Actually, the real opportunity here for this type of capability is in the enterprise."

So then we were riding this wave of the consumerization of IT wave.

Grant: OK, cool. So you raised this B and then during that B is when you realized, "OK. Maybe the move is enterprise, and we need to take this to companies."

Primarily from pool around MacBook Airs, which is amazing, as the key.

If you think about predicting a platform shift, you wouldn't be like "There's going to be this really thin computer that every sales exec is going to want, and that's going to create this nightmare for IT orgs."

But you have this solution and you're able to deliver it. What was the end user experience?

Was it like I was running Windows on a MacBook Air, or what was the--?

John: Yeah, exactly. We partnered with VMware, we leveraged on the MAC and we leveraged their VMware fusion product on Windows, we leveraged their player product.

We built it-- They didn't see any of that, it was just basically that you launch it, you have your enterprise environment, you click "Go."

It brings up either a full screen or a Windows environment, and it had active directory, it had all the corporate--

It was basically your corporate desktop image, but baked into a virtual machine and then wrapped up with all of these policies about "Yes, all the data has to be encrypted.

All the network traffic needs to go through the VPN, and you're not allowed to copy data in and out, and you could remote wipe it" and all of these type of management--

Basically, we put a management interface around it because, again, you're running on a personal device. Who knows?

That's probably the same device that your kids are using, or it may have malware on it, and these type of things. This is the type of stuff that we have to deal with.

Grant: You're installing Popcorn Time on it, that was popular.

John: Yeah. So we got used to this problem of when we talked to an IT department or somebody in security, and they say "No. Clearly we are secure because our policy states that you can never use a personal device, and there are no personal devices allowed on our network."

And then you do a network scan and you point out all these personal devices that they had no clue about that were sitting there on their network, or if you go and survey the users and things like that, you found that no, actually you may have these policies but like if you look at what people are actually doing day to day, it's quite different.

There's always this challenge and tension in terms of talking to these IT departments and these people in security within enterprise around what is actually happening within your enterprise, because many of them really had no clue about what people were actually doing.

If you come from that angle, if you then say "Let's take it as a given that people are going to want to use their own devices to access work things, how could you possibly secure that?"

That's where we started to get "OK. Now we can have a conversation. Now we have a conversation about, 'What other type of stuff that you can do.'

Clearly you want to be able to, before the thing connects we want to be able to make sure that we do a malware scan and make sure that it doesn't have any known malware on it, or scan for keyloggers or these other types of security things.

OK, obviously if it's a personal device I don't have all those controls over it, but we want to make sure that encryption is enforced and we want to make sure that all these things are enforced, and if they're not I want to be able to remote wipe it, just that container."

So we start to have a conversation along those lines of, "OK. Let's talk away about the way that people are actually using IT and technology within your organization, and let's talk about ways that you can support that and not become the "CI-No,"like whose job is to say "No" to everything.

If you want to be an enlightened CIO, you have to talk about technology as a business enabler, like IT as a business enabler.

The more enlightened people are and we're moving in that direction, I think the trend has been certainly in that direction.

Nowadays, like now both with people moving things to cloud and it's no longer about "I need to keep everything within my walls and keep everything secure, and security trumps everything else," now you have a new generation of IT leaders who really see their role in a really different way.

Grant: Was VDI, was that a thing? Was that a category at that time?

John: It was, yeah. That was our main competitor, was VDI.

In the VDI space the basic idea is you take all these desktops and you put them all on a server and you run them on a server so they're easy to manage, because they're just virtual machines on a server.

You can patch them whenever you want, you can scan them, you can do whatever you want.

But every time you wanted to use one of these, you then had to use some type of remote desktop protocol to connect in.

My co-founder, her husband actually was one of the people that was originally working on this product called Sunray, which was back in the early days.

This thing called "Clients" which were these really stripped down machines that didn't have any storage or anything that basically just allowed remote desktop and that was it.

I very much did not subscribe to that model at all, I thought it was a bad user experience and it was just really silly.

But this was a big thing. VMware and Citrix, Microsoft and others, they sold a lot of people servers.

And VDI that was in terms of getting fast storage and everything in the data center, the data center people loved it because it's like, "OK. I'll take desktops too, let's just put that in our data center."

But it was just very impractical from just a latency standpoint.

I see this again, Google now has their online gaming service where it's like "OK, we're going to play games. But in order to install them it's going to be like a remote desktop thing."

I remain very skeptical about these type of things, because it makes so much sense to do things on the edge.

Just in terms of latency and scale and everything, and then reliance on network.

There's a lot of things that make sense to do on the edge, so our most direct competitor was VDI.

We provided an alternative that had all of this centralized management of VDI, but the execution happened on the local device.

So whereas a VDI server, you could maybe get 40 users per server or maybe 50, if you give them a really bad experience you could give them more users per server.

For our solution, we were able to manage 50,000-100,000 users per server because none of the computation actually happened on the server.

It was just doing policies and updates was all managed on the server, but all the execution happened on the endpoint device.

That also meant you could run offline, and there were just too many use cases where it's like "If the only if the only way you can use your computer is you need to have this high quality, low latency network connection," it's like, "What about when you're on an airplane?"

There's just too many cases where you say, "You cannot be productive if you don't have that high bandwidth, low latency network connection."

So that's primarily who we competed against.

Grant: OK, but there was multiple companies in the VDI space, right?

There was virtual desktop infrastructure with a handful companies, to your point. Were you the only company in this--?

I guess VMware, to your point, provided some amount of this functionality, but not any of the management layer. They're like the underlying--?

John: Yeah, so that's the niche that we had and that we ended up with.

Then this was really on the on the laptop and the desktop side, then we saw the advent of iPhones and then iPads as well.

It was most similar type of story, where people wanted to use this but there was no-- In the early days there was not really even MDM or anything like that for those on those mobile platforms.

That's where, in that space, we compete with good technologies or any of the mobile iron or any of these other MDM providers, in terms of being able to provide enterprise management on these platforms.

Grant: So, you then would bring a Windows desktop experience to an iPhone 4?

John: No, by that time we had not-- This was not, like the type of stuff you do on a phone is really different.

You don't want to be pinching and zooming and stuff through a Windows desktop experience.

This is more around people being able to have ready access to information to things like email, contacts, file shares like SharePoint or other sensitive documents, and things like that.

But you don't want people to just be able to download that to their iPad or their iPhone and then go and forward it to whoever, or it's not encrypted, or any of this.

That access was stored within a secure container on that device, like on the iPad or on the iPhone.

Grant: So you delivered it as an app?

John: Yes, this was delivered as an app and then you have seamless access to your corporate resources.

You don't have to hook up a VPN to the whole device, the VPN was based in--

Grant: A single app.

John: Yeah, a single app. You download this app and you then register, and you can then-- The enterprise can say, "OK. Here's the resources, here's the intranet sites that I want them to be able to access, the internal web resources.

Here's a single sign on capability so I know I can sign on to every single thing, here 's document shares, SharePoint, and these type of things."

And then again, you can set all sorts of policies about, "Do they need to authenticate? Are they allowed to print? Are they allowed to open data and copy data into other apps?"

These type of things.

Grant: Interesting. OK, where did it go from there? You raised money, you got this out there, MacBook Airs are all over the place. What's the next chapter?

John: This was an enterprise, very much an enterprise company.

We had a very typical inside sales process there, where we had very long sales cycles.

Especially if you think about how we were doing, some of the things we were doing was the desktop replacement.

There are companies that were saying, "We want to move to this model of the company owns the laptops and you'll get a company versioned laptop, and we'll refresh those every three or four years."

They wanted to move to using a personal device, especially for things like contractors or people working from home, or in certain industries. Oil and gas was big in the legal space, like places where there were certain regulations.

That's where you had the biggest uptick and the biggest interest in terms of those type of verticals.

But it was very-- We had our enterprise sales team and the sales cycles were--

The enterprise sales cycles are already long, but these were even longer because they were often tied to a hardware refresh, so even if we get somebody excited in terms of the rollout it's like as we start we're not going to take people and move them off from their current laptop onto this.

When their laptop ages out, instead of replacing it with another Windows laptop, you'll get the option of choosing a Mac.

There's a lot of different models, they had even BYOD where it's like the people could would even just get the device and own it.

There was also like CYOD, which is they could choose their own device, like they had a menu of stuff so it was still owned by the company but you now had the option to choose a Mac, or other types of hardware as well.

But many of the things we were doing, because they were tied with the hardware refresh cycles these things were really long and it was very lumpy.

It was very, it's like hunting elephants. You go and you were able to deal these big deals, hundreds of thousands or millions of dollars deals.

But they took a long time to close and an even longer time to deploy, so there was a lot of ups and downs.

It was like, "Whether we're going to make this quarter or not is going to depend on whether this PO comes in on March 30th or April 1st."

We continuously had a lot of challenges along those lines, and I think this is true of any enterprise company or any company that is selling into the enterprise, but it was especially true at Moka5 because of the nature of what we're doing.

We were often tied to hardware refresh cycles, which would stretch out things even further.

Grant: It sounds like maybe it wasn't growing as fast as you wanted it to grow, so what was the conclusion there?

John: Eventually, like I mentioned, we had a number of missteps.

We've gone through four CEOs, I believe. This was coming up to close to 10 years, and we had some cool technology.

Earlier on in the company we had some very strong interests around potential acquisition and these type of things.

Again, the board was not interested in that. They were very interested in-- They wanted the big outcome.

They didn't want the 2x or 3x return, they wanted 50x-100x return.

So I believe, I'll have to look back, but I think it was maybe from start to finish, I think we raised around $83 million dollars through the course of the company.

I'm not sure what series we ended up with. But again, we had raised quite a bit of money by that point in time.

Then basically what had happened towards the end was we had some very strong interest, something happened in my personal life on my personal side where I was not able to work after that point.

Then the rest of the exec team at that point was out as well.

Then it was largely a fire sale at that point, and it was not--

It did eventually get picked up and acquired, but it was not the outcome that any of us had been wanting.

Especially thinking around 10 years in.

A lot of this today, we learned a ton of lessons through that whole experience which are very valuable in the next company.

We approach things in a very different way at UnifyID, and it's definitely paid off.

Grant: Yeah. I think it's a great time to talk about , what is UnifyID? What's the backstory? Let's dive into that a little bit as well.

John: UnifyID, we do something called implicit authentication.

We can authenticate users based on passive factors, things about their behavior or about their environment that are unique to them but don't require any conscious user action.

They can just be themselves and there's enough that's unique about them that we can actually use that for authentication in many cases.

This was really driven by, again, experience at Moka5 and seeing all of these cases where if you try to implement security without taking the end user experience into account, then you're going to run into all sorts of problems.

They either won't be adopt it or even worse, people will use it and be miserable.

This was especially true around authentication technologies.

You look at things like, there's passwords and then the predominant method at that point was "We have passwords and we have these password complexity rules, and we also have rules around how you have to change your password every so often and you're not allowed to reuse old passwords," and it's just a lot of frustration on that side.

Especially because people are starting to now get used to interacting with more and more services, so now they have to manage more and more passwords.

There is that, and there is also the view that passwords are not a great solution in the first place.

The whole notion of the password is "I have a secret and I tell you that secret, and that's how you know that it's me."

Of course, that leaves it open to things like phishing.

If they can somehow trick you into entering your password into the wrong place they can figure out what it is, or key logging or screen scraping, or those type of attacks.

It also opens yourself up to "I'll reuse the same passwords on multiple services, and then now if one of them gets breached I may not even know about it, but I still get compromised on that point."

Passwords alone, clearly this was not-- This was not scaling, and it was not working.

But the existing 2FA solutions were not very good.

If you look at things like the physical tokens, like RSA secure ID, which admittedly added a lot of security and are a very secure solution.

This notion that I have to carry something extra around and then I have to type in this code before it expires, things like that.

This was not, if you look at the actual adoption of 2FA or that style of 2FA is very low.

People hated it and they did not want to use it. In some cases, it was mandated and you must use it, so people just dealt with it but nobody liked it.

Then you looked at other, because those things were so inconvenient, those physical tokens, they then moved to soft tokens which is basically an app on your phone that like holds a secret.

Then it's a much the same thing, you can then type in your code based on your app, and there was a realization that "People don't want to carry something extra around, so I'm going to just do this.

I'm going to make a soft token, a software version of the token and do that just on the phone."

The security is quite a bit lower in these cases, especially if your phone is jailbroken or any of these. There's not really great ways to keep those things secure, so you do lose some of the security there but the convenience ends up trumping that.

But then this is silly, if you just think about this idea of "I have my phone in my hand and it's displaying a code and I'm sitting at my computer, and then for some reason I need to type in that code into my keyboard when the two devices are sitting right next to each other."

You're just introducing friction, things should not work this way.

With this realization, at Moka5 one of our big customers was Royal Dutch Shell.

They were very forward thinking, they were thinking around authentication and how to deal with identity. They have a huge, massive organization.

I think they were global one, or at that time they were basically the largest company in the world for some period of time there.

They had a system where everyone used smart cards and pins, like nobody knew what their password was.

They didn't use passwords, they used smart cards and a pin.

If you wanted to authenticate, you plug in your smart card and type in your pin, which is actually a very good solution from a security standpoint.

But then they ran into very practical matters of, "I want to authenticate on my phone, but I can't plug my smartcard into my phone. What am I going to do?"

Again, all of this, it's in this environment that we started to come from the other direction.

It was like, "How far could you go if you don't require the user to do anything?"

Because that's the hard part of security, is actually changing human behavior.

That's the approach that we took.

We talked about VDI, and me and my co-founder went to a security conference where we did this demo, which was attacked basically as an attack against VDI, where what we did is we built this tool that took a wireshark trace of the network traffic between the client and the server for VMware and Citrix and Microsoft.

A set of these type of remote desktop VDI Solutions, and of course they encrypted all the traffic, which is nice, but we didn't look at the content of the packet.

We just looked at the timing between the packets, and then based on that we can determine the timing of the user's keystrokes on the terminal.

Then based on that, we can actually determine what the user was typing.

Because you can think as you're moving your fingers around the keyboard, there's slightly different timings depending on which keys you're touching.

If you combine that with a language model, you can actually build something that can predict what somebody is typing.

So we had this awesome demo where you type something across this encrypted channel, you drop this wireshark trace in this tool, and it say "Here's what I thought you typed."

People are really blown away by this because they had been sold this VDI solution says "Everything is secure. It's all in your data center."

But literally, they know that they just open themselves up to this side channel attack where you could pick up keystroke timings and then figure out what people are typing.

So that's really how we got started on this technology, and this again is a connection back to Stanford to my PHD days.

There was Dan Binay, who's a professor there at Stanford who had done a lot of work on these type of side channel attacks and these type of things, he was very aware of that work.

There was another person there when I was doing my PHD that was looking at something called keystroke dynamics that was looking at how somebody types and then using that for identity verification authentication.

So we began to explore things in these areas as a side project, and it turns out--

Grant: Was this just because you were back at Stanford teaching at that point, or what was it--?

John: I was teaching at that point, but this was-- If you think about the evolution of the company at Moka5, I was a CTO.

Initially there's a lot of technology work, but in the later stage of the company it was much more about sales, sales execution, and getting people deployed.

These type of things. There's less of that core technology at work, and so I was still involved there but this is when I also went back into Stanford and started to teach.

Then I started to do some side projects there as well, and this was one of those side projects that initially it started as a demo that we had put together for-- As a demo of an attack on VDI.

But then one of the challenges that we had of that was actually it would work really well for me, because it was like the system was trained on me, but if somebody else tried it would not work as well because they typed in a different way.

It was in that type of environment, that's where the idea of the genesis of that was born.

We began to look at these, things like keystrokes. What we found is that if you type around three sentences we could then tell pretty accurately whether it's you or not.

Once you've typed around three signs. We looked at trackpad usage and it turns out the way that people scroll on their trackpad is really unique to them.

In terms of what part of the track pad they're touching, what is the arc and the angle and the pressure they're using?

Things like that. There's a lot of promising things there, and then we looked on the phone because we saw a big opportunity on the phone.

There's a wealth of sensors on the phone, and that's really what unlocked it in terms of using that sensor data from the phone.

Things like the accelerometer and gyroscope and your location, and there's other factors.

Each of them individually, they had their own false positives, and you don't always get signals from them.

But if you combined a large number of these together, then you could get something that was very highly accurate, and so that's really how we got started at UnifyID.

Grant: OK, interesting. Again, you had university roots from some work and things you were doing at the university.

John: Yeah, that's right.

Grant: In terms of commercializing any of these projects that come out of a university, is there anything special you're doing or that you're working with the university on?

Or is it all, "Stanford is great about just letting these technologies come out and become companies?"

John: No. When I was at Stanford I was a PHD student and I was doing research under Stanford under these grants.

When I went back and became a lecturer, I was basically a hired gun where they needed somebody to teach some of the classes.

I had a background in that area, so this was again, this was the compilers class. I went back to teach the compilers class because that was really my research area.

The interesting thing is the way that they do it is you are literally as a hired gun, you're there and employed for the quarter.

Then the quarter finishes and I'm no longer employed. Then the next year they employ me again, and then I'm no longer employed.

I was not-- Actually, I think my title was "Visiting lecturer."

I was not really the full time employee of the university at that point, but I still had many of these connections there and talked with many of the people, including Dan Binay for example.

He was an advisor at our first company, Moka5. He's also an advisor here at UnifyID as well.

I was aware of those things and worked on them, but in the case of the stuff we're doing at UnifyID, that was very much a separate side project that we were working on that was informed by those things.

Grant: Got it.

John: But back to your original question around for Moka5, for example, or anything that comes out of a university.

There's a technology licensing office, because any work that you do at Stanford using Stanford resources, it's owned by Stanford.

Because they're paying, they pay for those graduate student stipends and they are providing those resources.

There's a technology licensing office, and this is true at Stanford and Berkeley, and MIT and just about every other school, where if you want to build a company based on something in a university you have to interact with that technology licensing office.

The way the model typically works is, obviously Stanford and others they want these things to get out in the world, but they want them to become something big.

If you think about things like Google, for example, which is based on research at Stanford and then they spun off into a company, and a big company.

Usually the way that they'll do it is they say, "OK. We'll negotiate, we'll give you an exclusive license to the IP that you developed here. In exchange for that, we will get some equity in your company and there'll be some set of escalating payments that'll happen.

Initially, it's going to be really cheap, maybe it's like you pay $1,000 dollars for your exclusive license to all this tech, but then that will start to ramp up over time."

So that's the way that they'll typically setup these type of deals, because they want it to be a win-win.

They want people to go off and spin off companies based on this research, but they want to have a piece of that as well.

I think Stanford has done this very successfully, and they have a very good technology licensing office that negotiates these type of deals.

The university can see the upside there as well, so then often they'll get equity--

The university will get equity in your startup, in the company, and then in exchange for exclusive license.

Now if you don't care about the exclusive license, then they are welcome to go and take that technology and then license it to whomever, but of course they would much rather license it to somebody who was the one who did the work, who is most likely to succeed with it.

That's typically be the people who were initially involved.

Grant: Interesting, OK. So there's also other technologies that anyone can try to get a license.

John: That's right, yeah. If you have something, or if they have something that's commercially viable that was developed as part of the university then that's part of the job of the technology licensing office.

To monetize that in appropriate ways, and part of that is in terms of talking with various companies.

Then this is most common when you have some concrete artifact, like a patent for example.

If you filed a patent based on some of the work you've done at Stanford, then Stanford will then license that patent so you can have those IP protections.

The other very common thing is code, so if you're working on something that's a research project within a university setting and you want to spin that off into a company, you can't go just take that code and start a company.

Because that code, that IP is actually owned by the university, so you have to work out a deal to license that.

Even if you're not using that much of the code or anything like that, many times that's the first initial version is the version that you built at the university using university resources.

In these cases, you do need to license that code from the technology licensing office.

Grant: Interesting. So a lot of that code that's happening there actually isn't open source? It's like--?

John: It can be open source, but then if you want to --

Grant: It hasn't got a license on it. The open source license isn't like, Apache 2, or something.

John: Yeah. This is a case where if you want to have proprietary access to that code, that's one way that people will do it.

You have a university project, you make that open source, then you can go out into industry and you can use that the same way as anyone else could use that, and that's fine.

But if you have started to build proprietary code that you don't want to be open source, or these type of techniques and stuff that were not open source and you want to maintain them to not be open source, then you need to license that from the university.

I think this is also, in particular, this is not a little bit different for undergrads, for example.

If you're undergrad in university, you're not getting support from the university in terms of a research grant or these type of things.

The rules are a little bit different in those type of cases versus if you're a grad student and they are paying you as a research assistant, those type of things.

When you're doing that, ostensibly that IP that you generate is owned by the university in those cases.

Again, they're not evil people, they want this stuff to get out so they want to facilitate that.

They're not going to be difficult in terms of being-- They strive to be really easy to work with and actually encourage people to go out and start companies.

But most commonly, they'll take some slice of equity based on that and then in exchange for that you get the exclusive license.

Grant: Interesting. Any range of equity to take? Is it like 5%, 2%? What is the--?

John: I think it really varies. This is , again, they don't want to have a situation where they are holding your company back in any way.

This is in the single digit percentages is the most typical, I think. It's 1 or 2%, these type of things.

Which I think that, again, they want to be easy to work with but they do want to be able to see some of the upside if one of these things, like Google or others, go and become really successful.

Grant: Yeah, that's cool. I didn't know much about that world, so that's pretty interesting. OK, so back to UnifyID.

You built this little hack to basically prove that VDI is insecure, probably because you're still fighting that war.

Then you realize it has some additional-- Like, that hack has some interesting implications. Is that what happened next?

John: That's right, yeah. Then begin to think just again, this side project that I was working on, just looking at "OK. What are the other sources of--?"

Grant: These signals that you have?

John: That's precisely right, yeah. Look at these other signals, and then put together some-- Machine learning was becoming a thing, and again at that point this was around 2014-2015 timeframe.

I had some background in that, like I had one chapter--

My thesis had something around machine learning and then when I was there at Stanford I had taken a class with Andrew Eng and then he had consulted with me a little bit on some papers and stuff I was writing.

I was familiar with these techniques, and began to apply some of these techniques to this problem.

Then found out "Actually you can go a long way in terms of be able to identify and authenticate the user, like the human being, without requiring them to do any conscious action."

When we thought about "What is the shape of the solution in the future?" We knew it was not going to be passwords.

We knew that it's not going to be something extra that you have to carry around, and honestly anything that required the user to change their behavior would be a very hard sell.

It would be-- That's the hardest part of security, is actually changing human behavior.

So if we talk about "What is the shape of the solution in the future?"

We thought, "OK. It's going to be passive, it's going to be continuous, it's going to be something that users ideally would not have to even think about and do, and it would be much more natural.

It'd just be much more natural interactions, the same way that you or I would talk. How do I know that you're actually Grant Miller?

We met before and I recognized your voice, and that's how I know that that you are who you say you are.

We thought that technology, in terms of authentication technology, was going to move in the same direction.

Where many of these interactions, which I have this physical token that I need to plug in or I need to type in this code for, or I need to remember this password to these security questions or these type of things.

We thought in the future, it was going to be much more like you'd see in some sci fi movies, things like that, where you're going to have a voice interface and these type of things are going to be much more natural and just much more continuous, just happening all the time.

That's the model, we knew things are going to move that way in the future, so that's just really how we started building the technology around that side.

Grant: Cool, and then I think you maybe launched it at RSA or something.

John: Yeah. We were in a cell for a long time, we actually launched at TechCrunch Disrupt onstage.

Grant: Nice.

John: This was in San Francisco where we honestly at that point, we had no clue what people were going to think of this.

Because we were thinking "Are people going to be creeped out by this, are they going to think this is big brother? How are people going to react?"

And we had a really surprisingly positive reaction, there was some -- There's probably like 5% or so who were like "Oh my gosh, this is crazy. What about privacy?"

And these type of things. But we had 95% of people who were like "So you're telling me that you're going to track everything I do, you're going to track my location and movement, all of this? And I don't need to remember passwords? Sign me up. That's the world that I want to live in."

Because there was so much frustration around things on that problem on that side.

Also, I think attitudes around these things have really evolved. If you think about, just think about Amazon Echo and Alexa.

Let's say in 2005 you had said, "You're going to have a microphone in your house so that Amazon can listen to everything you say, so you could talk to Amazon and order toilet paper or ask what the weather is or whatever, and they'll be listening all the time?"

That is literally straight out of 1984. People would think you were crazy, and now that's one of the top selling products from Amazon.

Again, it's because people see the value in ads and like and their attitudes around these things are evolving.

I think that people care about privacy and they care about security, but they also care about convenience.

If you can provide some amount of extra convenience or value to the end user, then people are often willing to share more information or to use these type of systems.

The other thing that happened is that technology and machine learning had reached a point where things that used to be sci-fi were now, actually, people see these in real life.

Stuff like an autonomous vehicle, a self-driving car.

The fact that a car can drive itself, that people were accepting of that type of technology or understand that type of technology existed, when we came along and then say "We can identify you based on your gait and based on the way you touch a screen and things like that."

This was not so far fetched that people actually believed it and they believed it was possible, so that was certainly a contributing factor.

The other aspect was around the security problem, the fact that the security problem had gotten so bad.

Passwords, people hate passwords so much. All of those security questions and 2FA and everything, I think there was a general understanding and consensus that this was not the way of the future.

This was not the way that things were going to be in the future.

There was a question mark in people's minds about, "What is it going to be, how am I going to do identity and authentication in the future?"

But it was clearly not going to be passwords or passwords plus 2FA codes or these type of things. There was definitely an appetite for type of approach.

Grant: There's a couple different ways that you could take that market, though.

You could try to take this to companies so that they can replace their passwords for their consumer service with this new way to identify consumers, or you can take it to companies and say "Stop handing out RSA tokens and start using more of this context to help people authenticate into your corporate network."

Which approach did you decide to take?

John: Again, we went through multiple iterations of this, but when we first got started I mentioned we were at TechCrunch Disrupt.

We also we had RSA Innovation Sandbox, and that's I think where we were the first ever and still only ever unanimous winner there, and then South by Southwest and a handful of others as well.

Our initial approach, though, was basically as a souped up password manager.

We had a chrome extension, we had a browser extension and a mobile app that individuals could go and they could download.

We had a beta, like a private beta that people sign up for, and then we basically managed all their passwords and credentials but we would just hide all of that stuff.

So you go to a website, you go to Amazon or whatever, and it wouldn't even show you or ask you for your password.

It would just be "Replace this" by this button that just logs in using UnifyID.

You'd click that, and then in the background it would actually be talking username and password with the back end, but we had wrapped our authentication technology around that.

Now that approach is very hard because we needed a lot of data to improve our technology and to really drive that machine learning algorithms, and it's a hard slog.

In terms of user growth on that consumer side, maybe you can get-- We had a big splash at TechCrunch, we got 10,000 people to sign up and download our app and all this.

But then in terms of you want to talk about growth there, and we needed millions of users to really get that type of data that we needed.

We look at that growth path as like, "You've got to fight tooth and nail just to get your 10,000. And then the next week, if you need to double that, then you need to do all of that work plus more."

Again, end users don't care that much about security, it was a little bit of a hard slog.

You look at people like LastPass, one password and others as well, they have been at it for a long time and they still do not have great penetration.

The number of people who use password managers is not very high.

That's also not the market that we wanted to be associated with in any case, so we then shifted, and it was almost like "How can we get more users and more data?"

Again, we started getting approached by organizations that had challenges around this. They already had millions of users, they already had millions of end users.

We can give you an SDK, you can link into your app and then we can scale up much more quickly.

So that's really what our approach was this time, was we bootstrapped a bit with those beta users, just individuals with our chrome extension and our mobile app.

Then we quickly moved to an SDK that you can link into other apps, and then provide that service. Then again, we had a choice.

It was like, "Do we want to go after within the enterprise? Try to displace existing authentication mechanisms within a company?

Or, do we want to go more of a B2B2C route where we are authenticating our customers' ultimate end users?"

So we did the latte, we focused on the latter. We made that SDK so that, for example, we work with a bank or integrate into their banking app.

So then, providing extra levels of authentication for their ultimate end users. The thing that really drove us there was number one our need for data.

Even if we have a large deployment with an enterprise, that's 100,000 people at most.

Even large enterprises, they are in on the order of hundreds of thousands of people, whereas if you talk to other services then that goes into the millions of tens of millions.

That's one direction, and this aligns with the long term strategic direction of the company in terms of "We're trying to build this next generation identity platform that is not based on passwords, but based on these other behavioral factors," and then get a large enough portion of the population onto that platform.

There was a route within the enterprise, the other thing is there were established players there with very aggressive sales forces that were executing extremely well.

I'll point to Duo for example, Duo got acquired for $3+ billion dollars.

They didn't really have that much technology, they basically had a little app and they had something that was slightly better than RSA and RSA secure ID and soft token.

But there was no real technology there, but they executed extremely well on the enterprise sales side and they got a lot of great deals.

They ate a lot of market share from RSA, and they do greenfield opportunities that people wanted to, saying "Your password is not secure, you need to do 2FA."

Then they were there, they had just the right solution and they positioned it the right way.

So us as the tiny startup at this point, we were 10 people, and that was not the market that we wanted to go in and compete against.

Because I knew what that market would look like, that would be a big inside sales team trying to land these type of accounts for internal usage, and then really going head to head against--

It was not just Duo, there's a whole set of companies that really go after that space.

That was another reason why we shied away from doing that within the enterprise, authenticating employees or contractors.

Grant: Got it, OK. So then doing the B2B2C side, was the idea that end customers opt into this? Or that it's more like a fraud prevention technology?

John: This is really the two biggest areas of our business.

One is around streamlining authentication, so that is eliminating passwords and going passwordless.

Because both from a user experience point of view as well as the security point of view, there's a lot of organizations that want to move to passwordless, but they're not sure how to get there.

We provide a very nice solution either for password less or for displacing existing 2FA.

It's a supplement to the password, so you still have your password but instead of doing "I type in the six digit code," or "I SMS and text you this code," then we're able to use it and do this in a much more seamless way.

In these cases, we most often work with product owners and ones that care a lot about user experience. They want to move to that next generation experience.

Another one is call centers or contact centers, cases where there's a lot of friction involved in the authentication process as well as it being a vector for attack.

Providing more seamless authentication in those type of contexts, as well as physical world. Things like for smart locks and doors and automobiles like cars, travel.

These type of things as well. That's one area, and the other area is really around working closely with the risk and fraud teams.

In these cases, this is more like they're already ingesting a lot of different signals around risk and fraud.

"What device is this coming from? What is the IP address? What are the previous purchases this account has made? What is the velocity on this account in a more general sense, in terms of correlating with other providers?

Have I seen somebody with this identity trying to open up accounts at 10 different organizations? OK, that's now risky. Or have these credentials been part of a data breach?"

Using a lot of these different signals, and then we just provide additional signals of additional context, and we provide a lot of value there because the type of things that we look at are really different and orthogonal to many of the other aspects that they look at.

They find a lot of value, not only in terms of finding new cases of fraud, but also in terms of in terms of reducing false positive rates where it's actually legitimately users and maybe is legitimately the correct user but it may be other things that flag that make it look like a risky transaction.

But we get to say, "No. Actually this was the correct person, because all these biometrics match and everything like that."

So in those cases we work much more closely with those teams and then instead of just being an authentication result, that's like "Yes" or "No" or "Inconclusive," then we provide a lot more color around what was actually happening and that the user is doing.

In those cases, like in the risk and fraud case, then it's more like this is just sitting in the background looking at behavior and providing those additional signals.

The type of stuff that we do that already fits in, it typically already fits in with the end user agreements that they already have in place, because they're often using things like IP address and location and other types of data for these type of things as well.

Grant: So, right now you're going to market with both use cases? Or primarily with one or the other?

John: We do have some on the risk and fraud side, most of our business is actually on the streamlining authentication side.

Going back with the company, we started with a grand vision. Like, "This is the way that we're going to reinvent authentication for everyone," and all these different use cases.

Then we had the technology, a very cool technology.

Our gait analysis is very sophisticated, if you walk for even a short distance we can identify you with the same accuracy as a physical fingerprint.

About a one in fifty thousand false positive rate, that's where the state of technology is for gait today, with our solution.

Grant: That's just by having a phone in your pocket and walking with it for 30 steps? Or, how many steps?

John: Not many steps, around 5-10 seconds, and then we can then we then have enough that it turns out your movement and your gait is unique enough that we're able to then hit that level of accuracy, and this is all proven out with lots of real world data we had.

I believe the latest number is 35 million devices that are in front of our SDK that we've collected this type of motion data for.

Then we've used that to train machine learning models and validate them, so this is all based on real road usage as well.

There are a sets of customers that are really the early adopters that are very interested in that area, but then part of the struggle that we have is we don't want to just be working with innovation teams and the people on the future products.

We want to have people deploy and solve problems for them immediately, and burning problems.

We also, basically we introduced what we view as a stepping stone to that eventual future where there's no more passwords and all this authentication happens in a much more seamless way.

We implemented a push to auth capability. This is basically, if you want--

When you want to perform some action, you want to log into a website for example, instead of asking for your password or in addition to asking for your password, you get a notification on your phone that says "OK. Somebody is trying to log in, or somebody is trying to perform this action. Do I want to approve it? Or say, 'That's not me?'"

So then we have a mechanism within there, and we designed it with an eye toward security in terms of doing this in a much more secure way than these type of OTP solutions or SMS or these type of solutions.

That's a current status quo, is that most people implement SMS.

It is not an authentication protocol, and Nist and the FBI and everyone has come out and said this is deprecated, "Do not use SMS for two factor authentication because of lots of problems around the protocol itself."

The SS7 and the communication protocol there is not authenticated, it's not secure, it's not encrypted at all.

Not only that, but then there's a big problem with SIM porting where all you need to do is you just need to convince Verizon or AT&T or whoever it is that, "I lost my phone. Can you can port my number to this new SIM or this new device?"

Or even, "I was a Verizon customer. Now I want to be an AT&T customer, can you port my number over?"

The things that they use to authenticate these transactions is very weak.

They ask you things like, "What's your address? What's your mother's maiden name? What's your Social Security number?"

All these things that are really very easy to social engineer and to hack.

This even happened pretty recently, there was Jack Dorsey who is the CEO of Twitter.

He got his Twitter account taken over because somebody went into the store with a fake ID that said "Jack Dorsey,"and ported his number to a new phone and then reset his credentials and then logged in as him and then tweeted a bunch of stuff.

If this could happen to Jack Dorsey it can really happen to anyone. And it does, this is what we hear from customers.

They are now experiencing wide scale attacks on SMS as a second factor.

The most typical is you'll get a phone call that appears to be from your bank, you answer it and they say "Hello, I'm from so-and-so bank fraud department. We've noticed of suspicious activity in your account.

But first, we need to verify your identity. I just sent you a 6-digit code. Can you read it off to me?"

Of course, the person reads off the code and then maybe the hacker will then log into using that code to reset the credentials, log into the account.

They can then read off legitimate transactions. At that point, if you had any skepticism before you're no longer skeptical.

"How could they possibly know I did these transactions unless they actually work at the bank?"

And then they'll say something like, "We've noticed this fraud on your account. We need to close out your account and then set up a new one. We'll take care of all of that for you, but we'll need to transfer all the money in your account over to the new account."

And you say, "OK. Thank you very much." Then of course, later on if you get some notification that says "Big withdrawal, money being transferred."

You're like, "Of course. They called and they told me that was going to happen."

These used to be sophisticated attacks, but no longer. To spoof a caller ID, anyone can go to any number of services, and that part is trivial.

The rest of it is just a little bit of social engineering, but these are really costly attacks.

Again, it's because that SMS protocol and using a phone number as authentication is just really fundamentally broken.

If people don't take anything else from this podcast, just take one thing which is do not use SMS for two factor auth.

I know that there's a lot of organizations that currently use it, but it is being deprecated. It wasn't best practice three years ago and it's still, especially now, not best practice.

If you're on it, take a serious look at moving of. If you're implementing something new, do not implement SMS because that protocol and technique is just fundamentally broken.

Just related to that, we introduced a push to auth service, like if you log in then you'll get a notification and you'll get all the context around it.

It's much more secure, it's a much better user experience and it's much cheaper.

We price it very competitively compared to SMS, and so that's actually where we're seeing a lot of uptake now.

Partially because we're riding this wave of people who want to do 2FA, but they don't want to implement SMS because they know it's insecure and people know if you're going to do an implementation you don't want to do the thing that is deprecated.

You want to do something newer. This really competes directly with Duo, and with a number of other types of push to authenticate solutions.

Then we end up differentiating in terms of how we have all the behavioral pieces on top of that as well, so even if they're not ready at this point to fully embrace a full behavioral authentication, they at the very least can just get started with a much better--

Something that is much more secure, a better user experience and much cheaper than SMS. That was a relatively recent shift for our company, and then that's--

We're seeing a lot of uptake on that side.

Grant: Interesting. So, this is actually an interesting lesson, which is oftentimes the market is not ready for your grand future vision of the world.

They're just not going to adopt it nearly as fast.

So having a product or go-to market solution that's the interim step before you get to there, but people can lead down the path and eventually "OK, this other data we've already been doing that for years,"now you can bring that all in as well.

John: Yeah. I think this is just in general, any case where you are developing something-- This is a new capability, it's a new--

It's something that people don't really go and search for, this behavioral biometric authentication, because they don't even know it exists.

The whole idea of "I can authenticate based on motion and gait, and location, and these type of things," we as a tiny startup, we could either go and educate the whole world on this and try to push everyone in this direction--

We strongly believe things are going to move in that direction, and the people that we do engage with, we could talk passionately about it.

We could try to get them to see the world the same way, but that's again, there's a lot of challenges in following that type of approach.

I think it's important when you do engage with a customer, or engage with a vendor, they do know there is that long term vision and they believe in it and all of this.

But it also introduces a lot of risk and it introduces a lot of complexity, so then if you think about "What is a sales process for us? If we're selling this behavior, biometric solution?"

It's like "First of all, they have to believe that it works."

Because it's not widely deployed and everything, you have to get over that skepticism.

And then you have to say, "OK. What about GDPR and CCPA and privacy?"

And then we have good answers for each of these, it's like "All the raw data stays on a local device, and we don't collect any PII."

All of this, we have answers to all of those, but again this is making the sale much more complex.

Not to mention that even in the first place, it's not like many organizations have this.

We have a budgeted project to go and do behavior authentication, and there are some.

They are the future looking ones, the ones that really want to be on the cutting edge. They do, and so we engage with those customers.

But if you're talking about not the early adopters but the bulk of the market, that's an area where you have to build a solution that is really brain-dead simple.

The value prop is blatantly obvious, like it would smack you in the face it's so obvious.

They already are spending money on it or they already have a project to do it, like you don't have to go and convince them to create a new project or a new budget for this.

It already fits in with something that they're already going to do.

And yes, there's competitors in that space, but maybe the competitors are not servicing it well enough or there is some angle that you can take.

In terms of, "This is much more secure and it's a better user experience, and it's much cheaper."

You want to make it as easy as possible for a company to do business with you.

It's very much along those lines, and you can maintain that grand vision and that product differentiation and everything, but you need to have an offering that that is very easy for customers to adopt and use.

Grant: Part of the demo is the "Wow."

If you can do the same stuff that somebody else is doing but you add this "Wow factor" in that people are like, "Wow. That's really amazing."

Even if they don't end up using it right away or it becomes--

If it gets the demo exciting, like it makes them want to watch and get more people involved, it can be really helpful in terms of how you sell.

John: We've run into challenges there as well.

In terms of like, "You have your website, and you have other materials. How much do you talk about the big vision of where this thing is going, and the capabilities? "

And how much do you talk about, "Here's the things that you do that you can do with this today and you can deploy today," and so there's a natural tension there.

You have to strike this balance very carefully.

Grant: Yeah. The way that I've been thinking about this personally, for Replicated, is I try to--

We came up with this philosophy that our website really needs to be directed at the buyer and people who are going to buy from us.

I think we have other sites, we have Enterprise Ready and we are publishing a new thing pretty soon called OnPrem.org, and these are the higher level, more strategic messages.

Publish your strategic messages on these content-oriented guides, and really they are less branded by your company.

I think they're more viral and consumable that way as well, but you're really helping to deliver a vision that you believe in.

It's not really that commercial, the message, it's like "We believe this stuff is important." Then you have your website talking to your buyer, and that's more actionable.

Then I think you have to have-- For us, we really try to work with developers and give them the power to leverage our tools and adopt our tools.

There's open source websites and open source repos that are really developer first, so it's really to me, it's about these different properties speaking to different audiences and then helping that to lead to eventually a buy, hopefully.

John: Yeah, definitely. That's absolutely correct.

You really have to understand your customer and what is their problem, like "Who are you talking to and what do they care about?"

In some cases, is this the early adopter CIO who just recently joined the company and wants to have a major initiative?

They're trying to push forward a major initiative that is really visionary and moving forward, and then you want to ride along with them and provide them all the ammunition and everything that they need?

Is this somebody that there's a fire that they have to put out, or they're currently getting poked in the eye by something and you're selling them something that solves their immediate problem and that's the thing that they care about?

You really have to understand, "Who is the buyer?" Within the organization, and "What do they care about?"

Then you want to make sure that your message is very crafted towards that individual.

Grant: Yeah. Product marketing is hard, in the enterprise software space and the security ecosystem particularly, there's just so much jargon and noise that it's hard to really differentiate and be clear about what you're doing, because you're trying to tie the categories they are familiar with and trying to align with budget.

But at the same time you want to communicate the unique value you're bringing.

John: Yeah, these are all the challenges of enterprise sales. I think it's gotten worse, actually.

It used to be that you could do SDR work and you could reach out to someone, and then you sometimes get a response so people would be interested in this .

Now because those channels have been so flooded, now basically you talk to modern CIOs and others in IT in the enterprise, and there's so much there that they just become all noise.

They just block all of it, and so you have to be really creative about "How do you find and reach those people?"

Because they're getting phone calls and emails and LinkedIn, and so many things just all the time, just inundated with all of this.

Because it's very lucrative, because if you think about all of these SDRs that are working at all of these organizations, if they get that deal and that customer signs that can make or break a company.

That can make their quarter, all of this. So the sales has become increasingly aggressive, and that's actually turned off a lot of customers on the other side.

That also means that you have to be really careful and thoughtful in terms of how you engage with the customers.

Grant: Yeah, and I think there's always different challenges. I think that rarely what used to work still works, that's a constant theme in everything.

You have to find new channels, new ways to reach people, new approaches on the consumer side.

This happens where a specific channel or source becomes saturated, like there was so many businesses built on the back of AdWords back in the day.

Now to really build a business on AdWords you're paying these huge prices, so the arbitrage opportunity was earlier in the market and eventually the market recognizes the actual market price.

It just becomes harder to actually create and extract value from that, so you have to find new places, and new ways to do that.

John: Yeah, and I think developer first, I think there's a lot of promise there.

You have to approach it the right way. If you just think "I'm going to make an open source project and I'm going to throw it up on GitHub, and then magically stuff is going to happen."

That's not the way that these things work, you have to be very thoughtful around how you approach it.

But especially nowadays, it used to be that a lot of things were top down in IT departments and enterprise.

Now you see a lot more developer led and developer focused, with DevOps and everything else, in terms of them making the decisions about some of the tools that you use, or these type of things.

I think there's a lot of value in providing this type of developer first, but again you have to do it in a really careful way.

Grant: Of course, you have to respect your buyer. I think that's the most important.

Respect the customer, respect what they're doing. You can't be too aggressive.

You can't talk down to them, and there's a lot because you want these people to respect you and to buy from you, and you have to show them respect to make that happen.

John: Yes, absolutely.

Grant: Cool, so what else are you thinking about? What's next on your agenda for UnifyID, or what else are you seeing coming out of academia? What's exciting for you right now?

John: Here at the company, like I mentioned, we really got started in 2016.

We've been working on the technology for a while, and this is just personally, I very much want to see this problem get solved.

That's really the motivation behind doing this, doing the company. You saw that, yes, there's a business opportunity there.

But more fundamentally it's just "Come on, guys. We can do this in a much better way."

This is especially why I'm especially passionate around just moving off of really bad forms of authentication, like your SMS or mother's maiden name or security questions.

You don't have to go full password list yet, but at least move off in that direction. Much of the stuff we're doing is to try and support those.

Like I mentioned, we have an aggressive price point around push to auth service. Again, it's just trying to drive that type of adoption.

That part is really important for us for 2020. Just looking at the broader landscape of enterprise, enterprise software has always been this area of huge potential that is still and will continue to be underserved.

Because when you think about startups and people starting companies and doing new innovative things, most of that energy is focused on the consumer market.

If you look on the enterprise side, there's large-- And I would argue even larger opportunities on the consumer side, but there is much less of a focus on that side just because there's not as many people who are familiar with it.

It's a little bit of a foreign concept for individuals, like an individual, if you're an entrepreneur and you use your own products all the time you understand those.

But unless you've done something within enterprise or worked in the enterprise space before, you don't necessarily understand or are comfortable with the needs of the enterprise.

Because it really is a very different beast than consumer.

When we look for hiring, for example, and people in product engineering and other places, we really value that enterprise experience because it's such a different beast than what you see on the consumer side.

I think what that means is that the pool of entrepreneurs and ideas and innovation is smaller, so I think that means that the enterprise market is going to continue to be underserved even though there's a massive opportunity there.

I think investors see that as well, and the investors are always interested in enterprise.

Even on the VC side, there's not that many VCs that really truly understand enterprise, but the ones that do and are able to identify the real opportunities there and identify the teams that could execute and win versus the ones that won't, they're going to win out big.

The other thing around enterprise is that these things take a long time.

I mentioned for my first company, it was 10 years start to finish and I heard a metric that "The median time for an outcome, in terms of IPO or acquisition for a successful enterprise company, is 10.7 years from start to finish."

You have on the consumer side, especially, you hear these stories about these companies that get acquired in 18 months, 24 months, these type of things.

The enterprise one is a much longer haul, so again maybe people shy away from it a little bit more.

But the demand has not gone away and will only increase, because I mentioned around authentication and risk and fraud, the majority of those costs are borne by the organizations.

They have a desperate need to solve these problems.

Individuals are just like, "Fine. I lost my password, but they ultimately don't end up paying for that. It's the organizations that do. I think that's the same-- The same is going to be true, where both the liabilities and opportunities are going to be very much on the enterprise side.

That's going to continue to happen and only increase, and I think the supply-- Because of the nature of enterprise and the fact there's not as many people who are familiar with it, the supply on that side is still going to be limited.

Which means I think that there's going to be a lot of great opportunities on the enterprise side.

Grant: Yeah, I couldn't agree more. That's one of the goals of EnterpriseReady and this show, to try to encourage more folks to understand enterprise and get the knowledge and be able to dive in.

Because it's hard to hire people with enterprise software experience if the prerequisite for everyone is that everyone have enterprise software experience.

We need folks to be able to come in and not have had that much experience, but have some knowledge shared with them beforehand. Hopefully we're helping to build that future.

John: Yes, I hope so.

Grant: Awesome. John, thanks so much for your time. This was amazing and I really appreciate it.

John: Yes, thank you for having me. It was a great time and a great conversation.