Lessons Learned Launching a Startup in College

This past summer I was the lead developer in a founding team of an early stage startup out of USC. This was my first experience ever doing something like this, especially in the blockchain/web3 space. While I ended up leaving the team, there are many lessons I picked up from my run, and I thought I would want to recount them just for my own sake.

Just a disclaimer that I am by no means claiming to be Michael Seibel 2.0, or a seasoned startup co-founder by any means. My startup story was not a successful one, but I would argue that more valuable lessons can be learned from failures than success stories. After all, the set of failed startup ventures is vastly larger than the set of successes, so there are much more data and observations to be made in that area. Most successful founders seemed to do all of the same things — they took all the “right steps”. It’s so evident what the right way to be a founder is, yet the most talented people that manage to replicate those methods — even with great ideas — still often find themselves failing. For these reasons, I believe learning from the vast set of failures will yield more important lessons than copying the successes.

As a side note, this is referring to factors within the sphere of human control. Outside of that, probability, luck, black swans, good timing, fate, etc. could be (and probably are) the deciding factors of success.

…but I digress. I sometimes feel as if I’m not qualified to speak on a certain topic (as I feel now) — an insecurity about my knowledge, of sorts. However, I do have a firm belief in the statement that humans are all clueless, and no one has the answer to everything. Thus, I’ll inject the little bit of insight that I do have. If that bothers you, consider this just a recount of the personal lessons learned from my experience: retrospection and nothing more.

So here’s what I learned.

Team & Company

Work out a compensation and equity structure from the start

According to other startup founders I’ve talked to , this is one of the more common founder’s dilemmas. Of course, you may feel it unreasonable to dish out equity or compensation agreements very early on, since team members may not feel certain about one another yet, but at some point before launching a product, every member of a founding team needs to have compensation inked out on paper. This was one of the main problems with my experience. I spent over 4 months almost single-handedly building an MVP, just to find out in the end that other team members disagreed with me on equity. Know your worth, and never kick the can down the road when it comes to ownership and payment. Own what you build, and make sure you get what you deserve.

This idea often reminds me of the story of Facebook, depicted in The Social Network, when Eduardo Saverin’s shares get diluted according to Mark Zuckerberg’s plan, effectively kicking Saverin out of the company. Get equity sorted out early, and get it inked out on paper; importantly, get a lawyer to read through the paperwork for you. If you’re not looking for equity, make sure you do the same for your salary. What I often tell my friends is: “don’t get Zuckerberg’d.”

Build quickly

From the perspective of an early-stage, pre-seed startup, building and launching a minimum viable product quickly is key. This is where the term “lean MVP” comes in — this should the most bare-bones version of what you’re trying to build. Cut out all extra functionality and just make something that works, it can be extremely rudimentary. A simple Google search of successful companies’ lean MVP’s can show you how basic some primary lean MVP’s were — take a look at Airbnb for example, and see for yourself.

The reason for this is to just get a proof of concept. You likely don’t even know that your product will work or have product-market fit. The goal here is to build something and test it as quickly as possible; every second that you spend overbuilding is a second wasted that you could funnel into other ideas. Never overbuild when you don’t know if your product will even work, so get to the lean MVP first, then once you see that the product has a fit, build on top of it. Don’t worry too much about your product’s direction if you’re not certain on things, as you can always pivot afterwards.

Once your lean MVP is done, start testing its product-market fit. Reach out to potential users, conduct user surveys, onboard people onto your waiting list, and go hard on marketing. At this point you should be looking for VC funding as well. I would say that it makes most sense to go to VC’s once you have a lean MVP and some users. This is the only way to really secure a lot of funding if you don’t have some big reputation attached to your name and your team.

Be adaptable — be able to pivot

From the venture capital friends I have talked to, one of the most important qualities of a startup founding team is to be able to pivot. Knowing when your idea or product doesn’t fit is important, so be open to adapt to what the market needs in a timely manner

My team went through many tough design decisions early on. One was what type of market making model we wanted to use for the built-in crypto exchange on the platform. Even after months of building and being 90% done with an MVP, we became aware of a brand new market making model in the crypto space that better fit our needs. We quickly realized that our decision to stick to an AMM wasn’t optimal, and so we decided to pivot and change the whole codebase. This was one of the things we did right, and I think every startup should be very adaptable to the changing market, new technologies, and consumer demands.

Agile work

All startups should study and build with the agile development methodology. It almost feels like a no-brainer, but I’ve seen friends and others not really set up their organization like this.

In addition to this, I have some key pointers on how team dynamics and organizational behavior should work in a small, early-stage startup (especially tech):

• Fast-paced task completion: everyone relies on everyone else to get shit done, in order to keep the ball rolling. Every single person’s role is pivotal, so no one can be slacking off. A startup is not a corporation with 100 people in a department split up into 20 different teams, each handling a small task. Each person is their own department in an pre-seed startup. Set up a Kanban or a task-management calendar of some sort, and let team members hold each other accountable for getting work done.
• Make decisions as you go: this ties in to the agile methodology, and also to being adaptable and able to pivot. As a developer, or a marketer, or a BizDev person, or anything really, you will be making crucial decisions every day and adapting what you build as you go along.
• Host team meetings on a regular basis: While I find that in-person work is always more productive and energizing in small teams, especially in startups, it is very likely that everyone may be working remotely. Thus, make sure everyone meets on a regular basis so team members can check in on task progress, discuss company/product direction, give each other feedback, and hold each other accountable. Feedback is very important here.
• Activities are also a great opportunity for the team to bond, so do fun shit together from time to time.

Self

Deep Work

While I could’ve learned this anywhere, my startup experience taught me the power and importance of deep work. In a world where the technology surrounding us is so distracting, it’s super hard to tune out and just focus on building something, especially when you’re a coder. Getting a hang of flow state is really hard, but once you’re in it, you can’t focus on anything but the task at hand. I learned how to power off my phone, close all my Twitter and email tabs, put everything on do not disturb, and tell myself to work on only one thing for the next 4 hours. Getting a hang of this is tough, but it’s something you need to do, especially as a developer. Avoid any context changes that might bring your mind away from the task at hand. Never schedule meetings in the daily block of time that you want to dedicate to “deep work sessions.” I highly recommend reading Deep Work by Cal Newport and Flow State by Mihaly Csikszentmihalyi.

Of course, this probably doesn’t apply to everyone. I understand that if you’re a CEO, or doing business development, marketing, or outreach, your work might have a very different flavor to it; some roles wholly consist of discussion, delegation, and scrolling Twitter all day. However, this is just the takeaway from my experience, as an engineer.

Time management + daily routine

This goes hand-in-hand with the last point. Having a routine helped me be productive. Waking up and meditating; making my bed; going to the gym; setting aside a period for deep work — the same block of 6 hours a day with one break; having a set block of time to take meetings, catch up with team members, and brainstorm with the team; etc. etc. All of these things go into maximizing personal productivity. I quickly learned that this was the superior way to get shit done. So much cleaner, less stressful, and more productive than the anxiety-inducing mess that is a university student’s academic and extra-curricular schedule. There is literally no routine to that at all.

How to think

When you build something, and take ownership of that thing, your meticulousness must be unmatched. Be picky, hell, be stubborn with the level of quality that you demand from yourself and your colleagues. Never cut corners with any part of your job at a startup. This is not a school project, it’s a cutthroat competition for success. You must employ shrewd decision making — dot your i’s and cross your t’s.

I personally found this to be a whole mentality, a way of thinking: you take ownership of something, deep in your conscience, and convince yourself that the success of your startup is completely contingent on your performance, and that you can make it happen. Once you do this you will find yourself trying harder than you ever have at anything you’ve ever done, using every resource and skill at your disposal to make things come together according to your vision. The mentality is necessary.

That feeling, for me, was exhilarating. I didn’t end up sticking with the startup due to disagreements among the team and a mistimed product, but I sure did learn that I want to build my own company again in the future, and if it fails, then I’ll do it again. I just love it for some reason.