If only someone told me this before my first startup
2. Kill your EGO. It's not about me, but the user. I must want what the user wants, not what I want.
3. Don't chaise investors, chase users, and then investors will be chasing you.
4. Never hire managers. Only hire doers until PMF.
5. Landing page is the least important thing in a startup.
6. Hire only fullstack devs. There is nothing less productive in this world than a team of developers.
7. Chase global market from day 1. You'll win or fail despite the market you target in most cases, so go for bigger upside.
8. Do SEO from day 2. As early as you can. I ignored this for 14 years. It's my biggest regret.
9. Sell features, before building them. Ask existing users if they want this feature. I run DMs with 10-20 users every day, where I chat about all my ideas and features I wanna add.
10. Hire only people you would wanna hug. My mentor said this to me in 2015. And it was a big shift. I realized that if I don't wanna hug the person, it means I dislike them. Even if I can't say why, but that's the fact. Sooner or later, we would have a conflict and eventually break up.
11. Invest all money into your startups and friends. Not crypt0, not stockmarket, not properties. I did some math, if I kept investing all my money into all my friends’ startups, that would be about 70 investments. 3 of them turned into unicorns eventually. Since 2022, I have invested all my money into my products, friends, and network.
12. Post on Twitter daily. I started posting here in March this year. It's my primary source of new connections and traffic.
13. Don't work/partner with corporates. Corporations always seem like an amazing opportunity. They're big and rich, they promise huge stuff, millions of users, etc. But every single time none of this happens. Because you talk to a regular employees there. They waste your time, destroy focus, shift priorities.
14. Don't get ever distracted by hype, e.g. crypt0. I lost 1.5 years of my life this way. I met the worst people along the way. Fricks, scammers, thieves. Some of my close friends turned into thieves along the way, just because it was so common in that space.
15. Don't build consumer apps. Only b2b. Consumer apps are so hard, like a lottery. It's just 0.00001% who make it big. The rest don't. Even if I got many users, then there is a monetization challenge.
16. Don't hold on bad project for too long, max 1 year. Some projects just don't work. In most cases, it's either the idea that's so wrong that you can't even pivot it or it's a team that is good one by one but can't make it as a team.
17. Tech conferences are a waste of time. They cost money, take energy, and time and you never really meet anyone there. Most people there are the "good" employees of corporations who were sent there as a perk for being loyal to the corporation.
18. Scrum is a Scam. If I had a team that had to be nagged every morning with questions as if they were children in kindergarten, then things would eventually fail. The only good stuff I managed to do happened with people who were grownups and could manage their stuff. We would just do everything over chat as a sync on goals and plans.
19. Outsource nothing at all until PMF. In a startup, almost everything needs to be done in a slightly different way, more creative, and more integrated into the vision. When outsourcing, the external members get no love and no case for the product. It's just yet another assignment in their boring job.
20. Bootstrap. I spent way too much time raising money. I raised more than 10 times, preseed, seed, and series A. But each time it was a 3-9 month project, meetings every week, and lots of destruction. I could afford to bootstrap, but I still went the VC-funded way, I don't know why. To be honest, I didn't know bootstrapping was a thing I could do or anyone does.
That's it.
87 comments
[ 1.7 ms ] story [ 147 ms ] threadEdit: Product/Market Fit. Got it.
(sans the comment about real estate).
> 9. Sell features, before building them. Ask existing users if they want this feature.
> 15. Don't build consumer apps. Only b2b. Consumer apps are so hard, like a lottery. It's just 0.00001% who make it big. The rest don't. Even if I got many users, then there is a monetization challenge.
^ these in particular stand out and all connect together. many plans never say who you will sell to, how to reach them, and how much they will pay. beware the urge to start working before these questions are answered
without thinking about, and talking to, customers, you can dwell safe + warm in your solitary brain for far too long
so is it an error? or a necessary phase of growth
but yes it is good to graduate beyond it
However the reader should take everything in my post as my subjective experience which they should make up their own mind upon
If I could go back in time, I'd have put 100% of the energy I put into fits & starts around partnerships (that unanimously went nowhere useful) into more baseline marketing around awareness and discoverability. I'd also have gone about fundraising significantly differently.
3. Don't chaise investors, chase users, and then investors will be chasing you.
4. Never hire managers. Only hire doers until PMF.
5. Landing page is the least important thing in a startup
>
My experience at multiple startups from 2017-2020 suggests differently. I wish it weren't the case, but it seems there is a certain type of company that can focus solely on hype and fundraising and headcount, and make it quite far.
> and make it quite far
Is that measured by funding rounds and valuation, or by paid users/revenue?
Huh? And those "fullstack devs" will do everything alone or what? Maybe if you are building a proof-of-concept prototype with a useful half-life of 6 months before you sell the company to someone else (and let them deal with the mess under the carpet) but not once you actually start selling the product - and mainly, have to maintain it.
I have spent 11 years in such startup - and this "fullstack" mentality, with everyone being "expert" in everything led to quick and dirty solutions that worked for getting a release out to the client - and repeatedly kept blowing up in our faces every few months afterwards.
"Fullstack developer" is myth. Yes, people can learn a little bit of everything to get a cobbled up solution out of the door. But this doesn't scale and will severely impact the quality of what you are delivering over time. At some point you will need to invest in specialists or let people specialize, especially if you are building anything beyond some trivial web apps. Ignore at your own peril ...
>18. Scrum is a Scam. If I had a team that had to be nagged every morning with questions as if they were children in kindergarten, then things would eventually fail. The only good stuff I managed to do happened with people who were grownups and could manage their stuff. We would just do everything over chat as a sync on goals and plans.
No offense, but that only means you don't understand Scrum and are cargo-culting it instead. Which is, unfortunately, common. People focus on the process minutiae and lose sight/don't understand why that process exists and what it wants to achieve. Then they declare that "Scrum is a scam" instead of adapting it to their needs, while keeping the spirit/idea behind it (i.e. not turning it into a waterfall/whatever).
There is nothing in Scrum that explicitly prescribes that one must have an in-person standup every morning - and that the same cannot be done over chat or some other means.
The point of these things is to have a daily sync point for all stakeholders. And that explicitly includes the usually very busy founders/partners if they are part of the development team (e.g. as product owner(s) ).
This is vital for the developers if they are to build what the business/customer actually wants because the PO needs to be there to answer questions - and also for the PO/business stakeholders to have an overview how things are going and what needs to be organized/fixed/resolved for the team to keep moving forward towards the objective.
Specifically, this is not intended for you to organize or manage the time of your team! You are there to only to set the goals (at the sprint planning usually) and to clear the way for the team as required e.g. by providing necessary resources which may come up during the sprint.
If you can make do without such formal structure only with chat - by all means do so. However, it does not scale and you will discover this rather quickly as your team(s) grow in size and scope - even with 3 people it is often too much already.
Unless your team is capable of reading minds you will sooner or later end up inundated with organizational questions over the day, which is both distracting and slows everyone down - the busy founder/owner/PO becomes a bottleneck.
We had this in the startup I was in. The owner was practically impossible to get hold of because he was constantly busy, important decisions only he could make were thus not being made, projects were being delayed because of this, etc.
At my current company we have Scrum implemented in the more-or-less original form, with 15 minutes long standups over Microsoft Teams (we are mostly remote) every morning so that everyone knows where we stand, what issues need to be solved and what are we going to be doing today.
Some teams have a longer technical follow-up afterwards ...
The lack of some sort of formal structure very much was a problem.
Granted, some people are so self-disciplined and enlightened/experienced that they are fully capable of self-organizing and don't need the support of any formal work structure. But those are rare like hen teeth. It doesn't have to be Scrum but Scrum works, so why reinvent the wheel?
This is especially true at early stage startups when there are millions of things to take care of besides the coding. The structure/being organized is super important or things start falling through the cracks.
If it is a feature request that didn't make it that is annoying but likely no big deal. But if it is e.g. a tax declaration for the company or maybe some government paperwork that had to be done, or following up a major investment/sales lead - that could literally destroy your company overnight.
So having a structure in place to make sure everyone is constantly on the same page, everyone knows what needs to be done - and mainly who is going to do it - is super important.
The problem is that most people I have met didn't realize this. Esp. when the founders have never worked in a structured team themselves, never saw how to manage a team or had a mentor to show them the ropes. So you end up with poorly reinvented management "wheels" that don't work and the company is wasting precious capital because suddenly the founder becomes an over-stressed and overloaded bottleneck trying to juggle coding, finances, sales, filing taxes and what not. Or, worse, makes the company fail because something that had to be done wasn't.
This isn't stuff that is taught in universities or that people are somehow born with. One has to learn it with experience - and ideally see how to do it from someone more experienced.
Obviously, if your entire company is one person, you don't need Scrum. However, the moment you hire your first developer you better put some structure in place because sooner or later you will outgrow the informal "system". Only so much can be done with a single person.
And once you have more than 1 developer (or any team member - it can be graphic designer, web designer, sales, whatever) you will have problems if you keep things totally free form. It becomes super inefficient.
While I can agree that hiring full stacks may be better at the beginning, then I dont understand 2nd part "There is nothing less productive in this world than a team of developers."
WTF?
(At least, that's how I interpret the OP, and don't understand your perception of any tension between 'full stackers best' & 'teams unproductive'.)
Then defenestrate myself.
First, yikes.
Also, I'm quite curious about how productivity was measured here.
For a (successful) software business, the work output of developers is highly productive because the marginal cost of selling another copy of the software is so low.
SaaS delivery models may result in somewhat higher marginal costs compared to non-SaaS distribution models, but I'd be surprised to learn that it makes developer work the least productive component of the SDLC.
From my own experience, my most successful products have been built by one single full-stack dev. Who did everything
For example, post on Twitter everyday. It might have worked for some people before but I always found Twitter as noise and pointless. You can see startups getting likes for dump screenshots of revenue or milestones but it doesn’t really get you customers or real users.
The corporate one is spot on, I’ve had lots of interest from large companies but I couldn’t close any as I was a solo founder. They require lots of paper work, sales cycle is months, lots of stake holders … etc
> 8. Do SEO from day 2. As early as you can. I ignored this for 14 years. It's my biggest regret.
Those seem pretty directly in conflict. (I suspect that #5 is the one that's in error.)
The thing is, you can't confuse a "yes" with the user actually wanting it. But there are plenty of ideas that everybody clearly do not want, and people will answer you a "no" if you ask.
Ever met people with "brilliant ideas" but no skills to make them concrete? They're not only nonproductive, but usually sap everyone else's productivity with their "expertise."