It takes practice. Here is how it works for me for big product projects. Maybe it inspires you:

1. Problem definition

try to understand the problem (the root might be hidden behind a few whys https://en.wikipedia.org/wiki/Five_whys )

2. Information Gathering

Gather enough more or less random info surrounding the problem. I do this until I feel like there is nothing major hidden from me anymore and I have a good grasp of the topic. This is interviews with people who know more and some googling or finding a book on it. Take notes, this is the first filter for what is important.

3. Structuring the Problem Space

If you can, try to structure the random info of your notes hierarchically right away. If you can't do that right away, dump all info in to a text file, read through it and than try to come up with a structure. I often have a "quick and dirty" inbox I only later refile in to my hierarchy.

4. Identify Knowledge Gaps, fill or postpone

With a bit of structure you might be able to identify gaps in your knowledge. If they are isolated enough not to change the general outcome of my decision making I just make a note that here is a clarification-todo to handle when making a concrete plan. If they are potential deal-brakers or uncover a bigger topic that needs attention I go back to 2. with this topic.

5. Note Ideas, don't dive in

Often in parallel I already make small notes of possible solutions or solutions to sub-problems, but nothing refined yet. Just enough not too loose any sparking idea. It's important not to get lost in the details before having a clear picture of the situation. With that picture done in 1. to 4. I now try to find a solution.

6. Research Prior-Art

I like to sketch out a first solution and only than research the competition. This way I'm not destined to follow their footstep and might find a better solution. Anyways: don't reinvent the wheel, see what others did.

7. Solving big to small

Go from big to small. Can you summarize your solution in a hand full of "stages"? With that as a skeleton things become much easier and you don't get lost in details. I do the same for sub-stages.

8. Full Concept

You have a solution sketched out, it looks good. Now go in deep. I try to go through every step of my solution mentally. Like imagining getting dressed to check if you packed everything in your bag for holidays. There will be more questions and clarification-todos popping up. You can solve them now or solve just those you need for the first steps of implementing a solution. Maybe write examples, mockups etc. here. Typically this 3-folds my notes.

9. Intermediate Goals and Stepping Stones

You have a full-fledged solution specified now. See if you can cut corners, do a proof-of-concept, an MVP or Milestones. If possible try to find a first milestone that already works start to end, just misses everything non-essential in between.

10. Build, learn, adjust, iterate

Do your first version, adapt your concept with what you learned, do a 2nd version and so on.

My approach is a bit watterfall-style and only at 10. becomes agile (unless it involves experiments to fill knowledge gaps). You might want to jump from 3. (structuring the knowledge space) to experiments and RATs quicker depending on the project. I try to limit the scope of my problem in the first place and save big ideas for later so the downsides of waterfall don't manifest that much. Just keep in mind the longer your concept the more of it might become obsolete mid way.