Startup Lesson: Your Technology Is Not Your Business

Jevon MacDonald's "How Startups will save Venture Capital in Canada" identifies the lack of a sufficient number of startups as the core problem in Canada's VC/entrepreneurship ecosystem. I have to agree with him in that the major challenge in Canada is the lack of a sufficient number of fundable startups. Being fundable doesn't mean that the startup will actually need to raise money, merely that the startup has identified a real customer need, and has a plan to capture the opportunity in that market.

Unfortunately, many entrepreneurs in the Web 2.0 world currently suffer from an obsession with technology. Instead of generating a business model, identifying paths to market, or validating assumptions, many tech entrepreneurs are focusing on choosing one technology over another and being buzzword-compliant. Building a startup in this fashion is kind of like creating a superhero who has lots of cool powers and gadgets, but neglecting to create a back story that explains to the reader why the hero is driven to fight crime. If you're this company, you're Batman – except your parents weren't murdered in front of you as a child by The Joker, and you had a relatively happy and fulfilling childhood.

Instead of focusing on technology, a startup (or any company for that matter) needs to focus on its business case. Clarifying the business case can be grueling, but at its core it only really requires good answers to a few key questions:

1. What problem will your startup/product solve?
2. Who has this problem?
3. How are they currently solving this problem?
4. Who else is solving/has solved this problem?
5. How are you different than any of the other solutions?
6. How will you make money from providing this solution?

This is the usual point in the article where I provide a personal story to illustrate my point. So, not wanting to disappoint, here we go:

The first product I worked on as a product manager was quite possibly the most boring piece of software ever created. It was also extremely lucrative. It took one programmer, one QA person and me to build, test, and market it...yet it retailed for $7500 for a 2-CPU version (yes, it was licensed on a per-CPU basis). While I can't provide insight into the revenue for the product, the company I worked for publicly disclosed revenues over the four years I worked there in excess of $100M on a product line consisting of only a half dozen products. Suffice it to say, a non-trivial percentage of that $100M could be attributed to this product. The return on investment on the product was well over 1000%. While this product wasn't a startup in and of itself, its revenues would put many startups in Vancouver to shame.

What was this magical money-making software? Well, it was a command-line encryption utility. It took files and encrypted them, or took encrypted files and decrypted them. That's it. It featured no graphical user interface, and used a dozen different standard public domain or otherwise open/standardized cryptographic methods to secure the data.

Any software engineer or technology-centric entrepreneur that hears me talk about this software is instantly horrified. "Why would anyone buy this software? And for $7,500?!? Why not just use a copy of GPG (a free, open source program that does exactly the same thing)?" The problem with an engineer's response to this is that it focuses solely on the software itself. But nobody just buys software, they buy a solution to a problem. The totality of that solution is not limited to technology, but also includes knowing the customer's motivation, how much the solution is worth to them, where they look for solutions to problems, and even where they go to buy. All of these pieces fit together.

So why was this software successful? Why was it able to charge so much?

• Urgent problem: Enterprises regularly transfer large amounts of data between themselves and their partners and have built systems to automate these transfers. However, over the past five years enterprises have faced an explosion in the number of federal, state, local, and industry mandates requiring them to protect confidential business, financial, customer, and employee data. Given the alternatives (negative press, lost customers, fines, loss of license to operate, prison), companies wanted a solution that could secure these data transfers, and they wanted it fast.
• Well-defined target customer: At a high level, the customer for the product could be anyone handling large amounts of sensitive business or customer data. However, the nature of the laws governing data privacy made it very easy to be more specific - financial services companies. Anyone in financial services had standardized on FTP for large data transfers, and now stood at the intersection of a large number of very scary industry and government mandates that required them to protect customer, employee, and financial data. So, there was not only an urgent problem that needed to be solved, but customers with lots of money who were willing to pay for software that solved that problem.
• Over-priced, aging existing solution: Interestingly enough, the customers already had a solution in place in many cases. However, the company providing that solution had sold off most of the core assets and was running a minimal skeleton support team. Customers were annoyed because problems weren't getting fixed, and there was little indication that they could continue to rely on the solution to continue functioning on newer platforms. The existence of a solution was useful for two reasons: it validated that there was a problem that needed to be solved, and it told us how much customers were willing to pay.
• It came from someone they trusted: The company I worked for was a well-known information security brand, and had been for nearly a dozen years. Most people in IT would have used early versions of this company's software while they were in college, and hence it was the first company that came to mind when they started looking for a data security software product. While it is unusual for a startup to have a known brand, technologists often overlook the inherent value of marketing. If no one knows your solution exists, or knows the unique capabilities it provides, it doesn't matter if your solution has inherently better technology or not.

To summarize (using this handy format): The product provided a command line encryption utility that secures large data transfers for enterprises, such as financial services companies, that are subject to regulations requiring them to protect sensitive data from unauthorized access. Unlike competing solutions, the product provided an up-to-date, supported solution that integrated easily with existing data transfer solutions, and came with the commitment of ongoing support from a leading information security software provider.

Jevon is correct that the required solution is for Canadian startups to start hustling, and that hustling means building viable businesses. When you can answer the six questions I outlined above in a succinct manner, and back up any claim you make with hard facts, you've got yourself a viable business.

Congrats - now get back to work!