Startup Lessons Learned -- Take it with a grain of salt(warholandy.tumblr.com)
warholandy.tumblr.com
Startup Lessons Learned -- Take it with a grain of salt
http://warholandy.tumblr.com/post/48157830/startup-lessons-learned
11 comments
7:41 PM EST :oooooh. LOOK at him scraaammbbbling to change terminology and entire sections in his post. I wish I could have saved the page from cache so people could really see the author's point in all this.
To those who missed the action: the author has gone from exclusively and falsely blaming one person from his team to taking a generic stance. Probably after reading all of this and realizing things don't make sense..
This is exactly the kind of stuff I had to put up for 5 months.
awesome. Anyway, that's enough of the drama. I'm out.
To those who missed the action: the author has gone from exclusively and falsely blaming one person from his team to taking a generic stance. Probably after reading all of this and realizing things don't make sense..
This is exactly the kind of stuff I had to put up for 5 months.
awesome. Anyway, that's enough of the drama. I'm out.
So was it like a big fight with drama and crying and all? Did someone get voted out? Please do tell your side of the story! I love drama!
I wish I could but unfortunately- the author is very agile with his various BS NDA, Non-compete and what-the-hell-not forms. I'd rather move on to things in my life that don't waste 5 months of my time. Anyway, I just couldn't hold myself back from saying something when seeing the "leader" go on and publish his thoughts while suppressing mine and then misrepresenting a few things.
I'd rather end it here by saying I don't want to be a part of this new blame game and that the advice given is very sound and realistic. Tragically, the author has tried to apply his zero-technical background to very technical practices when trying to blow out his thoughts into relevant context provided by others. In the process, he has decided to dish out 50% of the problems, misrepresenting a few and then suppressing the other REAL 50% through NDA forms.
Lastly, so that it is clear- the author and his company paid 0 dollars for the patent- It all came out of my pocket and was the result of years of work.
In my opinion it is wise to file a provisional patent for an idea you think is worth it in all its uniqueness and by all measures, I (think I) did not commit a crime by trying to secure my invention/s.
Choose the people who you work for very, very carefully. Things like this (and probably worse) happen later.
Adios.
I'd rather end it here by saying I don't want to be a part of this new blame game and that the advice given is very sound and realistic. Tragically, the author has tried to apply his zero-technical background to very technical practices when trying to blow out his thoughts into relevant context provided by others. In the process, he has decided to dish out 50% of the problems, misrepresenting a few and then suppressing the other REAL 50% through NDA forms.
Lastly, so that it is clear- the author and his company paid 0 dollars for the patent- It all came out of my pocket and was the result of years of work.
In my opinion it is wise to file a provisional patent for an idea you think is worth it in all its uniqueness and by all measures, I (think I) did not commit a crime by trying to secure my invention/s.
Choose the people who you work for very, very carefully. Things like this (and probably worse) happen later.
Adios.
You can send me an email at [email protected] and article poster, please if you have the time, do send me one too!
"Our biggest mistake in our startup was scrapping a prototype that was built in a certain framework for first PHP and then eventually Python/Django. ... This applies not just to the programming language or framework, but to hardware and software applications — keep costs low, use what you already know, and move on"
This is one that requires a large grain of salt. Switching technology may very well be compatible with "use what you already know" and "keep costs low". You can't switch key players in the middle and expect consistency in either quality or cost, which a lot of people think is possible. "You can’t afford to have a religion" works both ways: you can't have a religion based on what you perceive to the value of what you've already done either. I've come into a few projects after a not insignificant money was spent on "cheap" freelancers and contractors to "get the prototype up". Now all I'm supposed to do is add a few more features and polish it to take it to the next level or deploy it. This is often an impossible task, or one that will take longer or cost more than a rewrite because it merely does the prototypical features and wasn't built for expansion or even deployment. But people fear the "rewrite" because it sounds like you're starting over. Get the right people in early, use #8 when necessary, and #6, #7 will come easier (at least in terms of the technology).
This is one that requires a large grain of salt. Switching technology may very well be compatible with "use what you already know" and "keep costs low". You can't switch key players in the middle and expect consistency in either quality or cost, which a lot of people think is possible. "You can’t afford to have a religion" works both ways: you can't have a religion based on what you perceive to the value of what you've already done either. I've come into a few projects after a not insignificant money was spent on "cheap" freelancers and contractors to "get the prototype up". Now all I'm supposed to do is add a few more features and polish it to take it to the next level or deploy it. This is often an impossible task, or one that will take longer or cost more than a rewrite because it merely does the prototypical features and wasn't built for expansion or even deployment. But people fear the "rewrite" because it sounds like you're starting over. Get the right people in early, use #8 when necessary, and #6, #7 will come easier (at least in terms of the technology).
I think the hard lesson I am learning is that you really can't afford to spend time arguing with co-founders about what should be included and what should not.
I think that every 2 person team has to designate one person as leader, and the other as adviser. Otherwise there are too many bruised egos and too much compromise.
I think that every 2 person team has to designate one person as leader, and the other as adviser. Otherwise there are too many bruised egos and too much compromise.
Post was pretty good, but this link within the post was even better: http://venturehacks.com/articles/speed
Can really relate to #9 "Highs and Lows — Never give up".
One day I think "haha this is going to be BIG". Then the next day I think to myself it's an idiotic idea that will never make any money and is using too much traffic and I ought to just close it now before it uses more. Trying to average those feelings out over the days is quite hard - especially if you're a single founder.
I guess if you have co-founders, each founders highs and lows rarely coincide, so you're able to pick each other up.
One day I think "haha this is going to be BIG". Then the next day I think to myself it's an idiotic idea that will never make any money and is using too much traffic and I ought to just close it now before it uses more. Trying to average those feelings out over the days is quite hard - especially if you're a single founder.
I guess if you have co-founders, each founders highs and lows rarely coincide, so you're able to pick each other up.
[deleted]
[deleted]
Nonetheless, most of the advice is realistic and useful in the sense that the points raised are practical and might help structure your startup.