Amit Rathore's blog about software and startups

Just finished reading Viral Loop. As we think about the distribution side of things for Zolodeck, I figured it couldn’t hurt to read about how a bunch of companies achieved massive scale.

It’s a good read… and certainly describes how things were done at companies like Hotmail, Twitter, Facebook, Hot Or Not (remember?), Bebo (remember?), MySpace (remember?), eBay, Flickr, PayPal, and even Tupperware (yeah, really).

It isn’t, however, a book of recipes. I didn’t really expect a book to be able to just tell me the 10 things I can do to fix distribution, I guess, and on that count the book was merely describing how awesome it is when you do achieve massive scale. Not how to get it.

Still, a very decent read, and did trigger a few thoughts for what one can do to address this. A lot of people in the startup space know this already, but it’s been sinking in for me more and more over the past few months: distribution is the more important of the two key things a startup needs to solve (the other being product/market fit, or product in general). And also that distribution is the harder of the two problems, and more than product, it is distribution that will make or break the company.

As I said, we’re thinking a lot about this for Zolodeck… and since this is so important, we’re erring on the side of over-measuring things to ensure we can keep a pulse on what the distribution story is looking like. What else can one do at such an early stage?

Logging is an obvious requirement when it comes to being able to debug non-trivial systems. We’ve been thinking a lot about logging, thanks to the large-scale, distributed nature of the Zolodeck architecture. Unfortunately, when logging larger Clojure data-structures, I often find some kinds of log statements a bit hard to decipher. For instance, consider a map m that looked like this:

When you log things like m (shown here with println for simplicity), you may end up needing to understand this:

Aaugh, look at that second line! Where does the data-structure begin and end? What is nested, and what’s top-level? And this problem gets progressively worse as the size and nested-ness of such data-structures grow. I wrote this following function to help alleviate some of the pain:

Remember to include clojure.pprint. And here’s how you use it:

That’s it, really. Not a big deal, not a particularly clever function. But it’s much better to see this structured and formatted log statement when you’re poring over log files in the middle of the night.

Just note that you want to use this sparingly. I first modified things to make ALL log statements automatically wrap everything being logged with pp-str: it immediately halved the performance of everything. pp-str isn’t cheap (actually, pprint isn’t cheap). So use with caution, where you really need it!

I’ve been reading Paul Graham’s essays for a long time: since 2001, when an old friend introduced them to me. I was excited by the way he writes about startups and what startups can accomplish. In my head, startups are like the Rebel Alliance, with the odds heavily stacked against them, and they battle the various Death Star corporations for a slice of the business, to institute a smarter way of doing things.

I was also heavily influenced by his articles on Lisp, particularly this one. It’s why I started playing with various Lisps, and why I was so excited by Clojure, and why I wholeheartedly embraced it.

But this post isn’t about technology. It’s about the Rebel Alliance. It’s about two guys in a makeshift office, in the proverbial garage somewhere. Startup statistics can be quite depressing, with 19 of every 20 startups doomed to failure. With such a low rate of success, how do the successful ones do it?

I remember reading this article by Paul Graham, and thinking it makes sense. I remember it making sense in a very superficial, non-committal sort of way. The core of the statement: “Make something people want” seemed perfectly obvious to me. How could you succeed if you didn’t make something people wanted? Duh. Right?

I’ve been spending a lot of time thinking about Zolodeck, the depth of this idea is actually hitting me quite hard. There are two parts of any tech startup: the product side, and the distribution side. The product side is about finding the product/market fit, about making sure the experience is right, and that what you charge for the product is more than what it costs to make. The distribution side is about customer acquisition. Obviously, there’s interplay between the two sides.

“Make something people want” is a simple recipe for success. It seems to distill everything the Lean movement talks about into a single sentence: is your startup making something people want? Everything else is details (of course, the devil is in the details, and you need the details to succeed). In the end, you have to collect and collate the metrics that will point you to what it is that people want, and that will tell you how and what your startup should be doing. But the overarching guiding principle is very sound: make something people want.

And yet, a lot of startups fail because ultimately they don’t end up building something that enough people find value in. Or perhaps at a cost that was lesser than what they could charge for it. Making something people want doesn’t mean that if you build something incredibly powerful and useful, but at a gargantuan price, you’ll succeed. The something you build for people needs to solve an equation that involves cost, price, scale, and utility.

So back to the two guys in their garage. If you’re a tiny startup (in reality or in spirit), you can greatly increase your chances of success by using this mantra as a guiding light: make something people want. And make use of Lean metrics to see if you’re trending towards a success or failure. I really do believe that if done right (pick the right metrics, and make adjustments based on what they say), a startup can succeed. And given the stats on startups, this is a bold claim.

I plan to share our Lean metrics dashboard and overall progress as we continue to work on Zolodeck. I think of it like a public experiment. Hopefully, we’ll discover something of value, and others can benefit too! Go Rebel Alliance!

There is a spectrum of productivity when it comes to programming languages. I don’t really care to argue how much more productive dynamic languages are… but for those who buy that premise and want to learn a hyper-productive language, Clojure is a good choice. And for someone who has a Java background, the choice Clojure becomes the best one. Here’s why:

The Java library ecosystem – what logging framework to use? what web-server? database drivers? And on and on….

The Maven situation – sometimes you have to know what’s going on underneath lein

Understanding of how to structure large code-bases – Clojure codebases also grow

OO Analysis and Design – similar to figuring out what functions go where

I’m sure there’s a lot more here, and I’ll elaborate on a few of these in future blog posts.

I’ve not used Java itself in a fairly long time (we’re using Clojure for Zolodeck). Even so, I’m getting a bit tired of some folks looking down on Java devs, when I’ve seen so many Clojure programmers struggle from not understanding the Java landscape.

So, hey Java Devs! Given that there are so many good reasons to learn Clojure – it’s a modern LISP with a full macro system, it’s a functional programming language, it has concurrency semantics, it sits on the JVM and has access to all those libraries, it makes a lot of sense for you to look at it. And if you’re already looking at something more dynamic than Java itself (say Groovy, or JRuby, or something similar), why not just take that extra step to something truly amazing? Especially when you have such an incredible advantage (your knowledge of the Java ecosystem) on your side already?

Editor’s note:Cherian Thomas is founder and CEO of Cucumbertown, a recipe-publishing platform. Follow him on his blog and Twitter.

For entrepreneurs, it is now both easier and harder to raise capital: easier because of powerful platforms like AngelList; harder if you’re not part of an accelerator or don’t have a strong network.

Silicon Valley has more startups than ever before. My startup, Cucumbertown, raised its first round a month ago, and during the course of this journey, I realized that, as a first-time entrepreneur without any solid Valley footing, my run toward raising funds as a non-American co-founder was somewhat unique.

Valley funding used to be an impenetrable fortress that opened up only by way of introductions. Your success in raising capital decreased to insignificant levels otherwise. The only other chance to make yourself noticeable was traction, which trumps everything. But the market dynamics of fundraising is shifting, and investors are no longer clustered in the Valley. Accelerators are becoming the showcase for promising startups. I was initially disappointed when a VC told me their firm only focuses on YC companies. But then I realized it makes more sense for them to look at YC, 500Startups or TechStars than to sift through hundreds of decks. These accelerators are becoming the entrance exams for selection.

So here’s how my month of experience as a non-accelerator, non-American fundraiser translates into advice.

Make Friends Fast

I was scheduled to meet 500Startups Partner Paul Singh on the second day of fundraising. As I waited for my appointment, Courtney Powell, CEO of PublikDemand, asked me about Cucumbertown. We became friends within the hour. The PublikDemand team invited me to crash at their home and Courtney taught me everything she knew about fundraising. We continue to meet whenever I am in the Bay Area. Courtney even re-wrote my press release notes.

After I read Darius Monsef’s article on TechCrunch, I contacted him, and he put me in touch with Rajiv Bhat, co-founder of YC alumni Mertado. Rajiv advised me on everything from convertible caps to living life as an Indian founder in the Valley. Nowadays Rajiv and I meet frequently here in Bangalore to track one another’s progress. I even bake for him.

Cucumbertown’s first investor and the co-creator of Farmville was Sizhao Yang, and we became great friends. He also offered constructive criticism of Cucumbertown. Every now and then Zao mails me one-liners reflecting something on the industry worth understanding. Zao now is my 1 a.m. friend/investor on call.

Cucumbertown’s most important advisor and friend is Naval Ravikant. He responds to every email and takes action when necessary. He even follows up. When Naval said stop, I stopped. When he asked me to meet him at AngelList HQ in San Francisco, I changed all my other plans.

These people represent only a fraction of the relationships I built in less than a month, and they represent the change in Cucumbertown’s trajectory to success.

Meet With Companies Who Have Raised

It’s also important to meet with companies who have recently raised. They have a wealth of tribal knowledge that can help you save time. For instance, I met with a company that closed its funds in October, and they advised me about the shift in investors’ herding mentality due to the September YC Demo day this year. This was a wealth of information, as I was able to strike a number of investors from my potential list.

Get On AngelList

AngelList is powering the Valley’s revolution in investing and raising funds. During one of my lunches with an investor, he said that raising funds for the first company he co-founded was near impossible. And raising series A was much more difficult than that. His company’s investors played waiting games and did not introduce the company until their contacts came into the picture. He said shady acts like this frustrated him as an entrepreneur.

AngelList changes all of that and is perhaps the most important tool you’ll need as an entrepreneur raising capital. It is the canonical source of all things related to angel funding in technology now. Never has Silicon Valley been in a position where every investor and fundraiser could e-meet at a platform.

Cucumbertown represents a first-time investment for Mokriya‘s CEO Sunil Kanderi and partner Chandra Kalle. I met them during a growth hacking conference in San Francisco, and they expressed their desire to be connected to Cucumbertown. Our profile on AngelList, our existing investor list there, and our testimonials offered the credibility we needed to gain their trust. And investor Stefano Bernadi followed us out of the blue on AngelList and subsequently invested in Cucumbertown.

Here are some things I learned to be successful on AngelList:

Build a concise and compelling profile.

Make it equally good for your team, too.

Follow investors early on, even during your idea incubation stage, to understand their modus operandi.

Follow partners at VC firms to understand the deals they are seeking. You can view their activity stream.

When you get your breakthrough investors, immediately connect with their connections and start the conversations (AngelList allows you to talk to connections of connections).

Showcase your strengths in the status messages. Don’t overdo it.

Respond to everyone who initiates a message with you. But once you start calendaring in people become selective in appointments.

Get your investors to write testimonials for you.

Almost every company listed there is exceptional. Being different is difficult. But seek the difference.

Silicon Valley works largely by clustered investments. Your company would have always had a chance of being invested in by people who knew each other. And limited by them, too. That has changed with AngelList.

Calendar Every Meeting

I met 28 investors/funds over three weeks, and more were scheduled. The Valley is flooded with investors, and it can get pretty overwhelming once people start responding. Keep it organized and calendar all meetings. The executive assistants for most of these investors will reschedule your meeting at least three times. You have only once chance, so be prepared to move around.

Learn To Say No

As tempting as it was to accept capital from anyone — especially with the uncertainty of the future looming over our heads — we said no to investors who did not align with our thought process and principles. It was difficult. But we sleep well today. My new best friends in the Valley taught me this quality, as well.

Maintain Heat

The Valley has more startups now than ever before, and investors are bombarded by a hundred pitches every week. You are as valuable to them as the other 99 and so are likely to get lost within three days. Be proactive in the conversation, and try to get a response in a week.

Fundraising is a game. If you know you have a good product/team/traction, then get in to win. You are already here because you believe in something. Continue the journey to win. Persevere.

Thanks to Maneesh Arora, advisor and investor in Cucumbertown, for the draft review.

[Disclaimer: 500 Startups is an investor in Cucumbertown. But we are a non-accelerator investment. Though Naval is AngelList’s co-founder Cucumbertown did not benefit any special status. Cucumbertown wasn’t a featured startup or did not show up in the trending list. Dan Hauk is Cucumbertown’s American co-founder. But Dan was not involved in fundraising. Cucumbertown is a distributed startup and none of us co-founders have seen each other. I travelled to the Bay Area to raise funds.]

The function definition for pmapcat above, does what mapcat does, except that by using pmap underneath, it does so in parallel. The semantics are a bit different: first off, the first parameter is called batches (and not, say, coll, for collection). This means that instead of passing in a simple collection of items, you have to pass in a collection of collections, where each is a batch of items.

Correspondingly, the parameter f is the function that will be applied not to each item, but to each batch of items.

Usage of this might look something like this:

One thing to remember is that pmap uses the Clojure send-off pool to do it’s thing, so the usual caveats will apply wrt to how f should behave.