If I find it interesting enough, and I decide to do it, I focus my idea-generation finding the minimum core of the idea, as a milestone with steps or pieces required to get there. Basic rule is that it must take less than 1 day to get there (or know that you can't get there). Then I code/fabricate it, then iterate along same lines, each time allowing more time for next milestone, until I'm done with it. The process explicitly focuses on keeping problems small, so they are fun to execute - and not worrying about 'final' outcomes.
I always start by drawing the "MCD" (I'd translate it as "conceptual data model"). It looks like one of the UML diagram : there are entities and relationships between these entities (zero to one, one to many etc). With this model you can design your relational database schema with ease.
It's my experience that if your data model is right you're building on strong foundations.
I don't understand why it never took of (elsewhere than in France) for relational data modeling. It's a really vast and complex method if you want to apply everything, but most devs here use only the part that make database modeling easy.
I should stress that it's purely for relational data, NoSQL didn't exist when they invented Merise and it would have probably been frown upon ;-) So I guess it's not really interesting in most startups environment were NoSQL seems the norm.
Get this person to talk to you.
Have a conversation asking them about their daily life and their pain points.
See if the problem you are trying to solve comes up in conversation without you bringing it up.
Take notes about their daily work and their problems.
Repeat this process with 10 other people.
Ask yourself if you want to solve this problem or if something else came up in conversations that would be a better problem to solve.
On the other hand, when I come up with an idea that's in my line of work, I'm immediately convinced of its viability. I always start out with drawings (tables, schematics, pro/con, etc). Then I move on to building the DB schema but I don't get too deep in the normalization. Otherwise it gets too tangled up. I then pick a framework and begin . As soon as I have a working proof of concept (not prototype), I pick a good name and website. Then I work toward an MVP.
Good luck!
Then I spend a lot of time thinking about the idea. I think of it from it's beginning to where it could grow. The different paths it might go down. I think about how users will react to it and how it helps them. I think about scaling it. I think about it technically. I think about how it makes money. I think about writing a PR about the idea announcing it. I think of the simpliest way to start the project (no feature creep) and then I try to start from there.
It's full of great advice...but I think one of the key take aways is to "find a market" before you really "have an idea"...and he walks you through some really good ways to do that (using real world case studies of people that are doing it)
I always start with an Evernote page with my general thoughts, then grab a pen and paper and start drawing what could be a barebones UIm then do more research.
I go through the cycle again and again until I am ready to graduate to Balsamiq for a clearer UI and have a clearer story to tell about the project.
I try to balance between doing and researching. I find that excessive research in the beginning is just another form of procrastination of just starting.
I say first decide is it an experiment, or for profit? Depending on that you'll need different research methods, planning, and tools.
Especially if you envision some ultimate goals, quickly forget those and formulate the first milestone reachable with minimal effort. At most a proof of concept to take hurdles (function, technical, or other), not a prototype.
Started... most of mine are data oriented so I usually start with entry screens, maybe a little bit of creating some inital DB tables first.