Acquiring skills usually means: practicing, practicing and practicing.
I had the very same problem in software dev - I knew how to code, I knew how to read source code, but I had no clue how I should structure my program, build an architecture, etc. And yes, while there are books which will talk you through certain architectures, you still need to acquire an understanding on a much broader base. You might not want to structure your bread-and-butter software in a way the linux kernel is structured, for example - for reasons that become obvious once you've gathered enough knowledge to understand why certain things are working the way they are working.
So I just kept practicing stuff, kept reading pattern books, kept reading source code - and tried to find the patterns I learned. Also, I tried to read a lot of "post-mortems" of failed and successful projects, so that I could get a clue what works and what doesn't. At the end, though, I got most of the knowledge while actually building programs and failing at them.
I'm pretty sure there is something like "patterns" in electronics. It might make sense to dig books that resembles these. While I'm not that knee-deep into electronics, I think you might be able to recognize certain patterns after a lot of practicing.
My advice would be: Grab an easy to understand electronic device, disassemble it, and try to rebuild the schematic with your components. You might want to start with your radio clock, for instance. This would be how I'd acquire the skills necessary. You didn't mention your existing skill set, so replace "radio clock" with whatever you think might work for you.
However, keep in mind that you are a) a single person and b) have only a certain amount of time at hand. I wouldn't expect a hobbiyst to decipher and fully rebuild a modern, high-tech device. Also, to keep yourself motivated, you might want to set smaller milestones.
I had the very same problem in software dev - I knew how to code, I knew how to read source code, but I had no clue how I should structure my program, build an architecture, etc. And yes, while there are books which will talk you through certain architectures, you still need to acquire an understanding on a much broader base. You might not want to structure your bread-and-butter software in a way the linux kernel is structured, for example - for reasons that become obvious once you've gathered enough knowledge to understand why certain things are working the way they are working.
So I just kept practicing stuff, kept reading pattern books, kept reading source code - and tried to find the patterns I learned. Also, I tried to read a lot of "post-mortems" of failed and successful projects, so that I could get a clue what works and what doesn't. At the end, though, I got most of the knowledge while actually building programs and failing at them.
I'm pretty sure there is something like "patterns" in electronics. It might make sense to dig books that resembles these. While I'm not that knee-deep into electronics, I think you might be able to recognize certain patterns after a lot of practicing.
My advice would be: Grab an easy to understand electronic device, disassemble it, and try to rebuild the schematic with your components. You might want to start with your radio clock, for instance. This would be how I'd acquire the skills necessary. You didn't mention your existing skill set, so replace "radio clock" with whatever you think might work for you. However, keep in mind that you are a) a single person and b) have only a certain amount of time at hand. I wouldn't expect a hobbiyst to decipher and fully rebuild a modern, high-tech device. Also, to keep yourself motivated, you might want to set smaller milestones.
Maybe digging through some repair guides could help? E.g.: http://www.industrial-electronics.com/Diagnose-Repair-Elec_0... or https://www.amazon.com/How-Diagnose-Everything-Electronic-Se... ?
Oh, and: Once you are done, write a book about it. Maybe you just discovered a niche that isn't filled yet. :)
(sorry for that wall of text, it grew while writing)