“Good judgement comes from experience, experience comes from bad judgement.”
I wrote a private postmortem within days of shutting Kryptiva down last April, but you'll never read that one. Sure, you'd guess there are things which are intimate and delicate, but more importantly, hindsight has enhanced my understanding. That was one lesson learned: when you've invested so much time and effort and have made so many sacrifices to achieve a goal, it becomes very difficult to let go.
My first startup didn't (and still doesn't in fact) need a postmortem. It was rather successful given its field of endeavour: providing training and consulting in the mobile/embedded Linux world. With customers such as Motorola, BAE systems, Scientific-Atlanta (now part of Cisco), Panasonic, etc., I had started it out while doing my masters and brought it up from nothing with little outside help. Making in a week what others made in a year at twenty something you'd think you can walk on water.
I had gotten into the FOSS community in the late '90s right before FOSS became mainstream and made a number of contributions, including the Linux Trace Toolkit (LTT), before eventually writing O'Reilly's “Building Embedded Linux Systems”. Actually, it was after I witnessed the uptake for LTT that I started my first startup. That was a case of monetizing on pent-up demand. To an extent, I was at the right place at the right time. And then, of course, with some effort and zeal, one thing leads to another and a real business was born.
Coming into Kryptiva, it looked like a given. I had already built another startup and had a very solid technical track record. So this was a matter of taking my next big idea, create the product and profit. Or so it seemed. Because, in the end, previous experience in a successful startup can be an impediment and while a technical track record is necessary, it is far from sufficient.
Interspersed across the text are indented comments such as this one. They reflect my current day thinking about what I'd do differently from the events described in the non-indented text. Please keep in mind that these are forward-looking statements. I have a tremendous amount of respect towards everyone that I've worked with on this endeavour and do not wish to even hint at a “should've”/“would've” discussion. What's done is done. There is no way to go back. And ultimately it failed under my watch, and that is mine to bare.
Still, this is the story of one of the greatest endeavours I've ever undertaken. One that has left a profound imprint on me with regards to not just every aspect of building a startup, introducing new technology to the market and running a company but, in fact, some very fundamental aspects of life, human relations and human nature in general. It is now an intrinsic part of what makes me who I am and most certainly a key to many of my future successes.
Note that this postmortem is written with specific focus on what I would do differently in my next startup. I'm not going to spend much time on what I would do as-is, it's mostly inherent to the description. Ills, therefore, might seem to take a disproportionate place, but generally and despite its ultimate failure, the amount of time and energy I put into it, and the amount of stress I lived through it, this was a fun place to work. For this is mostly a case of a death by a thousand cuts.
Email authentication: Q3-Q4 2005
I started Kryptiva with an eye on solving the spam problem. I had been receiving tons of it for a while and wasn't satisfied with this idea of filtering stuff away. There ought to be a way to simply and effectively let recipients know whether an incoming email was spam or not. And like others with an itch to scratch, I came up with a solution. A solution that seemed so revolutionary that I went and filed a patent on it. That seemed like the best way to protect it at the time. Over the years, as our technology expanded and we discovered new bleeding edge ways of doing cool things, we filed half a dozen patents.
Would I do this again? Would I start by filing patents and/or use patents generally? Likely not. Patents cost a lot and require a lot of time and energy to get them right. Initially we used an IP law firm for all aspects of the patent process: drafting, drawing, filing, prosecuting, etc. The further we went, though, the more I found myself involved in writing the full patent descriptions and claims myself. Part of it to save money and part of it became self-fulfilling as I found myself having an increasingly easier time drafting the content and the claims, and, later, filing myself directly with the PTO. For what it's worth, I even had a patent attorney once suggest I pass the patent bar. Thanks but no thanks.
So stick to getting the best product out there and get a user mass first. Once you've got those and are starting to break new ground then you might want to file some patents. Whatever you get with your initial product is going to be low-hanging fruit for any large player already in that field anyway, so you might as well focus on building a fanatical user-base. That's an asset whatever 800 pound gorilla you're afraid of just can't duplicate. In that regard, Guy Kawasaki is right: the best way to protect your idea is to make a great implementation of it.
I would, however, file trademark applications very early on. It used to be that you only needed to secure your “.com” and be on your way. In this day and age, though, it seems like namespaces are multiplying at a very rapid pace. You now need the same moniker at twitter.com/foo, facebook.com/foo, your favourite app store, etc. You can try securing all of those at once and you might just succeed. But I can guarantee some new namespace will crop up while you're not looking and it'll bite you. So, by all means, it'll take you about an hour to fill out the form on the USPTO's site and about 300USD to get going. Put in something like half a day to make sure you understand the process and you should be all set. I was a little more paranoid and spent some time studying competitors' trademark filings to use similar language, but you don't have to do that, the PTO's examiner's job is to make sure your application is receivable and will make suggestions as to necessary language changes. Sure you'll need lawyers to get your trademark enforced, but at least it'll cost almost nothing to secure that option. Whereas later it'll either be too late or way more expensive.
In the summer of 2005, we hired a handful of interns to start working on the alpha version of the authentication solution. It was essentially a new cryptographic protocol based on existing cryptographic algorithms. So we had people working on the web registration system with its database, others working on the client side, including an Outlook plugin, and I was coding the server side. The delivery date was set to ASAP and we worked away at this until the end of the year.
Would I do this again? Use a complex client/server architecture for a product design? Likely not. Starting development with so many platforms (server-side SSL'ized crypto daemon, client-side SSL'ized crypto client, server web reg w/ db, and Outlook plugin) very much set the tone for the rest of the technical choices in the ensuing projects. This was somewhat exacerbated by the fact that the level of talent in the team made it possible for additional complexity to be added with relative ease. So much so that some of the deliverables were behemoths in and of themselves: our own custom file-system, our own Ubuntu-based custom Linux server distribution, etc. Along the way, we also ended up finding out that Outlook plugin development was much more complicated than anticipated; I think there were three rewrites of it before we got something relatively solid. It's one the trickiest development environments I've ever had to deal with. For what it's worth, I've found it easier to debug kernel code that crash-dumps Linux than to develop inside Outlook.
Whatever I do next will start with a minimalistic set of platforms, preferably a web platform with a REST API, possibly built on Node.js, and grow organically from there. Developing custom clients speaking custom protocols to custom server-side Unix daemons is something I've come to believe is a very wrong approach for the first iteration of a solution, especially given how “easy” it is to hack something together on top of a REST API. Twitter, for example, has only recently switched to a classic always-connected client-server configuration (they call it “real-time”) instead of a polling-based REST API. If a polling-based REST API can be useful to Twitter which has a 100M+ users then that construct can't be that bad. Of course each application requires its own architecture and polling may not fit your application. Try long-polling in those cases ;) And a word of advice on Outlook: for better or worse, it's been designed and programmed to blindly protect the user from lousy plugin developers, so you're walking on very thin ice; use C# and make sure you've mastered the use of Marshal.ReleaseComObject.
In parallel to the initial development we were looking for ways to get this to the market and were seeking some outside expertise to help us with this. After speaking to a variety of so-called “experts”, we secured the help of an outside firm that came through solid references and that specialized in helping startups. They did a lot of market intelligence on the authentication, phishing, security, etc. side of things and through various meetings and brain-storming sessions we came to the conclusion that authentication alone was going to be a hard sell.
Would I do this again? Use an outside firm to help in finding/planning a go-to-market (GTM)? As likely as hell freezing over. As Kawasaki puts it: if you can study the market you're trying to penetrate then you're already too late. In any meaningful startup, you can only study the market by trying to bring a product to it. As Eric Reis explains through his lean startup methodology, when you start you neither know what your product is nor which market to aim for. If you're not familiar with the concept of lean startup then you should get familiar with it, fast. What you want to do is bring to the market what you believe to be the minimum viable product (MVP) ASAP and pivot from there.
Email Security: Q1 2006 – Q4 2007
For some time before that, we had had a list of things we'd like to add along the way. Two of those were proof-of-delivery and encryption. And around the same time we were closing our work with the external market-research firm, I had actually come up with a fancy way to wrap all three services on top of the same infrastructure. Both from a market standpoint and a technical standpoint, this new solution which did encryption, proof-of-delivery (PoD) and authentication was very interesting. It actually provided the same level of security as PGP, plus PoD, plus authentication, but without users ever having to know anything about public keys or private keys. A rapid search through the PTO's site should yield the patent applications if you like this topic. Needless to say we were all very excited by this. Here we were solving one of the greatest problems facing the spread of secure email. You got all the benefits, none of the problems. What more could you ask for?
Would I do this again? Create/push a security product? Likely not. The security market is a very peculiar one. Take it from me and others who have failed before me: nobody cares about security. Sure, you'll get lots of people whining about Facebook security. But it won't stop them from using it. Security is a requirement for enterprise sales, but it is rarely a prime motivator unless it's a burning niche problem, like the RSA tokens for instance, and those are rare. In our case, we were aiming for curing a problem inherited from the use of legacy email. Unfortunately, perception of the problem vs. reality of the problem were very different. The problem was and still is real. The perception of it from the point of view of the business buyer, though, is that it doesn't require any fixing. And that's what it often comes down to: reality vs. perception. So do give serious consideration to Marc Andreessen's advice when he says that between market, product and team, he'd put market way in front, and team and product at a distant second and third. Remember to factor in human perception however. You may be able to make a brilliant case on paper that the market would benefit greatly if it used your product, and/or that your product cures a long-standing problem within the market. But if the market isn't, as Andreessen puts it, pulling on your product faster than you can make it, you've got nothing. Or, at the very least, you've still got a lot of work to do.
So, soon after concluding our work with the external firm, we hired a marketing industry veteran (non-tech related) to act as marketing lead. I'd focus on getting the product delivered with a yet-to-be-hired full-time tech team and he'd focus on getting us a website and all the rest of the marketing collateral required for sales. Over the next few months we worked on ironing out the marketing specifics related to the product to be developed, finding an agency for all the artwork and hiring a dev team.
Would I do this again? In this specific order? No. I'd build the MVP first, foremost and ASAF'nP. It doesn't need logos or artwork to get users for a product filing a real market need. Heck, I'm willing to bet it doesn't even take a proper website. But it doesn't have to be that drastic. I'd probably build some minimal website which does one thing on the front page: get to the point. No catchy phrases, just make sure the user gets to understand very rapidly what the thing does, in as few little words as possible. Put pictures, videos, foo, ... whatever it takes for the user to be able to visualize instantaneously how this thing fits in his life and how it benefits him; and no, I'm not advocating clutter, on the contrary. This is likely one of the most challenging tasks. Often, you'll either fall in the “I've already seen tons of products that do this and I can't see how this is different” or in the “I have no idea what this does and I can't be bothered to look further” with your misery ending with the user clicking on the “back” button. That's where the money trail starts, so figure it out. It is your problem.
Back to the MVP for a second. At this stage of the game the MVP was a fairly complex combination of server, client and cloud services. I would likely avoid this kind of project in the future unless I had a very substantial multi-year funding secured ahead of time. But you're unlikely to raise that kind of money if you haven't already very positively exited a previous VC-funded company. Funding is not an equal opportunity endeavour. Tough. Fred Wilson's recent TechCrunch interview is actually quite telling in that regard. When asked what were the determining factors that made him want to write a check to Zynga, he says: “... I've been an investor in every one of Mark's companies since 1994. I have a personal relationship with Mark. I love investing behind him. Some of his investments have been successful, some of them have not. ... It was a bet on Mark, ... It was Mark plus games plus Facebook and that was it.” If you're new to the startup game, read those words very carefully. Because a slew of those most well known startup success stories are often funded by a very small circle of highly inter-connected people. Very seldom do successful startups (successful enough to be house-hold names) reach the pinnacle without going at one point or another through that group of people.
On the hiring front, I started posting ads in local newspapers and local universities. I'm a Montreal guy, and that's where I started my first startup. By this time, I was living and Sherbrooke and I'll have to admit quite candidly that I was seriously afraid I wouldn't find the right calibre of people. It turns out I needn't be afraid. Having spent earlier years training dozens of engineers at some rather well known tech companies across North America, I was happy to find extremely sharp graduates coming from the Université de Sherbrooke. One of my criteria besides the academic background (it wasn't in fact a determining factor though most of the guys I hired had masters degrees), I absolutely wanted to see: a) individuals who clearly demonstrated that they had pivoted (that wasn't the term I used then to describe it, but that's what it was) in their curriculum to achieve a goal they set to themselves, and b) individuals that showed they had undertaken projects out of passion, above and beyond what was required out of their curriculum. I was rather upfront with those that came through the selection process: I couldn't pay them half of what they're worth, but they'd have the opportunity to work on an exciting project, they'd get shares and pay would of course increase as company milestones were met. I didn't get turned down by anyone I made an offer to, and the majority stayed until the very end. Most shared the point of view that they preferred this offer rather than have to go to work in Montreal. In hindsight, however, I expressed way too much confidence in the projected dates of the milestones and our certitude regarding where we were going.
Would I do this again? It depends which part. The recruiting requirements I'd likely keep the same. In fact, I'd probably be even more uncompromising in that regard. In those cases where I did compromise because I thought it would be good to get different profiles or tempers, it didn't work out. Either the fit with the rest of the team wasn't there or relationships with the rest of the team weren't so good. And don't get me wrong, I stood behind everyone all the way. I spent time ironing out differences, mending fences, helping sides appeal to each other and never accepted anyone to speak ill of anyone else. Even privately, I tried in as much as possible to work beyond any expressed discomfort or anger to actionable items. Still, the different personalities were always at odds. That being said, I'm happy to have worked with everyone there, even those who didn't fit the mold. In fact, and I hope nobody takes this wrong, I learned far more on the human level from managing the guys that stuck out than managing the rest of the team. Later, the benefit of having different personality types would be realized, but in the sales team.
One thing I wouldn't repeat is expressing any sort of confidence on the milestones, the product or the market. I fathom I'd say something like: “Look, this project is great in every crazy way you can think. Here's the general problem area we're working on, but we don't have any paying customers yet, so you're likely going to have to keep changing job descriptions for the foreseeable future. Which, I might add, is something you're going to participate in redefining every day. Are you in?” At least this makes pivoting ingrained.
After a few months, we had a working prototype which we showed under NDA to companies who agreed to participate in the beta. We were actually rather secretive of what we did. Remember, this was ground-breaking, so we absolutely wanted to make sure no word would leak out about what we did, how we did it or how it compared to what was out there. In fact, it wasn't until we had a close to final version of the product that we started showing it openly to customers in early 2007.
Would I do this again? Likely not. In fact in the next pivot we totally dumped secrecy. No more NDAs or anything of the likes. We went straight to the customers, showed them what we were planning to do and asked them what they thought. Save for personal or financial issues, I wouldn't want to carry secrecy around. There's far enough already to be carried.
With the final release close to being out, we were increasingly looking to materialize sales. After some tries and hiccups, we settled on the former national director of sales for a fairly-well known security firm. This was a 20 year sales veteran with contacts at the all right places. He had sold email security solutions before and understood the lingo, the decision process and the pain points. It was a match made in heaven, so to speak. One of the very first things he did when we started working together was make the case that no one was willing to pay for secure email. I initially fought this very hard, but eventually relented, he was right. So we set two things in motion: a) we would create a free version of the product that gave the encryption part free of charge, with PoD and authentication as a premium product, and b) I'd start looking at “what's next?”.
Would I do this again? Hire an industry veteran for a go-to-market? I'm of two minds on this one. On one hand, there is something fundamentally dysfunctional with a startup that must hire its industry expert for contacts and sales. On the other hand, you do what you need to do to ensure a startup succeeds, and if you don't have the requisite expertise/contacts for a given task, you go out and make sure you hire someone that does. Still, sales is pretty fundamental and despite what Fred Wilson has to say about what a CEO does, as a CEO sales is my business. If I can't sell it, nobody else can. No buts, no ifs, no maybes, no nothing.
There are also other aspects related to working with industry “veterans”. For one, if you are lucky to have them stick around long enough and the hierarchy does not get inverted, you get to learn, fast. Fact is, true industry veterans have no time to waste. In our case, the sales VP was a tremendous addition to the team and brought a lot of depth along with the expertise and contacts. I personally learned a tremendous amount about sales and the enterprise mindset through him. Sure I had sold for quite decent amounts to large companies, but truly mastering how to grasp need-payoff on the customers' side can be tricky, especially for techies who are accustomed to reasoned, well thought out, programming-style decision processes. Enterprise sales usually requires a lot of players to buy in for a PO to come out, so you need to find yourself an internal sponsor and align all the dominos so that it's easy for him to get everyone else inside to sign off.
The downside with having a “veteran” on board is that in times of doubt, frightened individuals will tilt towards safety, and that usually means experience. That's just human nature. So there were some odd situations where I had to work overtime to get my points across. But that's fine, because it allowed me to get pretty good at it, which was to the benefit of the entire team.
The dev team worked over the summer of 2007 on the free/premium offering while the sales VP and I looked for a PR firm for handling the launch of this radical new offering. I contacted a valley-based CMO I had crossed paths with several times through my FOSS involvement and he agreed to help us find a reputable PR firm. We interviewed a couple of those firms and eventually settled on one with offices on the east coast. And they did an outstanding job. In fact working with them turned out to be strategic in leading us to our next pivot. They hooked us up with journalists and analysts, and helped us draft a very decent press release. Finally we had our big day on October 1st 2007.
Would I do this again? Work with a PR firm for a startup? Unlikely. They aren't the right tool. When you've got people like Arthur Sulzburger, Jr. coming out and saying “We will stop printing the New York Times sometime in the future, date TBD”, you know the “press” world is changing very rapidly because the “media” world is going through some rather profound changes. “The people formerly known as the Audience” are actually right there waiting for you to spark a conversation about a problem they're having. You don't need intermediaries for that. You just need to show up and keep the conversation going.
One more thing: don't be distracted by TechCrunch and their following. I'm no TC specialist myself, but from the looks of it attending TC-related events and having connections through to TC authors are required elements for appearing on that blog. Plenty of interesting startups don't make it there, and I'm sure it isn't for lack of trying. And I could go on but the point is this: get over it, you will likely never get covered by Techcrunch. Much like a lot of things in startups, ignore the noise and focus on keeping your nose to the grindstone.
In parallel to this launch work, we had started a serious VC push. We had been running on angel money since the beginning and realized we needed serious muscle to move things faster. So we had everyone we know pull their Rolodex and we booked meetings with everyone we could find that could finance us. We prepared slide-decks, pitches and lined up close to a dozen meetings, mostly in Montreal but some over the phone to some US-based funds. We pitched through the end of September to early October.
Would I do this again? Wait this far in the game to visit VCs? No. Remember the Fred Wilson quote from above? Ask yourself which VC you have a personal relationship with. And if the answer is “none”, you've got a problem. Cash is a connections game. Make sure you cozy up to VCs very early on and keep in contact with them as often as possible/necessary. If nothing else, they'll come to perceive you as a specialist of the problem area you're trying to solve – and that would be a very good thing. If you're in Montreal, there are plenty of social events that'll allow you to mingle with VCs and like-minded entrepreneurs. There's, of course, a catch to this. Techies aren't sociable types and don't like to entertain relationships just for the heck of it. That's why techies that want to launch startups need to be of a special breed, or walk on their egos to get to their goal. You also need to understand how VCs work. There's plenty on this out there, read it up. But, essentially, they have to make careful bets based on tested rules of thumb that will allow them to get a stupendous payoff on some of the companies they invest in while others in their portfolio either die or go sideways. So you need to show why you, as a bet, will pay off. Hint: cool technology is of little value.
We came out of the PR and VC process realizing that getting to break-even was going to be very long and tedious. We were expecting some kind of ripple effect out of the PR process and none came. We were expecting a hallelujah from VCs and it never materialized. That was hard to take. By that time, we also had had a series of high-level meetings with several Canadian banks and brand-name law firms and engineering firms. None of which resulted in tangible sales.
Email-Centric Collaboration – Q4 2007 – Q4 2009
Over the summer I had been working on “what's next?” and had come up with a nifty concept/paradigm/construct. The idea was basically that in the web world (pull) https guarantees both authentication and encryption. Yet, it wasn't Netscape that made the money with SSL, it was everyone else that built something of value on top of it. So, essentially, it wasn't secure email that was interesting, but the fact that it could be used to push apps on top of email. By mid-October we had a demo that showed how a user could initiate a file-sharing, screen-sharing and instant messaging session just by clicking on a drop-down while composing an email. It was crude, but did raise eyebrows. Hence our next pivot came to be.
Would I do this again? A major pivot like that? Without hesitation. I'd even be more extreme and drastic about it. Fact is, the security stuff lingered on as the dev team worked on what we projected on top. At the time it seemed like an entirely reasonable choice: try selling what already works until the value on top of it is ready and then sell that. Plus, some in the team were really worried about this change of plans and, to be quite honest, I was very self-aware regarding the complexity of what we built and didn't want to loose any of those that had built it – another argument for sticking to simple designs. It wasn't obvious at the time, but when the value-add became advanced enough, we more or less realized that security was an impediment. In fact, some in the team were pushing for its dismissal earlier, but it was the only “finished” product we had and I wanted to see sales so I kept it there. Eventually, we dropped the crypto stuff altogether and only kept the ActiveDirectory/LDAP integration it gave us.
Even two years later, when we were entertaining our next major pivot, this “what can we build on top” mindset came to haunt us. In fact, even after the company shut down, I kept looking for ways to salvage something out of what was built. Maybe others have an easier time with this, but I've found it extremely difficult to sever from something I've invested a lot of energy into. The same goes for a lot of people involved in the project, sacrificing anything previously built was a harrowing experience. If nothing else, that has made me develop a watchdog routine in my head that keeps poking me to check for this pattern. It also made me develop an intransigence regarding anyone's pivot resistance. If I'm going to cut, I'd rather no doubt be left in anyone's mind that I'm resolute. And if someone disagrees and wants to stick with the status quo, they better have some very solid arguments to back that up.
Another thing you need to understand about pivots is that there can be more to your idea than you can think. It's one thing to envision something in one's head. It's an entirely different thing to see it in action, crude as it may be. So do yourself a favour and get to a prototype ASAP.
Would I do this again? Come up with a user experience that is totally off the wall? This one I'm really unsure about. The iPad is off the wall, but it's crazy how intuitive it is. Then again, it's got Apple using its marketing power to give it exposure. Trying to push something disruptive is definitely one of the toughest things, if not THE toughest thing, we had to wrestle with. How do you explain to the user something he's never done before? Sure, you want to show him, but what do you do in 10 seconds over the phone? Can you tie that in to an immediate pain? What if you're part of an emerging trend that hasn't yet set in? Etc.
I'd certainly be very leery of going into this territory again. I'd definitely want to cast anything I think of into a product that answers an immediate need some niche has. At least then I've got some revenue trickling in fast. Anything that requires evangelization would likely put me off. Then again, Twitter was off the wall and it took off like crazy. And that's the stuff of legend and where the really big payoffs usually are. It's a tough call.
Ultimately we solved this by reducing what we did to the single most obvious thing the user could identify with and possibly have a need for: file-sharing. And of course then it really didn't sound cool anymore. But it did get the point across, fast.
Over the first half of 2008, the dev team therefore worked on building file-sharing, screen-sharing and instant messaging on top of the secure email solution. This involved a whole new client, and two new server-side services. Stack'em up. So we had an Outlook plugin doing the security routine with one server and talking with a tray-icon application for the collaboration side of things, which itself spoke to a different server for all collaboration-related functionality. Up to then, I was still very heavily and directly involved in the design and development of much of the software components. Gradually though, I had been trying to delegate much of it and various events, including one especially difficult and lengthy meeting with the entire dev team, contributed in pushing in that direction.
Would I do this again? Continue being heavily involved in design and development? I really wish not. This isn't the best place for me to be, despite how “talented” I may be as a techie. In fact, we eventually got to a stage where I was rather removed from the majority of routine development while still being involved in critical designs and, most importantly, defining user-experience. In the future, I'd want to keep a safe distance from the dev team. Having a trusted lieutenant (i.e. Engineering VP or CTO) in charge is probably the best thing to do and has worked out very well for us.
While the dev team worked on the collaboration product, the sales efforts continued in the same direction as before: enterprise. We met dozens of companies and benefited from their insight as we crafted our message and made progress on the dev front. We also eventually realized that continuing to pursue enterprise sales was going to kill us, we needed to try something else. In the summer of '08 we therefore assembled a junior sales team to go after SMEs using cold-calling. They spent the rest of the year doing a 40 call per day routine each. Along the way, we started talking with some resellers (VARs, ASPs, etc.) to have them push the solution to their customers. The reps rapidly discovered the joys of pushing new software to customers. Boy was that fun. Nevertheless, it gave birth to a sustained feedback loop back to the dev team, with all of what that entails. Slowly the engine was warming up and a pipeline was being built. Earlier, we did have one and we were talking to customers. But an enterprise pipeline is a strange beast and a slow moving one at that.
Would I do this again? Wait this far to aggressively go after customers and get a sustained feedback loop back to the dev team? Hell no. I wish I could say that this wasn't by design and I didn't want things to turn out this way. But that's what happened. Later, we did figure out how to get the needle moving faster on this: it's called the Internet, stupid. At this stage in late '08, though, the strategy and the product's design were very much geared for volume sales, not individual licenses. So the thought didn't occur immediately for us to use AdWords. The net is good for getting lots of small sales, but is usually just a collateral when it comes to volume sales which need a one-to-one contact to get them moving and ultimately signed. The price-point at that time was, after all, 200$/user/year.
Still, I would stay away from trying to close volume sales as a first offensive. I'd rather focus on getting a huge customer base, possibly all using the product for free, get some conversion within that user base and then use that as a stepping stone for some low and then later large volume sales. A point I'll come back to later.
More generally, I would likely stay away from enterprise software sales altogether. It's not a generally exciting market, it's allergic to feeding anything bleeding edge to users, and moves at a snail's pace. It is, however, very lucrative when you can cut into it. I often read articles on startup funding that claim that some of the more profitable startups are those that go after the enterprise. Beside being a nice statistic, I'd be very curious to see the specific needs being fulfilled and the make up of the teams that have gone after those markets. The often-cited VMware, for example, did not start off in the enterprise market. At least that's not what I saw on their website the day they launched. Then, they were selling a piece of software whose main touted benefit was the ability to run Linux side-by-side with Windows. I remember because I installed it at the time and cursed at it for having mingled with my ethernet configuration. That server-side stuff must have come afterwards.
Another more fundamental problem about going after an enterprise-centric software market is that your development team can't get excited about their own dog food. For recent techie graduates there is likely no environment as foreign as the enterprise IT world. And at an early stage – in fact at any stage, you absolutely want developer A to be able to turn around and tell developer B that he really needs to fix widget foo because it's driving him crazy. That won't ever happen if you're developing enterprise software.
And then the financial crisis hit. The timing couldn't have been worse. We were just starting to shift into high gear when all of sudden everybody's check-book got torn from their hands by their banker. As another CEO would later tell me: “It's as if the market had literally stopped buying.” People weren't asking what was cheaper or if they should cut spending, but rather what they were going to cut and how deep they'd go. So while we miraculously did get through to 2009, we were cash-strapped and had little room to manoeuvre.
Would I do this again? Manage in a time of crisis? Sure, that's what a CEO is about. Not that it's fun or particularly rewarding to head a company in that kind of environment, but because when people depend on you it's your duty to come through. Nuff said.
Coming into 2009, we wanted to focus our limited resources on the one thing we believe could give us lots of volume, fast: resellers. So the strategy was set: we would get in touch with every reseller CEO we could find in North America to set up a short intro meeting. We must have contacted somewhere near 700 resellers. Of course you work the numbers from there. A lot don't ever respond to the email invitation (the reps did follow-up calls on those), some literally tell you to go to hell, some come through, and so on. Our offer was simple, we would give them a reseller-branded freemium they could give to all their user-base and we would share on the sale of premium licenses. At the end of the call we'd offer to create a few trial accounts for them to try it out and we'd schedule a follow-up meeting for a go/no-go. By the end of the summer, we had 10 resellers signed. That was exciting. Finally, we had found a way to get masses of users. Or so we thought. That is until we started getting into the roll-out details and logistics. This was like enterprise sales all over again. First and foremost their actual signed commitment didn't mean imminent roll-out. This was just another project that got added to their pipeline of software to deploy. Which meant we were months from practical use, and months still from actual conversion from free to paying users.
Would I do this again? Go after resellers to get an initial user mass? Likely not. At least, not before I had an established brand which made it so that the resellers' customers were already asking for my product. Or, alternatively, unless the resellers' customers already had a very specific problem for which there was no good solution out there. Backup is a good example of this. A few companies out there have been able to market backup solutions through resellers because it's a known need and this was a clear win-win-win for customer, reseller and software vendor.
Working with resellers also made me realize a few quirks of these types of arrangements. For example, anything that can make them sell man-hours on top of licenses is godsend. SharePoint, for instance, might not be the best thing for an SME to be using – simply because they don't actually need an ECM – but the VAR can sell them 100 hours of professional services to customize it to their business needs. Now that's something a VAR likes. Your software which gives them 30$/user/year and simply just works for the SME users' day-to-day has just no chance in the face of the lump sums the VAR will get from rolling out SharePoint to every one of his customers. Plus, it complements Office and comes from Microsoft. As the understanding of the perversity of this seeps in, you just want to go home and die. Microsoft in this regard is genius. Huddle, Box.net, Google Apps my a**. There's a reason social networks are popular, they bring human beings closer together. Ask yourself what feels closer to a user in an SME, the techie that comes in every week to make sure everyone's computer runs fine or the anonymous corp holding his most vital applications in some distant location accessible only from his browser – the thing he uses to chat on Facebook, get his daily jokes and watch porn. I'm sorry, everyone is up in the air with this whole cloud thing, but flesh-and-blood wins any day of the week in my book over a service I can't even call.
Posturing aside, I'm not saying things aren't moving into the cloud, they are, but my contention is that for anything that is core to a business' day-to-day operations, a flesh-and-blood human will have to be dispatchable to the SME's HQ. An SME may buy a cloud service from that human, but ultimately he's necessary for that transaction to go through. You can't disintermediate the sales rep and support guy for any major purchase.
Interesting factoid: after reading a draft of this postmortem, one of the reps remembered that upon having explained what we do and how inclusive/easy it was to a VAR he reached by phone he was told my the CEO something like “So, basically, you're putting me out of a job” and he hung up.
In parallel to the reseller front, the dev team had been busy refactoring key components (including a rewrite of the Outlook plugin), cutting the security mechanism out (we were no longer marketing it and having PGP-like symbols in every email was a major usability issue), adding sign-up capabilities for allowing us to finally allow users to sign up for trial/free account online, adding a totally new web UX that was actually professionally designed, etc. We had been getting fed up of having to wait for IT departments to roll-out our software long enough that no matter what the strategy was, the web was going to be part it. Amongst many other things, it turns out that strapping-on a web signup/activation procedure on an enterprise solution is unfortunately not a walk in the park. Plus, feedback from users had allowed us to understand that we had a slew of user experience issues we needed to weed out. So it wasn't until late 2009 that the online signup loop was out of development and on the production roll-out schedule.
Would I do this again? Wait this long to have on online signup free/trail procedure? Obviously not. I would put this right into the MVP. And, again, I wouldn't create a client-side application unless I absolutely had to. Web service with REST API is where I'd head first. An iOS or Android app would be right next, etc.
By that time the sales team was exhausted. They had been pushing themselves very hard and were only encountering setback after setback. The delayed availability of the signup very much crystallized that discontent. I can't blame them. So we sat down and had a very frank discussion about what they thought needed to change and came up with a few key action items including basic things like more rigorous QA. However, it was also obvious that more profound changes were needed. If what we did was truly indeed useful for a mass of users then we had to stop trying to get through to them through various intermediaries and if what we did wasn't lifting because it was broken or wasn't being pitched right then that too would have to be fixed.
Simple and Secure file-sharing – Q4 2009 – mid-Q2 2010
So late December 2009 we sat down and started everything back from a clean slate. What is it that we do? Why is it unique? What is really useful about this to the user? What is broken? What can be fixed? Etc. By the end of January 2010 we had a pretty good picture of what was wrong and what needed to be fixed. First, while the technology was great the UX was very poor. Second, we had to stop pitching the product as an aggregate of multiple functionalities, what it did is file-sharing; everything else was a bonus. Third, we absolutely had to go to the users directly through the web. Fourth, we set the entry point to the premium at 5$/user/month instead of 200$/user/year.
Would I do this again? Start with a high price for a premium edition? Likely not. You want to get the user gradually into paying more and more. A high premium price-point puts the user off even the free version. Plus, you do want to get to a stage where the user can expense the purchase without afterthought. Buying 10 licenses of something that costs 200$/user/year isn't something an SME is likely going to pass as an expense. At 5$/user/month no one will likely see it come through. And that's where you likely want to be.
As I said above, piercing through the cell-lining of any organization is difficult if you're going through the “official” channels. If you're aiming straight for the user, you might find your app part of the furniture before IT ever wakes up and knows you're there. At which point in time they just can't pull the plug on you anymore and need to “cope” by buying an enterprise license, and you get to laugh all the way to the bank. I hope no enterprise IT person takes this personally because I have a very high regard for every enterprise IT person I've come across, they do a very ungrateful job. Still, that's how almost everything is going in these days. I'm not sure there's any nice way to play this.
The code having been ready since late 2009, the online signup version went into full production mode in mid-February. Pretty soon afterwards the then director of sales and myself were having a conversation one late Friday afternoon when the idea came up to try using AdWords to get more people to try out the freemium. And so we did. Over that weekend alone, traffic soared and we started getting users signing up from all over the place. Over the next few weeks, we doubled-down on AdWords and started constantly tweaking our website, creating custom landing pages, keywords, campaigns, etc. And we could see the payoff in the traffic. Bounce rates were going down, singups were increasing, etc. But we still only had a few random sales here and there. Most importantly, though, we started seeing a workable pattern. X users went to the site, Y users downloaded the software, Z users activated it, P users created workspaces, etc. with N users ending up paying for the use of the service. Obviously the constant goal was to make sure the funnel kept being opened up with the aim of having N = X.
Would I do this again? Use AdWords? Absolutely. I might use it in a limited fashion to get an initial user-mass and drop it as soon as self-sustaining virality set in, but I would definitely use it. If we factor in all costs, it cost us 500$ to get a trial account when doing it with a direct sales force and 20$ with AdWords. And even that last number was raw and could have been worked on quite heavily. Basically, though, there just isn't any contest. If you're looking for users, do use AdWords. It'll cost you, but it'll also allow you to rapidly iterate into something that's pretty decent.
As another interesting factoid: with a 100$/day (roughly 2k$/month if you count out weekends) budget on AdWords, we had tons more traffic hitting the website than at any point in time we were able to generate through the use a PR firm, which cost us >10k$/month.
Beware that AdWords is pitched as being very accessible and it somewhat is, but it really has lots of layers to it. It took a few weeks to get it right and my director of sales spent quite some time delving into various tutorials and trying different things. Just make sure you appoint someone to specifically head this. It's not just a matter of putting a three-liner together and clicking “go”.
Over the 8 week period we used AdWords, however, growth remained linear. That is, while users were creating accounts, they were proportional to the money we put on AdWords and their use of it and their invitation of other parties to share with it did not result in additional accounts being created. If it occurred, it was marginal. Yet, while non-linear growth (the hockey stick) is what a startup should aim for, we had good reason to believe our user experience as it was then wouldn't allow us to achieve that type of growth.
Running out of pivots – April 2010
We had what we felt was a very solid plan for a pivot. Of course like all other pivots, there is no such thing as a guaranteed home-run, but we thought that with everything we'd been through earlier, this time we had something solid. After all, we had finally figured out a way to get a mass of users we could work on, something that had eluded us before. Plus, everyone in the team agreed that this pivot was the right thing to do, including the sales team.
We never got there though. Despite having come through at every crunch point in the past, our investors simply couldn't endorse another pivot. And it's totally understandable. Despite all our pivots and readjustments, we had been running for 4 years with no tangible sales to show. Paint it as one may, it was dizzying for anyone looking down. At best, after doing some math, we had the option of letting go of the entire dev team and keep trying to sell what we had then for another few months. But that wasn't something I could endorse. I would have either had to have been able to see the company reach break-even by then or explosive growth to occur for a third party to cut us a check. Neither seemed realistic without the planned pivot.
Shutting down
The next morning I met everyone one-by-one to tell them the bad news. Some said they had seen it coming, others were obviously disappointed. My prime concern was making sure everyone had another job to move to. I had people working there who had families, mortgages, car loans, etc. So I made phone calls to other CEOs I knew telling them I had talented people looking for jobs, provided references, helped rewrite resumes, preped people for interviews, lent laptops, etc. Anything I could do to help I did. And it paid off, everyone eventually got a job. Except me that is :) I have other plans in mind ;)
Closing up the office had an eerie feel to it. After all, this was kind'a a second home and the dozen or so souls that roamed these halls where like extended family. As they say, though, the show must go on.
I did try to sell the IP. But dead code is, well, dead. We did decide to open source it, but I haven't gotten around to taking care of that. The only thing that could have had a potential resale value was the patent applications. But these did not seem to find any suitors either. And at some point you just want to turn the page and move on.
I hesitated in fact in accepting to write this postmortem. Rummaging through the past isn't usually a good way to move forward. Still, once NextMontreal's Ben Yoskovitz asked if I'd write a postmortem I couldn't get the idea out of my head. I'm glad he asked, however, laying out what I'd want to do differently in the future has been a fruitful exercise.
Miscellaneous loose ends
Financing/MNAs:
You may have read through the above and wondered why we didn't sell before shutting down or why didn't try harder to raise capital. We did in fact have a number of discussions with potential suitors, but none came through. And we did indeed do several VC and other financing runs at different stages, and still none came through. That could be the subject of an entire other post, but essentially we fell at different stages into the odd categories for local VCs (uninteresting/saturated market, has product but no paying customer, ... ) and to top it off our ability to make a decent case coincided with the financial crisis. I was told flat out by several VCs at the time that they were conserving cash for the best companies in their portfolio and telling everyone to cut, cut and cut. Eventually we relented and resolved to go back only when we had users and conversions. If you remember anything of this post, it should be this: the asset is the user. As one VC put it: “If you had a million users, even if you weren't making any money from them I'd buy them and sell them toasters.”
Gartner, Forrester, and other armchair generals and pundits:
By all means, do keep yourself current about what “analysts” and pundits are saying about your field and, in fact, any related field. Remember, though, that no blog, analyst, pundit, or random Internet nut-case could have predicted Google, Facebook, Twitter, etc. In as far as we know, Steve Jobs doesn't call Gartner to ask them what he should be building next. In fact, I've come to see Gartner et al. as an insurance policy decision-makers buy to pad their backs on the decisions they make. You don't want to predict the future based on the brand of padding currently trending. So, while you ain't Steve Jobs (and neither am I), your best trusted advisers when it comes to where the market is going is your own gut feeling AND, most importantly, the learning you get from pivoting. Of course the more in-field experience you have the more your gut feeling will be right and the more pivoting you do the closer to converging you will be.
Branding:
The further we went into the collaboration world, the more the original company's name, “Kryptiva”, became a burden. As a matter of fact, it was outright murder when the reps did cold-calls. They had to repeat the name, spell it out letter by letter, etc. My advice is:
a) Stick to something that cannot be miss-spelled. In this day and age I know the trend is to kill a vowel or voluntarily miss-spell names in order to find an available domain name. But that condemns you to having to achieve house-hold-name-type success for the miss-spelling to become widely natural, and that's not a realistic goal. Try listening to yourself saying it over the phone or asking kids to write it down. Just having to repeat the name over the phone is bad. Having to spell it is outright atrocious. You've already got other more fundamental barriers to breach than linguistics.
b) Stick to something that's short. One syllable is best, but usually those domains name are all taken. Again, sucks, but buy that domain.
c) Stick to a “.com”. Sure, there are plenty of other “clever” word plays with other TLDs, but ordinary users will usually lump “.com” to whatever they hear about and try that site. And you've got a problem if it ain't you. Twitter's CEO, Evan Williams, paid 7,500$ for “Twitter.com”. Would they have been as successful with a “.foo”? Maybe, maybe not.
d) Stick to english words. This is a corollary to “a”. If you invent your own brand, you're likely going to have it miss-spelled or mispronounced or asked for spelling it ...
e) Try to find a clever combination of words that conveys what your product does. “Dropbox”, for instance, is a good example of a word combination that is hard to miss-pronounce, miss-spell and yet still already gives a hint about what it's about.
f) Make sure you reserve that name across all namespaces you can find at that time: twitter.com, facebook.com, etc. You don't want to have the “.com” while someone else owns the Twitter feed.
g) Make sure there isn't a conflicting USPTO trademark already assigned to your name and do immediately file an application for the use of that name in your field. This is an insurance policy as I described earlier.
Ok, sure, this all makes it sound like you should have a “boring” name and that you'll pay a lot of money for your “.com”. But if the boring part makes your speech that much more fluid and that expensive domain means you're easy to find, these will be two things you won't have to work on. And you've already got a ton of other things to figure out.
Leadership:
I haven't covered much of what I learned about leadership above. That too would warrant an entire other post. I've discovered that the key to getting things done is to incentivize; and I don't mean money. You need to understand why someone working for you is going to not just want to but will be passionate about having to do something that needs to be done. As an employer the cash carrot will only get you so far. People don't work just for money. They work for accomplishing meaning, for having fun, and, sometimes even, to conquer inner demons. Your job is first and foremost to listen. Once you've started tuning in to who they are and what they're seeking, you need to match that to what needs to be done, give them a great work environment and let them take it from there. This is an organic and cyclical process. Listening also includes taking into account the team's opinions and points of view; you don't have to numbingly execute something you and the rest of the management team or the board has decided. And if you do these things well enough the team will reward you with their trust and, therefore, grant you the ability to occasionally impose your vision despite their disagreement. But that trust must be earned. Most anything you read in the press or the history books about visionary and charismatic leaders is hogwash. I don't often cite scripture, but Jesus is said to have washed his apostles' feet (i.e. leadership is also about being at the service of those who service your cause.) And part of this trust will require showing the exit to those who either no longer have the passion, no longer serve the needs of the company or aren't fitting in, no matter how you may personally feel about them. You'll have done a great service both to those leaving and your team. Mark Suster's wrote a nice TC post on being a CEO entitled: “My Life As A CEO (And VC): Chief Psychologist.”
Generally, bare in mind that what you're reading here is a summary. If you've ever led a startup you'll notice there are entire chapters missing from this account, and that is by design. I believe, nevertheless, that the above stands on its own and provides a fairly level-headed view of what happened. Obviously all forward-looking statements are my personal opinion.
In closing
Two facts remain forever burned in my mind with regards to my tenure at Kryptiva: 1) I wasn't able to bring my investors' money to fruition, and 2) I missed out on a lot of my children's early years. Some things one can do better on a next run. Some things there are no two runs at. And that includes great opportunities. Life is such and that's what makes it beautiful. I certainly would have hoped for and, most importantly, have put every effort in getting to a different outcome. I have no regrets. Just a crave ...
In summary – in no particular order
What I would do again:
-
File trademarks
-
Being uncompromising about hiring policies
-
Hiring industry veterans
-
Execute major pivots
-
Manage in a time of crisis
-
Go directly to the user
-
Use AdWords
-
Help former employees in case of failure
What I'm undecided about:
-
Hiring an industry veteran specifically for a GTM
-
Coming up with an off-the-wall UX or paradigm
What I'm unlikely to do again:
-
Use a complex client/server architecture
-
Create/push a security product
-
Use NDAs or apply secrecy requirements
-
Use a PR firm for a startup
-
Continue being heavily involved as a techie deep into development
-
Trying to pursue a volume sales strategy as a first offensive
-
Trying to penetrate the enterprise market
-
Trying to sell software through resellers
-
Start with a high price point for a premium edition
What I wouldn't go for again:
-
File patents
-
Use an outside firm to help find/plan a GTM
-
Not build the MVP first, foremost and ASAF'nP
-
Provide any assurances regarding milestones or company purpose to hired personnel
-
Wait a long time into the company's lifetime to pitch VCs
-
Take a long time in aggressively going after customers and get a sustained feedback loop back to the dev team.
-
Take a long time to get an online signup form
