We struggled a lot with three failed ideas and were on the verge of bankruptcy by the end of 2010. I remember how sometimes I used to curse the startup life because nothing really was working, but it taught us two great lessons.

a) Trust in co-founder(s): You know whether the person is a coal or diamond only when subjected to stress, and bootstrapping provides a lot of opportunities for that. When you’ve a viral product or backed by a big investor with lots of money in the bank, it’s a great situation to be in and everyone’s happy. The real character is hardly known because every thing is going well and everyone’s happy. It’s when the boat is about to sink, the real person comes out and you instantly know whether you want to continue to work or not. This is a critical decision that can almost make/break the company.

b) How to use money: When you bootstrap, firstly it’s your hard-earned money that’s being invested and secondly it’s limited. This intrinsically gives you the habit of using it wisely and frugally. Even after being funded, we’ve never done anything outrageous. We’re a little better now with a beautiful office space, in-house cook, etc. but haven’t done anything extravagant or lavish. The frugal lifestyle always keeps a check on us.

Bootstrapping gives you the strength to handle anything that comes your way.

We were a 2-member team, went up to 6 people and then back to just the two of us all within a short span of 3-4 months. All our first hires left us to do something on their own. CodeSprint-2 was round the corner and we had invested quite a lot in marketing with companies like Apple participating in it. We had made big plans during the contest with the team and suddenly you find none around except your co-founder. I still remember the dreadful night but we continued working and CodeSprint-2 was a massive success with lots of job offers made, some being international as well. The only reason why we were able to put the situation behind and continue was the strength and confidence that the early bootstrapping days gave us. We were in similar/worse situations earlier. Hari is much better than me in handling such situations but I don’t want to talk about him here in fear of making this post border on cheesiness or embarrassing him.

That episode is over and we’re now a strong engineering team comprising of Shiv, Akshay, Sushil, Rohan, Chakra, Mike (2 more guys and a girl in the final stages) and enjoying every bit of it.

I remember PG telling about how not to die as a startup where he mentions two key points – founders split and/or running out of money. Bootstrapping is a magical hack that if not prevents, at least gives the strength to overcome both of them.

Nothing has really changed in our attitude towards Interviewstreet. We’re still scared of losing a customer (big/small), we still want to provide them the best and many more things that we started with have remained the same irrespective of the changes and the hype in the external environment. And so, I found out that it’s just a new chapter with different parameters but with the same highs & lows testing the strength of the founding team and the bank balance.

This post actually makes me think if the probability of startups succeeding is higher if they are able to bootstrap long enough till they actually need external funding rather than going in chase of money right at the start.

[1] Smarter e-mail

E-mail is hell and it sucks away a lot of productive time. As you grow higher up the ladder, it’s almost poisonous since you tend to be always on and not much of “real work” gets done. This e-mail system should be intelligent. For now it can just be a plugin but it should have the ability to

a) Pause e-mail: I should be able to set a timeframe where I don’t want to get any mail on my inbox unless it’s from a really important person. What constitutes a really important person is the AI logic that needs to be coded. It can be a combination of how frequently I mail the person, linkedin connect degree, importance of the person at this moment (for eg: if we’re doing a Quora CodeSprint that week, any mail from @quora.com is high priority that week), etc.

This helps me allocate a chunk of time that I can spend on “real work” and once done, I can batch process the mails.

b) Auto-send canned replies: Things like ‘What’s your office address?‘ or ‘What’s your phone number?‘, etc. don’t necessarily need my intervention. The e-mail system should be able to automatically send those responses.

As you go higher up the ladder, scheduling meetings is a big pain and normally the assistant looks up the calendar, suggests a couple of time slots for you to pick. Again, the effort of an assistant is not needed. The e-mail system should be able to fetch my calendar schedule and automatically suggest times during which I’m free to meet.

There are many more processes that don’t need the my intervention at all and can save a lot of time (and task switch most importantly!)

[2] CEO dashboard

However easy, analytics tool might be, there’s always a need to use at least two of them (eg: chart.io and mixpanel) This has in fact been a common topic in the YC groups and most of them have resorted to building custom dashboards. This analytics tool or the CEO dashboard should work at the apache/logs level (lower abstraction).

Once this tool is installed, it automatically categorizes similar links/actions which I can tag. For eg: if this link is accessed then a payment has been successfully made or if this SQL query is executed (from the logs), a user has been activated the account. Since *all* the activities (web + DB) are recorded in the requests/logs, having a hook there to analyze all the data will be more accurate and gives the flexibility to measure whatever I want easily.

[3] Summarize a video/blog to a few sentences.

Videos are long and none has the patience to watch a 50-min talk unless it’s really inspiring. This tool should have the ability to summarize the video in the form of a text or a mind map or any understandable format to humans. Instead of watching a 50-min video talk, I should just see the output of this tool and gain the essence and important aspects of the talk in just 10 minutes.The same can apply to long blog posts/articles as well.

[4] CRM inside e-mail

When e-mail has become the default way to communicate between teams, it makes sense to integrate things as much as possible within e-mail. Bug-tracking, task assigning, support tickets and many more, tangentially rely on e-mail but we all use individual products for each of the things mentioned which becomes cumbersome.

Since everything can be tracked via e-mail and labels, this tool should be generic enough for me to plugin anything I need. For eg: assigning labels to users means it’s their responsibility to fix the bug or respond to the customer request.

[5] Dating site for geeks

There’s a common notion that geeks or nerds can’t talk to girls. Ironically, in my friends circle it’s them who’ve been able to have sustained and successful relationships. However a common pattern amongst them was, it took them a long time to take the initial step of asking her out. So, if we build a site that overcomes the initial hiccup, it should give them a good start to take off.

Here’s a site where a girl posts a gig related to computers/programming. It can be as basic as ‘Help me move my posterous blog to tumblr’ to ‘Help me code my lab assignment‘. Once the task is done, since the guy has put quite a bit of effort she agrees to meet him in person for a coffee/lunch. Even though this might not be explicitly put up as a conditional thing, I’m guessing this is a natural extension once the gig is done. After all, there should’ve been quite a few conversations in the process.

PS: I just assumed geeks generally refer to guys, it can be vice-versa also, no chauvinist comments please.

[6] Web language

Every programmer has a language that he/she is comfortable with. I know a lot of programmers who’ve declined job offers (even though they loved the company) because the company was primarily using a different technology stack (Python vs Ruby) This happens vice-versa as well which is pretty sad because bumping onto a good hacker is getting harder and it’s definitely stupid to rewrite a large codebase in another language.

There should be a “web language” which all the interpreted languages get converted (and vice-versa) to, making it language agnostic. The ideal case is where a Python hacker and a Ruby hacker are able to add features on the website with the language of their choice.

I can see several problems here in terms of limitations of different languages and many more but after all these are frighteningly ambitious ideas that will make life simple.

Once this mindset is in, everything what the other person says sounds like gold. Naturally, when you meet 20 people in an event, you get a feeling as though you just got access to 20 pots of gold and you want to try out everything that was told to you. The truth is most of them might not apply to you or can even be plain stupid.

I remember an incident where a very senior marketing manager of an MNC asked me to advertise interviewstreet on radio channels. It might sound really stupid now, but not then when I seriously considered. Thankfully, I was bootstrapping so didn’t have enough money to spend on it.

With this mindset, you tend to sort the ideas by the people who advised rather than the ideas themselves which can lead to disasters if the person doesn’t understand your position. What worked for X doesn’t need to work for Y even though both X & Y might be operating in the same space, environment, etc. The potential of founders, co-incidental meetings (eg: Zuck with Sean Parker) and a bunch of other factors play in which aren’t accounted for when providing advice.

You (and your co-founder) are the only one in the world who understands completely about what’s going on in your startup and things that can/can’t be done. This is not to say don’t talk/listen to anyone around, that’s the most terrible thing one can ever do. This is a a heads-up on “executing” the suggestions you received.

How to execute suggestions/advice?
Talk to a lot of people, read blogs, brainstorm with your mentors, discuss with fellow entrepreneurs, experienced people in your field, etc. Assimilate all the suggestions in your whiteboard without associating any source. Analyze each one of them deeply and see which ones make the most sense for your startup.

One interesting correlation I’ve found with the suggestions I implement is they’ve always come from people I deeply respect/admire because their suggestions seems to carry a reasoning behind it and not something blind. But that’s just me, it might not be the case for you.

Every startup is unique. Derive inspiration, talk to a lot of people but execute/experiment what you think makes sense.

Mentoring programs like YC, Morpheus, etc. are primarily built to guide founders so that they make fewer mistakes on the way thus keeping their morale level in place. Obviously, there can never be a program nor a mentor who can predict every mistake that a founder might do beforehand. If there was one such place, building startups would be really easy.

I’m glad to have wonderful mentors around me who’ve ensured the number of mistakes I make is less. But I’ve made many more and this is my attempt to share it with the rest of the ecosystem in the hope that it would help some entrepreneur(s).

It’s a warm fuzzy feeling to know that you’re making mistakes. It either means you’re experimenting a lot or you’re dumb, but let’s ignore the latter case for now. I promise to write blog posts about the mistakes I make in this journey.

The journey never ends

#1 Focus

Startups are lonely, tough and very hard to build. It’s also highly unlikely that you might hit off with your very first product/idea. I’ve seen a lot of YC companies that have pivoted 2-3 times from start to demo day. In such a harsh state, the only way to maximize your chances of succeeding is to spend most (all) your waking hours focusing on the product to get to market fit. In other words, it means you shouldn’t worry about things like

a. Incorporating a company: It takes roughly 90 days to get a Pvt Ltd done (vs) 4 days in the US to register as an Inc.
b. Integrating payment gateway: I had to fill up a zillion forms, get attestations from branch managers, etc. to get my CCAvenue account up (vs) inserting a 2-line javascript at your footer and you can start accepting payments.
c. Snail mail hard copy of invoices to approve it (vs) everything being done completely online and many more..

Though these may sound trivial, the fact that these miscellaneous tasks still remain on your whiteboard makes that thread silently run in the background all the time. There should be nothing in your head apart from your product & the metrics to see if things are actually working.

#2 Funding

“Building web Software is cheap in this era” whoever said that, I’d love to meet him because he doesn’t understand the difference between a server and a software. Servers are cheap, yes, softwares aren’t. Ironically, building a good software is a function of programmers & designers which are possibly the most expensive resources (I hate calling people as resources, still) today. Building a good web product is very expensive.

One thing I’ve noticed about investors in the valley is their decision to invest on is a function of team, product & traction in the same order with the highest weightage given to the team. Because, everything that changes in a startup (competition, traction, etc.) is fixable but founders aren’t. When you’ve investors betting on you more than the idea, it helps you to raise money at an early stage as well as gives the comfort that it’s you who’s being backed and not the idea. Hence, building a product becomes more enjoyable and you focus on the right things instead of worrying about infrastructure costs, the extra $100 spent on travel (which saved you 6 hrs), etc. You begin to optimize for the right things. And again, building a good web product is expensive.

#3 Equity

Building a team is hard and the early employees really set the culture and the DNA of the company. They’ve to be in to build a wonderful company and should ideally optimize more for the equity they own/hold than the pay. It’s a great feeling to have people around you like that who own a part of the company and want to make it big. Agreed, not a lot of people have made money in India with the stocks they’ve held, because of which the term ‘equity’ itself is extremely underrated, but there needs to be some starting point.

#4 Advisors
This is critical too, but the fact that you’d find great advisors only in valley, etc is exaggerated. If you really want to, you can find great advisors everywhere.

Please don’t start a hate-India/hate-me thread, the reason I wrote this article was we often blame/ask ourselves ‘Why can’t we create more Zuckerbergs or Steve Jobs?’ and then immediately resort the blame to our education system (btw, they were dropouts) or the general attitude of Indians being conservative, etc. BS. The programmers working/worked at Interviewstreet are every bit capable of getting a job in Dropbox or Quora, so it’s really has nothing to do with the education system and one of the guys dropped out of college to work with us temporarily, so it has nothing to with being conservative as well – the problem is something else. I’m definitely not ruining the possibility of building a great global startup, in fact I’m a huge fan of VWO and Paras, but you’ve to accept it’s very hard and is an exception. If we get awed by billion dollar valuations happening in the US, we should also track how many startups actually come out every year (most of them fail) to get a few startups valued $Bn.

“A 30-year old financial analyst complained she’s procrastinating a lot despite the fact that she gets a good pay, perks, etc. Analyzing, there was no particular problem with the work environment/family, etc. On one particular meeting, the psychologist casually observed the way she eats a cake. She firsts eats the frosting and then the others. Digging further, he examined her work-habits. As expected, on a given day she’d devote the 1st hour to the more gratifying work and the remaining to the objectionable reminder. Consequently, nothing in the remaining hours would get done and the work gets postponed. He suggested instead of 1 hour of pleasure and remaining hours of pain, she can try 1 hour of pain and remaining hours of pleasure. Being a strong-willed person, she switched modes and no longer procrastinates”

This is so much like a startup mode. The cake, procrastination, etc. are all parameters that can be substituted. The overall idea is – suffer pain now for a greater pleasure later. I’m sure you’d have seen the marshmallow experiment performed on young kids, the kid with the highest resistance (consequently greatest pain) gets to eat two marshmallows at the end.

When I look back, it’s the deprivation (money, lifestyle and many more) that has helped us survive and led us to the current stage. The thought process has always been ‘let’s undergo the pain now, there’s something big waiting‘. We were even approached by top MNC’s for an above the market salary during our early startup days. It’s so easy to ‘eat the frosting’ but we resisted for something bigger.

I think this is either a born quality or happens when you have an extremely ambitious goal, something close to conquering the world. After a while, when the internal functioning is built to accept pain, you enjoy it, sometimes even induce it, the goals get grander and bigger and consequently you become very powerful. Being deprived of something at every stage always keep you up to achieve something big. It’s probably the only way to rule the world.

I used to wonder how a funded startup can ever lose a battle with a bootstrapped one. More money, more resources, backing, etc. seems logical that they’d beat them, but no. One reason can be loss of focus after investment, but I tend to think it’s got to do more with not having the deprived feeling anymore. The moment you think you’re safe and comfortable, the aspiration drops down and you gradually shift to the losing side.

Even though you might be more comfortable, real animals would induce pain because they’ve not conquered the world yet. They continue to do this in search of a much bigger vision and goal and a true leader rises.

Early stage – when you start building the product.

Making money from the startup is either a secondary motive or doesn’t exist at all. Work all night (&day), demo to users, iterate till you arrive at something people want. The trick is to reach this state before the founders get demoralized. Clearly the make-or-break factor is not money, it’s building something before dying out on morale.

Pivoted – the pain point for a set of customers is identified.

The hunger to get more such customers to try out the product and get feedback is the primary motive. Let’s first get x beta users and then we can monetize. It’s an unparalleled feeling interacting with initial users, probably the best way to get high. Again, making money isn’t the primary motive

Paying customers

Let’s see if the beta users are actually “real” customers. You get to know how many “real” users are present only when they’re willing to pay. Even here you want your startup to become rich and not you.We’re currently at this stage and there should be many more stages in the startup journey.

We started off with a product that did mock interviews, tried different things for over a year, didn’t go anywhere. We then built a tool that helps companies screen programmers – we went through all the stages mentioned above, but the driving force hasn’t changed

Quoting Hari (co-founder) who said this yesterday: “I get scared when I get a phone call, I so hope it’s not someone who reports a bug”. This is exactly what I go through. I hate it when a customer finds a bug, doesn’t matter how big / small he is. It’s a combination of passion, fear of failure / losing the customer and may be a few others.

What surprises me is, even though the external environment has changed dramatically,  (we’ve gone from a bootstrapped startup to ramen profitable, now funded by an amazing set of angel investors, moved to the valley) our drive hasn’t – it’s still to make the best recruitment tool and get a lot of paying customers – make the startup rich. Taking home a big pay check is a secondary motive. I’m not dismissing it, it’s important but it’s never been the top thing on our mind.

To sum up, we’ll be happier if we become rich but would be downright upset and somber if the startup doesn’t.

This is a famous quote that is often misinterpreted. So, does that mean, you should never ask people what they want? as opposed to the general startup advice that says ‘Ask people what they want‘. I think the difference lies in the way it’s asked.

We’ve got a bunch of customers and each one wants a particular feature to be incorporated. I used to ask them ‘What feature do you need?‘, that would most likely give me a huge to-do list. But now, I started framing the question differently
‘Can you tell me the problem you face with the product?‘

As a founder, you’re the product visionary and you would have thought of a way (in your roadmap) of solving the problem elegantly. The pressure from customers is just to move faster in your roadmap.

Wording the question differently helps in making your customers happy, moving faster and aligning to the vision.

I’ve been following their blog posts, talks, books for quite sometime and without any doubt they’re doing amazing work. I agree with most of the things they say except for their stress on work-life balance and remote working teams.

Background
37signals was founded by Jason Fried as a web design shop in 1999 for which David worked as a contract programmer. It was a perfect combination of programming + design and they already had a bunch of paying customers. Basecamp was started as a side project since they wanted a neat way to manage clients’ requests, status, etc.

When you are starting up, the situation is going to be far from how basecamp started.

a. They had a huge set of beta users right from day-1 (or before they even started basecamp) and a good amount of them were ready to pay.

b. It was more like a side project and they were well paid from their main design shop – technically they got paid every month

c. They had a great reputation amongst their customers (who would eventually become Basecamp users)

9/10 times if you were to start a startup for the 1st time, none of the above would actually work in your favor . The hard part is to get the 1st check from a customer which in turn implies building a product that users actually want.

Their recent blog post on firing the workaholics does *not* apply to an early stage startup. You need to build (&fail) faster to actually check if the product makes any sense for users. The 5-day / 8-hrs work would mean slower build times and longer time to fail – which might eventually result in loss of fizz to do stuff.

Working remote:
The best way to move faster is everyone being at the same place. Even though many tools (skype, basecamp, etc.) exist, it’s easier and faster to sit together, discuss mockups, code & push rather than trying to work your way out in skype, etc.
The time spent in unnecessary discussions is very minimal since your whiteboard is always full (at least it should be like that).

I used to be an evangelist earlier of this whole work-life balance, etc, but realized it really makes little sense at the early stage of a startup. Building fast is a big criteria and I don’t know how work-life-balance (or) remote teams would fit into the picture

I started reading and subsequently had a meeting with Garry on UX designing. The resulting discussions & learning was a surprise. I wrote a post earlier on the 2 things a startup should focus and going to map them here.

Getting people to use the product is more a mind game rather than anything else – they have just coined different terms like A/B testing, etc. for the same.

Usability

Human behavior:

If you’re asked to do something and you do it all by your own (without any external help), your self-confidence and love towards it shoots up so much that you want
to keep doing it.

If you get your Hello world program right at your very first attempt, you would want to continue to code another program – your love towards it grows. You might be a great writer / singer / cricketer, etc. but you would still love programming because you tasted “success” at the 1st attempt.

After the UX discussion, I mapped it to building websites. Have a 1-liner for your website, can be anything. For eg: “My website allows people to upload a video“. If it’s going to require the user to signup, read a bunch of FAQ’s, etc. before being able to upload the video, it’s a bad experience. Checkout hellofax to understand it better.
But, if it’s just plain obvious and he does it all on his own, he just loves your product and even going to share with his network.

Adding features (vs) simplicity:
It’s a common problem, each customer requests a feature and you would want to build them, making the product bulky. Do you want to build it ? is a different discussion altogether, but overtime your product would have a lot many features which might actually be good.

However, irrespective of however bulky your product is, design it in such a way that the 1st time user should be able to achieve at least the 1-liner all by himself! Hook the 1st time user, half the problem gets solved.

Customer support:

This is another aspect that attracts people to signup with startups if done right. That’s exactly why I hate customer support products that has the feature ‘Canned responses‘

When 10 guys are going to mail you asking ‘Can I do this in your product?‘ – it’s very easy to just send them the same mail and “solve” the problem.

But, in reality you aren’t solving the problem, you’re actually forcing them to think in your way instead of understanding what made them think that way. If you were to reply individually and understand their thought process, it’s going to help you build a much more intuitive experience for future customers and really solve the problem.

It’s all about tuning the website to aligning to what your users might think.. Sounds simple, but definitely takes time