But I agree, once I have the basics down, I should just start executing and learn new languages and frameworks as needed.
Thanks
For example if you don't know any kind of code at all, draw pictures of your application screens, then learn HTML and CSS to mock them up, then learn whatever framework and language is handy to handle the backend and logic necessary to tie them all together.
A working kludge is better than a perfect code in one's head.
I can't count the number of times that I've learned a new technology and thought "You can do that? Woah, that's what I want to present to the user. None of this ugly kludgey stuff that I was gonna do."
I've also found that the hardest part about eliciting requirements from non-technical people is that their vision is constrained by the systems they've used. You ask them what they want, and they'll give you something that looks basically what they're already using, but with a few minor annoyances fixed. If you actually build that, you'll find that they won't bother to switch over. You usually need something that works in a radically different (and better) way for people to use it.
For example, you shouldn't assume that application screens, HTML and CSS is the right way to solve the problem at all. Maybe it's better done as a mobile app. Or maybe you're better off wiring together existing apps (say, Google Docs or Drupal) and writing a bookmarklet with a little bit of JavaScript glue. Maybe you want a hardware component and will be selling a physical device, like WakeMate.
Agree that learning languages isn't the way to discover these technologies. Instead, focus on algorithms and APIs. Learn what's possible before diving into the details of how to get it done.