We have a lot of app ideas.
When it comes to many ideas the person who came up with them is often ill-placed to validate whether they are "winners". This is because they are too close to the idea and reluctant to search properly for competitors, in case they come across the same idea and it dampens their spirit (perhaps a mild form of loss aversion).
I know I'm guilty of this.
When I have what seems to be good idea I'm well aware of my own inablity to assess the merits objectively - or worse still miss a vital factor. The only thing that tends to dampen my enthusiasm is that I'm also aware of the true cost of starting a project (initial fun development, first versions, testing, the slog of releasing, porting, supporting, answering emails etc). The saving of killing off a duff idea early is massive. If it's a really good idea it can stand the extra assessment time (and in fact any idea that perishes that quickly might not have been all that good, for this reason alone).
Here are the steps that we typically take when assessing an idea:
Gem of an idea surfaces. Normally one mulls it over and then eventually tells another team member: voice, text or email. I would have expected the person with the idea to have had a little investigation to see if the idea has already been done/partially done at this point. If the idea doesn't get destroyed for some obvious reason we move onto step 2.
Add the idea to the list of Good Ideas (currently approx. 139 ideas on the list!) - and here the idea stays. I have a JIRA list setup, with some EPICS/Tags that the ideas can be assigned to: COOKED (i.e. someone else has already done it better than we can), TOO HARD, NOT ENOUGH MONEY, TOO RISKY, ACTIONABLE
After a short cooling-off period we re-visit the idea. By now the initial keenness has waned, and realism starts pervading the idea. A member of the team can continue the research, but ideally not the orginal person. We have a little scout around, see what is available - try different search terms and build a list of similar ideas.
Having found the closest competitors we try and assess how they are performing. We look for download figures, revenue numbers, comments (positive or negative), and company financial accounts to gauge if the competitor is as good as they appear. Based on this we try and assess if there is a market, and if there's room in there for us too.
Then we build a list of the mimum features MVP (Minimal Viable Product) that we need to implement version 1. There is still no code written at this point. If there is a User Interface we produce a pen and pencil mockup, and see if we can identify the key technical problems. If it more data-related, we'll sketch a database/flow instead.
Finally we sit back and ponder if it still is the winner we originally thought. By this point we like to think we have a reasonable idea if the product is going to perform or not. If we are unsure we park it and review (much) later. It is surprising how often ideas we considered come back and eventually get released. Also a key thing to note here is that deciding not to developm something is a valid and useful outcome - far better to catch it early than 3-6 months time.
Sometimes ideas are so far out that being too rational might miss the beauty of them, as the quote goes:
Don't worry about people stealing an idea. If it's original, you will have to ram it down their throats. Howard H. Aiken