Personally, I run a Kanban board for product planning - the end of my board feeds into the beginning of the dev board, with the devs accepting the work onto their board so that if I missed anything or they need more info, it stays with me until it is complete enough that they can work it without questions. This speeds things up because I am not constantly just putting out fires due to poorly written cards.

I also find that product people tend to forget our purpose. PM 101: We say "what" needs done, Engineers say "how". So that is exactly what I write up. I don't diagram technical details, even though I also am an engineer and could do so... but I do get very tight on details of "what" should happen - "Click button a, do thing b, expect UI change c, etc." Cards typically outline a set of actions like that to comprise a feature, and I let the devs worry about whether it needs broken down into subtasks and shared amongst themselves or whether one dev will work it all. Again, my job is "what", theirs is "how".

Forgetting the goal of the product role often leads to product people who spend all their time in meetings micromanaging the dev process, instead of letting the engineers run free to do what they do. Which in turn leads to devs who complain about product people, and the whole team's morale tanks. If you can escape all that, the devs have autonomy to do their jobs and you have time to write good specs while keeping a lightweight process.

Edit: I should add that I don't set my specs in stone - devs are welcome to come to me and say, "Wouldn't it be better to do it this way?", and if their idea is better, I say yes.