The hazards of working for an Israeli startup
I was driving to work when the sirens started. This is how Israel’s Road No 1, aka “Jerusalem - Tel Aviv Road” looked when everyone stepped out of their cars to take shelter:
This is me, taking shelter behind my car (give me a break, the sun was in my eyes):
And then I saw two amazing Iron Dome rockets fly up from right next to me, intercepting two rockets on their way to Tel Aviv. Advanced tech to the rescue!
Then I proceeded to work, just another day in an Israeli start-up. Fucking war.
Meeting Eric Schmidt, Insights about Scaling a Start-up
One of the great things about Soluto is that we’re backed by an excellent team of investors, ranging from big-name VCs to private current and former senior executives in various companies. One of our investors is Eric Schmidt, Google’s chairman, through his personal fund (called Innovation Endeavors) that he founded with Dror Berman.
Eric recently came to visit Israel, and between meeting our prime minister and our president, came to listen first-hand to the start-ups he’s invested in (a total of 8 start-ups in Israel). So we all gathered in the new beautiful offices of BillGuard, our neighbors on Silicon Boulevard and presented who we are and what we do to Eric.
It felt like our presentation went really well, with Eric asking various super-smart questions, and after we finished, he raised one point that I think is worth sharing. He asked (I’m using my own words here, but the key message is the same):
What in your service is so special that it’ll push to scale? What inherent property of your service is such that as you grow, you will grow more and more? Because if you cannot find such a property, then all you’re counting on is luck, and luck doesn’t scale.
I gave an elaborate answer. I talked about focusing the company’s efforts on creating such an experience that will compel users to share the news about this amazing service with their friends, and how we believe this experience a user goes through is what differentiates great scalable services from those that remain, well, meh.
This answer sucks. Not because it’s not what we’re focusing on, and not because it’s wrong. But because it’s generic. And by being generic, it missed the depth of the question. About 15 minutes later I was excited to realize I actually have a great answer, but by then it was too late to chase Eric and correct myself (and it would have probably seemed super-lame if I did).
I don’t want to focus on our own specific answer (although it’s REALLY great), but rather on some insights I had while thinking about the question, and understanding a) how brilliant this question is; b) how important having an answer is and c) how brilliant Eric Schmidt is (and this is not ass-kissing, he has already invested..)
If you ask me, the single most important factor in the success of startups that became immensely successful is, put simply in one word, luck. If you want two words, you can take Good Karma. I’m talking about the likes of Facebook, Skype, Dropbox, SalesForce, Google and others. This luck usually manifests itself in the form of amazing timing between the market and the company, usually around some technological or psychological inflection point.
For Google the inflection point was related to a change in advertisers’ perception of the web as a viable channel for ad communication, combined with a growing number of consumers searching for stuff on the web. For Skype the inflection point was related to the width of the “Internet Pipes” globally. For SalesForce it was a combination of more and more businesses understanding the benefits of CRM, combined with a growing completexity and cost of “on premise” CRM solutions. For all the companies I mentioned you’ll be able to find other companies who did practically the same thing a couple of years earlier but never reached massive scale, and another bunch of companies who tried to do the same a year or two later, but again weren’t able to reach massive scale. A short disclaimer - some companies succeed without riding such an inflection point, but those are usually moderate successes (give me one example of a tech company that reached >$50B value without it).
So I think luck, usually in the form of timing, is the main differentiator for growing huge. However, there are several points to make here. Luck is certainly not enough, and most of those companies who reached massive scale had:
1. A strong product that solved a huge market problem.
2. The ability to listen to the market and maneuver accordingly.
3. Great ability to execute - build stuff fast enough and at a sufficient level of quality.
4. A technological solution that is far from trivial, especially at scale.
The list above is what I thought before Eric’s question. But Mr Schmidt added another, fifth point: 5. An inherent property of the service that pushes it to scale.
Let’s try to analyze the this point for the companies I previously mentioned:
- Google: I’m not familiar with the details of Google’s original search algorithm, but I believe one of The initial important factors was user-clicks on search result pages. In other words, the more people used Google, the better the results got, which led to happier users, which led then to tell their friends, which meant more people used Google, etc..
- Facebook & Skype: those are easy. Whenever you can detect a “network effect” you have such an interest scale property.
- Dropbox: many people believe that Dropbox’s massive scale was caused by its brilliantly executed referral plan, designed by Sean Ellis. But still, what underlies that? Maybe people’s willingness to go to lengths in order to get more free storage? What is so special in storage? Can this be replicated everywhere? Probably not. So I’m not sure here, I’ll invite Sean to answer…
The key insight for startups here is -
Think about your own product/service. Does it have an inherent property that’ll push it to scale? If not, are you ok with it? Or should you go searching for such a property?
Of course there are many differences between startup fundraising and Nigerian email scams
A brilliant article about lessons to be learned from Nigerian email scammers:
Essentially, scammers face an optimization problem. Touching a huge number of potential victims is easy. The real cost is the time spent converting a prospective victim into an actual victim. The scammer has to spend time to build the victim’s confidence to the point where they wire some amount of their money to the scammer. The opportunity cost here is massive. Spending time on a prospect that ultimately gets cold-feet is the worst possible outcome for the scammer. Not only did they fail to collect any money, but they wasted a bunch of time getting a “no.” The longer that victim took to ultimately back out, the higher the scammer’s cost. Since time is a real constraint, finding a way to steer clear of people who start a conversation but won’t ultimately send money is just as important as nurturing the rare victim who will end up handing over his or her cash.
Now, re-read the preceding two paragraphs, and replace the word “scammer” with “entrepreneur”, and the word “victim” with “investor”.
I’ll wait while you do it.
Why founders should not hire a Product Manager
In the past years I’ve been meeting many founders before they raise money, to help them around product, marketing and generally what’s important and when. One phenomena I keep seeing is one of the founders will ask “where can we find a good product manager?”
My answer is almost always “You don’t need a product manager. The product is the most important thing you’ve got to deal with right now, so one of you should do it.”
This may seem a shallow point of view, so I’ll elaborate on the insights behind it.
When you found a startup, there are important things and unimportant things. On another dimension, there are things that require lots of actual work (like coding), and things that do not require lots of actual work (like defining your marketing strategy). Surprisingly enough, in most cases at the very early stages of a startup, what’s important is what actually requires lots of work.
For most startups in that position, there’s nothing more important than product. You need to code it, true, but what “product” means is “what do we code?”
I often encounter two archetypes of founders who will ask me about hiring a product manager:
1. Coders who can write great code, but don’t know what they should do, so they are looking for someone who will tell them what to do.
2. People with business background who have no idea how to build products, and are looking for someone they will explain “the vision” to, and he will make it happen (while they masturbate around big words like “go-to-market strategy).
To the first group (coders) I say: if all you know is code, you’re not good enough founders. You need to think about your users, imagine their pains and needs, build it for them. Become the product managers. Or alternatively add another co-founder who can bring that skill to the founding team. The first product manager in a startup must be one of the founders.
To the second group (suits) I say: if you can’t build anything, you have no justification to be calling yourselves founders. a key skill for the founding team is to know how to build the damn thing, and if you cannot, it means the investors’ money will be spent on your salaries while you contribute nothing but big words (in reality I use much harsher words in those situations, but I don’t want to make this post NSFW). Don’t get me wrong, the business side is critical to the success of startups, but 1) mostly at later stages and; 2) Too often I see a group of 3-4 founders who have no idea how to build stuff, expecting they can outsource everything including the product side. Granted, sometimes those people succeed, but then it’s not interesting.
So if you’re building a startup, ask yourself which of the founders can be a great product manager. Build your thing, raise some money, and when that product-founder simply cannot do enough product work because he spends 13 hours a day doing something else that’s more important, then hire a product manager.