SRIDHAR VEMBU
In our first five or six years at Zoho, we had considered ourselves a complete failure because we didn’t make any impact on the market. But maybe in the eighth year, things started happening. Think about that from a startup’s perspective: you will fail the first five years, and in the eighth year, things start to pick up. We have that kind of patience here, and that is something that is explicitly communicated during hiring. We tell people that this will probably take ten years to master. If you don’t have that patience, you shouldn’t be in this. If you don’t have the stamina to go through this, the endurance, you shouldn’t be in this.
BHARAT GOENKA
I have been called the dinosaur of the IT industry, not the old man of the IT industry. I am genuinely old school. So when I say that I am old school, we start up virtually every time. Right now, we are in startup mode as a company. When I say we are in startup mode as a product company, whenever you throw away your old code base, you are in startup mode. This is the sixth time that we are starting up in the last 34 years. About a year or so ago, we scrapped our existing code base, and we are starting completely afresh. We will probably be in the market in another year. There is an existing product in the current code base, and the new code base is being developed, and as soon as the new code base comes into the market, the old code base will be thrown away. So, effectively, we are a startup.
AS A PRODUCT COMPANY, WHENEVER YOU THROW YOUR OLD CODE BASE, YOU ARE IN STARTUP MODE. THIS IS OUR SIXTH TIME IN 34 YEARS AND EACH TIME WE DID THE SAME THINGS FROM A TECH PERSPECTIVE. FROM THE MARKET PERSPECTIVE, YOU KEEP DOING DIFFERENT THINGS BECAUSE THE CUSTOMER PROFILES AND THE ADDRESSABLE MARKET ARE DIFFERENT. OF COURSE, THERE IS THE GROWTH PLAN. THOSE ARE THE THREE BUCKETS THAT WE LOOK AT AND THEN DETAILING IS A DIFFERENT MATTER.
— BHARAT GOENKA
What are we doing differently? Actually, all the six times that we have started up, we have done the same things from a tech perspective. From the market perspective, yes, you keep doing different things because the customer profiles are different, the market you are trying to address is different. Then, of course, there is the growth plan. Those are the three buckets that we normally look at. I mean, in the sense of the big three buckets, of course, detailing is a different matter. If I take the tech perspective, what we have done consistently for the last four years is perpetually go around the fundamentals. When I say perpetually go around the fundamentals I mean that we strongly believe that in the product space tech is the differentiator, and in the non-product space your business model may be the differentiator.
For example, if you want to get into the fintech business, technology is perhaps a minor differentiator, but your business model is a major differentiator. Suppose you are trying to do T+1 vs T vs T+2, suppose you are trying to do a subscription model vs per transaction model, various types of business models will differentiate you in the market. A lot of that will depend on how deep your pockets are and how you will sustain that. I’m using the [term] product in the sense of something that is going to run on your systems, whether it’s on your phone or laptop or desktop or your servers. Something that is running in your hands rather than something running in the background, then technology is your primary differentiator. What we keep trying to do is pushing
BUT I THINK RIGHT AT OUR SERIES A, SO LITERALLY SECOND, THIRD YEAR OF YOUR BUSINESS, YOU SHOULD START GETTING SERIOUS ABOUT METRICS TO FIGURE OUT WHAT IS GOING ON VERY OBJECTIVELY. WE WERE CLUELESS. WE WOULD LIKE TO HAVE HAD THESE NUMBERS, WE KNEW WHAT THE NUMBERS WERE, BUT A CONSCIOUS EFFORT TO GROW THE NUMBERS OR MAKE THEM HAPPEN, THAT I THINK CAME PRETTY LATE IN OUR JOURNEY. I WOULD BE NUMBERS-DRIVEN FROM THE VERY EARLY STAGES.
— ANAND JAIN
the limit of what computing can do today. Restarting six times, every time the computing environment has changed significantly, it is time to throw away your old code and rediscover the boundaries of what is possible. So that is what we do consistently.
ANAND JAIN
I will tell you what we would still do and what we would change. We would still continue to be product focused. We, three founders, are product builders. We come from product engineering backgrounds, having built software for so many years. That focus is very important. We have never really looked at this opportunity as an arbitrage opportunity that you build cheaply in India, sell it to the West kind of a thing. You build a solid product that can be sold or used by anyone in the world. The world is your market, and you build that. I will keep that as the DNA. What we will change is, we will be a lot more metrics-driven from early on. Literally it has been three years since we started looking at SaaS metrics very closely and that you know for good or for bad happened around Series B and C. But I think right at Series A, so literally in the second, third year of your business, you should start getting serious about metrics to figure out what is going on very objectively. We were clueless. We would like we had these numbers, we knew what the numbers were, but a conscious effort to grow the numbers or make them happen, that I think came pretty late in our journey. I would be numbers-driven from the very early stages.
RITESH ARORA
Before BrowserStack, we tried more than twenty ideas, we spent a significant amount of time. We failed so many times that we actually created our own playbook. There were a lot of learnings across all the years about what not to do. If you just ask me about BrowserStack, one thing that I would definitely do differently if I do it again would be that I would scale much faster. We reached 100 million in our ninth year. We could have reached there in three and a half to four years. That’s a big change that I would have made.
The biggest learning that I had was to go after the problem. Identify users who have this as an active problem. Don’t immediately start building for an idea. You want to build a good case that it’s a genuine need in the market. How deep is the problem? What are they currently using to solve the problem? That is something we did very differently with BrowserStack the first month because, being developers, we tend to straight away jump into writing the code. This time for the [first] month, we were very clear that we will not write the code; we will not write anything. We identified some 76 users across different internet mediums who clearly identified their problems with testing. Using that, we could get a sense of how big the market would be, how active the problem was. I would recommend that as the number one thing that first-time founders should do. If you are from sales and marketing, that will come naturally but if you come as a developer, an engineer getting into this, you tend to skip this part.
The second one was to make it a time-bound approach. Instead of spending two–three years trying out an idea or trying to solve a problem—because you will misfire as well—make it a time-bound approach. I remember we committed for six months. I was convincing Nakul to do this, and he wasn’t convinced about it. So I told him, let’s do this for six months. If we get it in six months, great, and if not, we will just move on to something else. The time window was such that the first month was research, a maximum of four months to build the product—the first version—and the next one month to get feedback from the market.
To build it in four months, we only had like three features. Technologically, it became such a difficult problem to solve that we narrowed it down to one feature. When we launched, it was a very bare minimum version of a product. So that’s my second piece of advice. You probably build fast, fail fast, iterate fast.
KRISH SUBRAMANIAN
As founders, we wanted to build an organization first, and then we picked the problem.
We picked subscription billing because SaaS and subscription-based business models had massive
I WOULD TAKE MORE TIME TO STUDY MARKET READINESS, UNDERSTAND THE COMPETITION, AND FORM A FIRM HYPOTHESIS ABOUT HOW I WANT TO APPROACH THIS PROBLEM RATHER THAN SOLVE EVERYTHING WITH CODE. IT IS MUCH BETTER TO TALK TO MORE CUSTOMERS, ITERATE, UNDERSTAND THE MARKET, DO MARKET STUDIES BEFORE COMMITTING TO SOME PATH. OF COURSE, THERE ARE STILL GOING TO BE LOTS OF THINGS THAT CAN GO WRONG.
— KRISH SUBRAMANIAN
potential in this market and are now even more relevant. It was a hard problem that was also a moat. It took us five years, many ups and downs, and the first $1 million in high-quality revenue to get to the initial product-market fit.
I would take more time to study market readiness, understand the competition, form a firm hypothesis about how I want to approach this problem rather than solve everything with code. It is much better to talk to more customers, iterate, understand the market, do market studies before committing to some path. Of course, there are still going to be lots of things that can go wrong.
With Chargebee, we bootstrapped the company for 18–24 months on the assumption that we would have started making money by then. Had we not gotten the right advice and raised money, we would have completely died as a company.
ANEESH REDDY
Our start was amazing, and our first five years were unbelievable. What we got right there was that we spent six to eight months figuring out what we wanted to build. There were a lot of conversations with customers. So it was PPTs and conversations with customers, and that really worked for us. We could zero in on what people really wanted, and that meant being shameless about it. We would actually go store to store in a mall and tell people we are two kids from IIT, tell us what you want. We can build good tech, and we did that for a good three-four–five months till we were sure that enough people wanted that. Once you hit that product-market fit, it makes life very easy. Once you have hit a reasonable product-market fit, then you are home. At least your initial two–three– four million is not a problem. I would definitely do that again.
If you are building a product for this side of the world, the thing that worked for us really well was that pilot piece. We would go to a customer and say try this for three months and [tell us] if you see the value. It was a very unit-linked pilot. If you had 100 stores, we would say try it out in 10 stores. Pricing models that scale nicely as people use more is something I would again say is very useful. As Sarasvathy puts it, “affordable loss”. Make sure that when you are pricing it initially, you are pricing it so that they can try it at an affordable loss, but when they decide to scale, it is a meaningful amount of money that you are making from each other. So, very unit-linked pricing.
These two things worked really well for us. Third, one of the founders has to be the sales guy. Whether you like selling or not or whether you have done sales in the past or not is a different thing. But having one of the founders focused on selling is a good idea because then you iterate much faster. The feedback is a lot faster, so this tends to work better. All three are enterprise SaaS-focused, large enterprise SaaSfocused observations because we have not done much mid-market or SMB, i.e, small-medium business.
Another thing I would not do is, staying in India, you always have this temptation of throwing people at a problem, given the cost of people is very low. We did that quite a bit between years two and four. We are as many people today as we were when we were a $2.5 million company. At 15 times that scale, we are still the same number of people. Of course, the quality of people has changed, and the type of people has changed. I see that many companies even today have massive customer success teams, massive support teams. You end up solving a problem by throwing people at it rather than throwing tech at it. That’s one of the don’ts. You should give careful consideration to who you hire. It’s easy to find cheap people, but it doesn’t play out in the long term; it just doesn’t.
What else worked for us was getting a good set of angels, and advisors. That is incredibly powerful. In my investors’ lot, the lot that has been very helpful has been the angel lot. Get people who are known to have good names in the industry, people who understand the space well. If you are especially building vertical SaaS, you need folks who understand the space well, and we did that right. Our initial angel investors were amazing and were very, very solid folks.
In the initial years, we never looked for funding. We just executed, and the money came by itself. When I look at many startups now, they just spend so much time trying to raise money and trying to build what investors like. I feel that is a very bad idea. We tried doing it once, and I regretted it like crazy. It takes the company in a very wrong direction.
Another don’t is don’t speed scale: especially you can’t speed scale teams very fast. What I mean by that is that the first time we did it, we started hiring people like crazy after our Series A. Everyone said go and hire people for the next five years. That was also a very different time in India. There wasn’t enough talent that you could really hire as well. We went and hired the best names that we could find: VPs of engineering from Yahoo to heads of professional services, very senior folks in Cognizant. Very good guys, but it’s very important in a startup to make sure that you are hiring for the next year first. If people are not successful in the next six months or a year, they won’t last. Neither will the team accept them, nor will they last for five years to be successful after that. This is something that Alok Goyal and Shekhar (Kirani) say quite a few times, that four years is a lifetime in a startup—if someone has lasted four years, they have lasted a lifetime. Hiring for forever is a bad idea. You should hire for the next six months to a year and people who had seen exactly that scale when you were scaling. Hiring someone who is an 800-pound Gorilla and came in like 20 years later into a business might not be able to solve the same problems that you have today and hence, will never win the respect of the team. Time and again, this has happened with us over the years.
That’s the dos and don’ts again: I would say it is to raise the right amount of money. So I would say raise for 18 months, that is the best. Every time we raised forever, we have only burnt that money in the next 18–24 months. That’s a bad idea; it spoils discipline and takes you into very varied directions.
SUDHEER KONERU
When we started, there was a good focus on the product, building the right product and thinking that through and all that stuff, and then there was concern around sales, how will we win, execution in terms of sales and marketing. If you ask me, one thing that I will change is our focus on implementation, like the go-live process and support process. It was a little bit of an ignored area for a long time in our
IN INDIA, THERE IS A TEMPTATION TO THROW PEOPLE AT A PROBLEM, GIVEN THEIR LOW COST. WE DID THAT BETWEEN YEARS TWO AND FOUR. EVEN TODAY COMPANIES HAVE MASSIVE TEAMS. YOU END UP SOLVING PROBLEMS BY THROWING PEOPLE AT THEM RATHER THAN TECH AT THEM. THAT’S ONE OF THE DON’TS. IT’S EASY TO FIND CHEAP PEOPLE, BUT IT DOESN’T PLAY OUT IN THE LONG TERM.
— ANEESH REDDY
the company, I feel, and we paid the price for it—it just took us too long to get our implementation process streamlined. The customer buys the product, and then you have to onboard them. That was always an afterthought, and none of the founders spent time thinking about the onboarding process. We just had somebody join, and we said, okay, you will take care of it. We were busy with the next sale and the next product release
In the early days, we paid a steep price for implementation, not just in terms of cost as in dollars but also in some customers not being happy and experiencing being poor, etc. When you ignore it and scale up your company, it becomes a bigger problem. Fixing it becomes that much harder than if you had done it in the early days.
The other thing that I would say will be the support aspect, supportability. We did integrate support into our product and all that stuff, but again, we had to scale our support faster than anybody in the founding team had really thought of. We solved the problem around implementation, but we are still solving the support problem in the company [that] is how I would characterize it.
PARAS CHOPRA
I feel we were blessed to be in a situation wherein we were profitable, and our revenue was higher than the salaries of the early team we had. But it also means that we never grew much faster than what we believed our revenue could support. We never invested way more ahead of the curve, wherein we
AFTER THE CUSTOMER BUYS THE PRODUCT, YOU HAVE TO ONBOARD THEM. THAT WAS ALWAYS AN AFTERTHOUGHT, AND WE DID NOT SPEND TIME ON IT. WE WERE BUSY WITH THE NEXT SALE AND THE NEXT PRODUCT. IN THE EARLY DAYS, WE PAID A STEEP PRICE FOR IMPLEMENTATION, NOT JUST IN TERMS OF COST BUT ALSO CUSTOMER EXPERIENCE. WHEN YOU IGNORE IT AND SCALE UP, IT BECOMES A BIGGER PROBLEM. FIXING IT BECOMES THAT MUCH HARDER LATER.
– SUDHEER KONERU
could completely take risks that could have been fatal for the company. We are tortoises in that sense; we like to keep moving but keep moving at a pace where accidents are less fatal.
