Eight lessons I learnt from my startup

Silhoutte by Aaron Burden

Was going through some old documents and came across a note I had written to myself when I was just shutting down my startup a year back. Usually when the ink dries, you find it was colored with emotions of the time. However find these points to be as relevant as ever for me.

For context, the startup Vedak was an Uber for business consultants — both hourly as well as long term. More details about it here. Sharing my learnings below

Cannot Outsource cr eation — The core product/technology/platform will need to be done by the founder/founding team with the idea. The idea will be difficult for anyone to grasp and execute. Hence if you are a non-techie looking to do a tech startup, the first iteration which is workable should be done by you. Proliferation of Nocode tools like Bubble, Airtable have made it easier than ever

The core of Vedak was an efficient search algorithm which reads linkedin profiles like a recruiter and matches them to consulting requests. Proved to be tough with engineering help

Market, Market, Market — What are the 3 most important things for a startup? I belong to the school which says it’s market, market, market (not team³). Vedak was in a market which only consultants and investors found useful, we couldn’t go beyond that. There are many nuances to selecting a good market, this talk by a YC partner is particularly useful

Team — Actively scout for team members before taking the plunge into full-time startup. They can be friends, colleagues, alumni, interest groups. Establish a working relationship before discussing business ideas. Treat it as dating before marriage, jumping as a single-ready-to-mingle guy at bars usually is a bad idea

The longest path is usually the shortest way home This is one of the cornerstones of military strategy really well applied to startups. Basically it states, the shortest and most obvious path is taken by almost everyone leading to massive competition, however the ones taking more difficult paths encounter less resistance.

Hyperlocal and delivery startups had a bloodbath period as anyone with an app could start a service. A counter-intuitive advice but build something which seems quite hard from the outside

MVP+Learning Time< 1 month

If it takes more than 1 month to do a software MVP, it’s not an MVP. Ideally one should put out a small prototype and gather feedback in less than 1 month. We worked on our product for months together without really ever shipping it; trying to perfect UX and everything but never felt ready to face real customers

Build a toy — Following the last point, since many founders find it difficult to launch a full-fledged version, testing the market with a toy might be quite useful. Benefits are

  • You can show it off as a cool thing you built
  • Failure doesn’t hurt
  • Address a niche. Don’t need to put a lot of market research & thoughts behind it
  • You don’t take it seriously. No one else does it. And suddenly it blows up if it satisfies a need

Two examples: Facebook was a way for people to waste time while Apple helped hackers build home computers before there was any business case for it. Find an excellent post here

Platform/marketplaces are challenging to start with

Platforms/marketplaces are complicated beasts. Few rules in case you are still intent

  1. Small niche so that it almost feels like a well-oiled service machine not a platform
  2. At least one-side of the market should be easily addressable, identified and accessible

Vedak had the difficulty in identifying both demand and supply. On demand side, uncovering an organizations’ consulting requirement is a very layered process requiring skilled selling. On supply side, identifying who is the right talent and then whether he/she is fit for a gig is again manual

Enterprise is an inherently hard play due to long sales cycles which extends learning time. Our mistake in enterprise was

  1. No way to get an effective lock-in on the clients. We were effectively a service for them as the product were consultants.
  2. We had a product/service that had “Whale” characteristics — Limited customers with dire need — however they paid less than they should have because of lack of proprietary access to supply. Ultimately we were fighting with an efficient linkedin search