I am a YC alumnus & 3X VC-funded founder-CTO. AMA!

I am an engineer who has founded three startups in the last 10 years. The first two were funded by Sequoia Capital & YCombinator. The current one is backed by Accel Partners. I have also worked at three other growth stage tech startups.

Having seen multiple product lifecycles, I have experienced the pain of creating & scaling products from scratch. Most of my experience and expertise comes from Distributed Systems.

On the non-tech side, I love building teams and going through the zero-to-one phase in a startup.

Feel free to ask anything about the YCombinator application process, entrepreneurship, building engineering teams, scaling products or anything else you are wondering about.

Comments

[KP]

Thanks for the AMA.

1. Would you rather bootstrap or go after VC funding?
2. As a product manager with 2 decades of experience, is going for YC worth the equity I'd be giving up?
3. Unrelated: Do you think there is value in a dev.to equivalent for Product managers, entrepreneurs, etc? It's a smaller market than the developer community, but is there potential there in your eyes and would you use it?
4. Biggest life lesson?

[Arpit Mohan]

Great questions @kp . Thanks for asking!

1. In an ideal world, I'd bootstrap but in a practical world, I'd raise VC money. Imagine sitting at a poker table carrying $10 while everyone else is carrying $10,000. Winning at that table is not impossible, just very low probability.

2. It depends on what you need from YC. Clearly, not product development advice. IMHO, YC gives you a network of kickass alumnus, a peer group that pushes you, access to VCs on demo day & most importantly, an early distribution channel for your product (your own batch). That last one is invaluable to get early product feedback.

3. I don't think I've come across a dev.to for PMs. In fact, the other day, our product manager asked the same question. If Design == Dribbble, Programming == Dev.to, Product Management == ? I think there's definitely potential there.

4. Biggest learning has been; "It's all about the people". Do right by your team, vendors, partner and they will reward you many-fold over your lifetime. Optimize for completing the marathon v/s winning a sprint.

[KP]

Thanks @mohanarpit this is super helpful. I especially liked "Optimize for completing the marathon v/s winning a sprint." You can never go wrong with long-term thinking.

[Chris Achard]

As someone who doesn't know a lot about Distributed Systems - what are some basics that I should keep in mind while I'm developing? Are there things I can do to make things easier or harder to scale later? (or: when should I start worrying about that?) Thanks!

[Arpit Mohan]

My biggest learning while dealing with Distributed Systems has been that everything fails (especially the network). Most of the products that I build now are not focused to prevent failure but instead to work inspite of failure. Some keywords to read up are Chaos Engineering and Crash First Development.

My second biggest learning ( & potentially unpopular opinion) is that if you can avoid a distributed system, avoid it. A monolith is hundred times easier to reason with and test against. :D

[Chris Achard]

Great points, thanks; Yeah - I think "everything fails" is one of the reasons I've really tried to avoid it so far :)

That, and nothing that I've built has enough traffic that can't just be solved by "increase the number of web processes" on a monolith app. Maybe if I build something popular enough, then I'll have to worry 🤣

[mrboywunder]

Hi Arpit, how does the role of a CTO change as a company scales? Also, any tips on how to go about finding product market fit and how to position engineering to assist that? Should founders build, iterate and learn or do thorough research before diving in, whats better/optimal?

[Arpit Mohan]

Really good questions! Thanks for asking.

Please refer to my comment here on the role of a CTO changing as per company scale.

Finding product market fit is the holy grail of starting up. As an engineer, in the early days, I would suggest that you design for change instead of scale or code-cleanliness. Even if you are copy-pasting code, that's fine as long as you can quickly pivot the product based on business needs. This generally goes against everything that we are taught, but unless you have found the product-market fit, don't listen to Uncle Bob and his clean code mantras :)

Each founder is different in their approach to building startups. Personally, I'm more of a doer than a thinker/researcher. There's definitely a lot of value in research before you build. I generally operate better once I have a prototype/MVP that I can demo to people and garner feedback. These days, I'm relying more on no-code / low-code solutions to prototype ideas before actually writing Java/Python code to bring that idea to life.

[Aadi Bajpai]

Do you feel the equity YC takes is worth the connections and the funding you get from them?

[Arpit Mohan]

Let me preface this question by Paul Graham's post on this very subject here.

I agree that they take a lot more equity than usual VCs do. But, in return, they provide a solid alumnus network, access to investors during Demo Day and most importantly, early customers. There are plenty of companies that have grown by simply selling to their own YC batch or just other YC startups. In my books, access to early & friendly customers is worth their weight in gold.

[Aadi Bajpai]

That post is exactly why I asked that question, do you feel that formula he proposes is applicable? It's one thing reading a blog-post and another thing getting the hands-on talk from someone who went through the whole experience 😛

[Martin Komara]

What are main responsibilities of a CTO?

[Arpit Mohan]

I think the responsibilities of a CTO changes based on the stage of the company. In the early stage, it's imperative for the CTO to have a hacker mentality and be able to quickly iterate the product towards product-market fit.

As the product & startup starts to scale, the CTO needs to transition towards being the visionary on the technology front. This involves juggling thoughts between the business folks and the tech team at the same time. It's usually at this juncture that a VP Engineering steps in to take care of the people problems and help scale the team & maintain the culture.

At an enterprise (read: Amazon, Juniper), the CTO cares about what will make the business successful. Since enterprises move slowly, the CTO needs to be able to see multiple years ahead and focus on the tech & ops to ensure the business continues to succeed.

I hope this answers your question.

[Sharath Ramesh Iyengar]

How did YC help you position and set yourself for the next gig/s?

[Arpit Mohan]

YC was an incredible experience that taught us the value of growth. I think their mentorship has helped me startup better this time around.

I think I'm better at cutting through the chaff and simplifying problems to their essence now. Most times, the solutions aren't big & dramatic but are small things staring at you right in your face.

Also, the YC founder network is super helpful & has been invaluable to get early product feedback or just act as a support group whenever I feel down.

[Nikhil Nandagopal]

Hey,

I'd love to hear the highs & lows that you've gone through as an entrepreneur! What were the key takeaways?

[Arpit Mohan]

The highs of entrepreneurship have generally remained the same as my robot hardware hacking days:

1. Watching an idea come to life. The first customer going live on the new platform/product is always a jittery butterfly-in-stomach experience.
2. Someone recommending my own product to me without knowing that I was the founder. :D It's an incredible ego-boost when you realize that you've done something right.

Lows:

1. Having to let go of most of our team when we pivoted the product. No matter how old I get, this still hurts me the most. The team put their faith in the founders and we let them down. It's never easy.
2. Having to explain to the business team that the systems crashed because they did a really good job on marketing and the tech didn't hold up. Even though the business team was extremely supportive, you feel very guilty of letting the team down.

My biggest takeaway from this journey has been that entrepreneurship is a marathon. Maximizing short-term gains doesn't make sense. If you do right by your team and other people you work with, you'll reap exponential benefits in the long run.

[Sebastian Vargr]

How successful are your startups, did you have any near misses with going out business or running out of funding?

And if so, how did you handle those situations? :)

[Arpit Mohan]

I've had a couple of exits with my previous company and learnt very different things through the acquisitions and failures. Even though my last company shut down (because we were burnt out as a team), I learnt how to scale a product growing at 15% day-on-day for 4 months straight.

As a founder, there have been 2 occasions where we couldn't pay ourselves salaries for 3 months straight. At both those times, what helped us the most was:

1. Being honest with the team. At all points, we took the entire team into confidence. This helped us retain all our engineers, even in low times.
2. Always trying to do right by the team. Even when things don't work out, we always ensured that everyone on the team had another job before we shut down.

[Brian]

1 - what 3 books would you gift to a friend of yours?
2 - how did you verify that your ideas had market value?

[Arpit Mohan]

3 books that I would definitely recommend reading:

1. The Score Takes Care of Itself: My Philosophy of Leadership - This is an incredible read about the attitude and process followed by leaders & winners. Heavy focus on mindset here.
2. The Pragmatic Programmer - This book made me love coding as a craft and not just as a job.
3. How will you measure your life - This made me think about my life priorities and start veering my life towards them.

Verifying the problem is a lot more valuable than the solution. This has been a combination of multiple strategies:

1. If I know someone in my network who has worked in that industry (or adjacent industries), bounce the idea off of them and get advice.
2. Ask for advice on forums such Dev.to, HN, Reddit etc to get people's opinion on the problem statement.
3. Create dummy websites, FB Groups etc. and try to garner subscriptions for that group. Allows us to talk to potential customers directly.
4. Google, google, google for competitors. How are they doing? It's unlikely that you are operating in a completely new space. If you're the only one in that space, find out what happened to the others. Are they big? small? funded? Having big competitors is great because it automatically validates the problem.

I hope this helps you whittle down your ideas to "the one".