olivergajek

This is a long and complicated topic. I’m oversimplifying things dramatically here.

The basic rule to consider is this: You get VC when you don’t need it and you might not get it when you do. 

Specifically:

1. An investor loves to invest in a company that basically knows what they’re doing and where there are strong answers to the primary questions around team risk, product risk, market risk. A good way to answer these questions is sustained, profitable, and growing revenue. In which case you don’t need the investment to survive. But you can use it to grow faster.

2. If you do go for a VC investment and it’s the strategy you have and there is no Plan B then that will be immediately obvious to a seasoned investor. And will either drive down the valuation or, more likely, dramatically reduce your chance of getting any investment at all.

There is a lot of value in getting some kind of board of directors or advisory board in place as early as possible. Somebody needs to tell you when you’re messing up.

More importantly, somebody needs to tell you when you’re doing a great job. Without the board life can get very lonely.

Your ability to get the right kind of people to sign up for this is also a good early indicator for your ability to attract employees, customers, investors, partners. 

Personally I’d recommend a three people setup at the beginning, minimum two, maximum four. 

For a more systematic view on this topic you may want to look at Brad Feld’s book on Startup Boards.

This one is pretty simple. Pick a (good) lawyer and stick with them. Switching lawyers generates huge overhead on both sides and you don’t have the time or the money for that. 

Corollary: You don’t have to pick the same law firm for all your legal needs. You will probably need to cover separate disciplines (corporate, trademarks and patents, and most likely also IT law) and I’d much rather work with specialist boutique firms for each discipline. 

Better finish the Ten Commandments posts before somebody beats me to it. So here goes.

“Thou Shalt Not Be German”

Meaning two things:

1. Don’t overengineer the product before you introduce it to the market. Of course a beautiful architecture and a rich feature set are wonderful things to strive for. But you won’t know what customers really want until you have put something in front of them and tried to get them to use it and pay for it.Note that this does not mean selling stuff that doesn’t exist (those days are mostly over) or shipping embarrassing crap. 

2. Don’t overestimate your market potential in the German market and don’t underestimate your market potential internationally. Chances are that your product is early and incomplete and therefore mostly relevant for early adopters. Of which there are a disproportionately low number in Germany, a notoriously conservative technology market. Make sure you can address early adopters wherever they are. 

Oh boy this blog is getting stale. Let’s see if this ever improves. In the meantime, for the record, my very sparse reading list for Q3. Baseball and other things must have kept me away from the bookshelves.

Tim Moore: Travels with my Donkey. Funny. 

New commandment: Thou shalt blog more often. Just kidding.

This is a good one, comes to you from the folks at Netscape: Find a parade and jump in front of it.

Meaning that whatever you do should be connected to a bigger thing that’s currently going on. People are gathering in the street and are beginning to march. More precisely, a topic is being recognized and buzz starts to build.

Examples, not necessarily the best ones, would include topics such as Big Data, Enterprise Social Networks, Next Generation Firewall, Zero-Knowledge Encryption, etc.  

You want to be at the stage where the people who are always too early have begun to lay the groundwork. And where normal people, especially potential customers, are beginning to want to figure out what this all about. And then you assume a thought-leadership position and try to shape and brand the discussion.

Note that this requires more than inventing a three-letter acronym and declaring yourself the leading provider thereof.

Why is this important? If there is no parade, meaning no early evangelists, no start-ups entering the market, no end-users with the nagging perception that they need to learn more about the topic, then there may just be no market or you may just be too early.

There are two separate aspects here.

First, know your user. For what job do they employ your product. Here you have to think about product, not feature. And about the specific benefits the user will be receiving from your specific products. And what other options they would have that you compete against. 

You will also have to think about what is the “whole product” as defined by Geoffrey Moore. This will be different depending on market segment and on segment maturity. 

The other aspect that you will have to think about is the organization that the user is a member of, particularly if you sell to businesses? What is the buying center? How do they make decisions? Who will be a positive influencer, who will stand in the way? This varies greatly based on organization size, vertical, geography. You have to understand the mechanics here, preferably based on personal experience and not just hearsay. 

I got a lot of reading done. No baseball and no football really helps.

This sounds obvious, but it is surprisingly hard. Technologists often start with a “wouldn’t it be cool if…” approach or they just fall in love with a particular piece of technology or maybe just an algorithm. Nothing wrong with that.

But now you have to switch your focus to the customer. Which product will your technology (we’ll call it a feature, because that’s mostly how things start out) be embedded in? And a product is something that usually has a price and some kind of description. And some kind of competition, either direct or via a substitution scenario. 

Useful exercises include drafting a product sheet that describes features and benefits and a price list that describes how the product is paid for. The Product Box exercise is also particularly useful to find out how to position various features and benefits with respect to each other.

Note that this is relevant even if you were not to build the product yourself, e.g. because you license the technology to somebody else. They will then have to answer these questions as well.