Short tips on startup ideas

I have been collecting tips about software startup ideas for a while. I have published them on a platform that might help to evaluate your idea. The goal is to post what you have and let the public decide if it is good or not.

It might help someone to stop wasting precious time.

Ideazed: https://ideazed.com/

Here is the small excerpt:

~ Ideas are overvalued. Not the idea, but the execution matters. Overvaluing the ideas leads to overreaction to competitors (“they got the idea first, a startup can’t compete with that”), but everything boils down to the product which the startup has created, and the startup’s relation to customers. Not once have the companies (big players as well) lost customers and they simply went down as a competitor, even though they had the idea first.

~ An idea doesn’t have to be something original; it could be something already there, but which just works better than existing solutions.

~ Who wants the product right now and would start using it instantly? Are they willing to use it even if it is a crappy version one? If the answer is no one, then probably it is not a good idea.

~ There is no singular, complete, and fully formed idea just floating around in the ether. The final product results from hundreds, even thousands of iterations, changes, and adaptations of the original thought, made by multiple people. Today’s smartphones, for example, are products of years and years of iterations with the same initial goal - communication between humans; the smartphone never was a single idea.

~ Good ideas are noticed in the real world, and not made-up. They should represent real-world use cases (grow organically), not just the “ideas” of what people might need. Most often than not, what people think other people need is not what they really need. The need should be genuine and not something made up backward to sound like it was a plausible idea. Is another recipe site or pet shop or new event aggregator really necessary?

~ Ask yourself, or the team, the following questions:

1. Do consumers recognize that there is a problem we are trying to solve?
2. If there was a solution, would they buy it?
3. Would they buy it from us?
4. Can we build a solution for that problem?

The common tendency is just to jump to the fourth question and try to build the product before confirming that the customers have a problem.

~ The overall problem with ideas is that they often sound plausible, when in fact they are far from good ones. The issue is that the set of plausible ideas is greater than the set of good ones, and it can lead to a blind path. For example, any derivative of existing things: social network, but for software engineers. It might sound plausible, but most certainly, it is just a bad idea.

~ Before doing anything concrete, one should consider if the idea would result in a product that users will use and like. Without that assurance, one will only waste time in creating something that no one needs. Programmers often develop something, because that is the fun part.

~ Best ideas can initially look like bad ideas (and often they are). But, When Google started, it seemed that there was no room for another search engine - looked like a bad idea at the time; there were already a couple of big search engines at that point. Again, what Google had was a far better search engine than anyone else had, which made all the difference.

~ Solving problems is not the hard part. Which problem to solve is the actual difficult part.

~ Ideas generate ideas. A lot of bad ideas will probably generate a couple of good ones.

~ Change the idea. Don’t get too attached to it. The change can usually result from communicating with clients/users. What do they want, and what are they willing to pay for right now?

~ Focus on problems, not ideas. Don't sit down trying to get the startup idea. Look for real problems you or others have.

---