These "rules" are a little too shallow to be very useful.
"Build something people need and love. People will talk about it."
People can only talk about it if they know about it. How will they know?
"Release, release and release. Release it before you think it's ready, you're wrong, you don't need that feature."
This would be better said as, "If you're not quite sure, don't be afraid to release. Blindly releasing for the sake of releasing is risky and stupid."
"Your app will probably fail, most of them do."
What is this doing on this list? Worst advice ever. Better would be, "Your app can succeed."
"Build something you want to use. Continue to use it, feel the user's pain."
This can easily be the opposite of #1, "Build something people need and love." You're unnecessarily restricting yourself to the relatively tiny population of things that interest you.
"Be Ballsy, don't follow the herd, make a courageous moves."
Such as...
"Build something you want to use. Continue to use it, feel the user's pain."
Bad advice. Better to ask the user about their own pain. Developers are notorious for having blind spots about their own apps.
"Google Adwords isn't a revenue model."
Not according to Markus Frind, founder of plentyoffish.com.
"Find the cheapest, fastest way to 500 paid users. People will pay for your app, if it's good."
Such as...
"Design is an iterative process, not just development. And you won't get it right the first time, so don't sweat so much."
Sweat a little. Release shit too soon and shoot yourself in the foot. Development must be done with design in mind.
"Don't scale until you actually need to. (The front page of Digg does not count as need.)"
But develop with scaling in mind. (Will you really have enough time to completely redesign your data base schema after 1000 users?)
"Don't spend any money."
What if spending money is more time/cost effective? (Paying someone to do something that would have taken me 5 days to do.)
"Rules" are not a "How to build the next Google For Dummies".
"People can only talk about it if they know about it. How will they know?"
Using it. Start with your friends, and if they like it, they will talk about it to their friends. There´s a lot of ways to make the user "talk". It´s not asking him like a favor, but, basically, regarding him. It´s better if to need your app, he MUST invite new users. It creates a powerful chain of humans.
This would be better said as, "If you're not quite sure, don't be afraid to release. Blindly releasing for the sake of releasing is risky and stupid."
Nope. I think it´s about really release as fast as possible, as long as your app can do the "mainly" think. It´s not even an beta, it´s a alpha, but if it works, it´s must be released.
What is this doing on this list? Worst advice ever. Better would be, "Your app can succeed."
Because newbies business men think that they will be successful by the end of the year. Don´t dream, stay focused and prepare to lose, a lot. It´s not a game where the victories depends of you and your guts, but rather luck and a lot of uncontrolled factors. The best advise ? Good luck !
This can easily be the opposite of #1, "Build something people need and love." You're unnecessarily restricting yourself to the relatively tiny population of things that interest you.
Nah ... there´s a trick part here. If you make something that you can REALLY use, so it´s will be MUCH, but really MUCH more easy to sell to others. If you any time tried to sell something, you should know that.
Such as...
Hum ... anything your mom ever have heard (even if it exists) could help. The point is to start something new, and then look for YOUR USERS needs ... not having the brilliant idea. Dont stick with examples and ideas, go for the reality and try to create anything your user need.
Not according to Markus Frind, founder of plentyoffish.com.
Maybe ... but if you are have something that don´t trows a lot of shit on the screen of the user, and even so that have money, your product is really for the win. Dont be afraid, if your app really help somebody, they will be happy to pay for it.
Such as...
Get one, listen to him, release, get ten, listen to them, release, get 100, listen to them, release, get 1000, listen to them, release ... remember, "we are not on the software business, we are on the SHOWBUSINESS". And, of course, believe on your work.
Sweat a little. Release shit too soon and shoot yourself in the foot. Development must be done with design in mind.
I agree.
But develop with scaling in mind. (Will you really have enough time to completely redesign your data base schema after 1000 users?)
Agree again with you here.
What if spending money is more time/cost effective? (Paying someone to do something that would have taken me 5 days to do.)
It works only if in this five days you can make more money then you have payed for. Therefore you are not spending, but earning.
It is astonishing how few people I take seriously anymore, precisely because of this. Most blog posts I read now seem to have a blatant typo in the first paragraph, if not first sentence. It's profoundly irritating. If I can read my drafts 50 times before publishing them, couldn't others be buggered to read them once?
aherm consider referring these folks to Uncle Raffi's spelling, style, grammar, and misused word detection for bloggers-- http://www.afterthedeadline.com I'm here to help!
I've actually signed up my first beta customer, which will be a big step towards an actual product. We use the product for our business, but n+1 is challenging. I'm doing it though. I want those 500 customers and the freedom to work on my own IP.
1st rule: create a software app of high enough quality, that CS college grads from good departments will not vomit, when they see your source code
2nd rule: don't run out of money; get a part-time job; mow your neighbors lawns etc.
3rd rule: build something that companies, or any mid-sized and funded organization will actually use; you're insane to think you will actually succeed in the consumer market
"Build something people need and love. People will talk about it."
People can only talk about it if they know about it. How will they know?
"Release, release and release. Release it before you think it's ready, you're wrong, you don't need that feature."
This would be better said as, "If you're not quite sure, don't be afraid to release. Blindly releasing for the sake of releasing is risky and stupid."
"Your app will probably fail, most of them do."
What is this doing on this list? Worst advice ever. Better would be, "Your app can succeed."
"Build something you want to use. Continue to use it, feel the user's pain."
This can easily be the opposite of #1, "Build something people need and love." You're unnecessarily restricting yourself to the relatively tiny population of things that interest you.
"Be Ballsy, don't follow the herd, make a courageous moves."
Such as...
"Build something you want to use. Continue to use it, feel the user's pain."
Bad advice. Better to ask the user about their own pain. Developers are notorious for having blind spots about their own apps.
"Google Adwords isn't a revenue model."
Not according to Markus Frind, founder of plentyoffish.com.
"Find the cheapest, fastest way to 500 paid users. People will pay for your app, if it's good."
Such as...
"Design is an iterative process, not just development. And you won't get it right the first time, so don't sweat so much."
Sweat a little. Release shit too soon and shoot yourself in the foot. Development must be done with design in mind.
"Don't scale until you actually need to. (The front page of Digg does not count as need.)"
But develop with scaling in mind. (Will you really have enough time to completely redesign your data base schema after 1000 users?)
"Don't spend any money."
What if spending money is more time/cost effective? (Paying someone to do something that would have taken me 5 days to do.)