In terms of feature parity, again it's generally a reflection of what customers are asking us to do. And the one example would be where of platform prevents us from doing something. So iOS has some very different idiosyncrasies versus Android, and so there are always going to be cases where we have to code around or do something different or unique for one platform or another based on whatever the inherent native attributes are of the platform, just in terms of basic things. Think of background processing as the most glaring example.
MR: With iOS 7 it looks like Apple is starting to work in some application management APIs, some standard APIs. How do you deal with that, do you worry about the big platform vendors like Apple and Google starting to build more of this functionality into the platform and kind of squeezing third-party vendors out?
A: I don't spend a lot of time worrying about that. First of all, I worked at Apple for a while and I worked at Motorola and worked very closely with Google for a while, right up until the end. I think we have a reasonable understanding of where they're headed and how aggressive their interests may be or not be with respect to supporting our kinds of customers.
Our product is very focused on enterprise. We're not a prosumer solution, we're not an SMB solution, per se. So I think there are always going to be cases where the native solution may be enough and if the native solution is enough then that customer is likely not going to be looking for us. I would say nine times out of 10 what we hear from customers is that they've been in a one-platform world before. They've sort of gotten stuck. When the hardware that they were locked into was no longer what their users wanted, that's when they got themselves into trouble. We don't hear a lot of customers looking to deploy a pure native solution, I think mostly because of the pressure on mobile needing to span across multiple kinds of users, on lots of different devices. So that's going to mean that they need to have different tools for different implementation for those.
Penetration testing for security solutions in a large enterprise can be six, nine, 12 months, depending. They're not going to want to do that over and over again for every flavor of OS that comes out. It's just not feasible. It's one thing to win the proof-of-concept. It's another thing to actually win the implementation, which means you've got to be great at both.
JG: You joined in January. In April you announced a new CMO, Chief Revenue Officer, and new SVP of operations. Why so much management change?
Sign up for CIO Asia eNewsletters.