I’ve also found that folding product workflows into the Kanban board gives the team more visibility and ownership over that end of the pipeline. We can observe how those items age before it ever gets to the dev team and swarm to fix things as a team earlier in the process.
Do you maybe ask for an estimate on “what”-tickets?
What I do instead is focus on priority. If the leadership thinks they need a date, I ask why. Often it ties to KPIs they need to hit, or promises they made up the chain, or sometimes even something real like: "We're out of funding in 4 months.". But once I know "why", I can tailor the "what" to focus tightly on that "why", and deliver. If they push for hard dates, then we're back into micromanagement to get the scope to hit the date, and we are wasting time again. So I don't measure effort... at all. I just let the team know what is most important, and we do the work.
The trick is to get leadership to trust that this works. Most of them are used to timelines, scrum cadences, 6 month roadmaps, etc. And if that works for them, great. But it isn't what I recommend for building an effective team who can deliver quickly while enjoying the work.
Edit: I always think of one more thing after I type up a comment... I can succeed in this scenario because I used to be an engineer. I know if something takes an hour vs. a day/week/month and can break things out accordingly. If a product person really does not have that sense, they'll need to ask about effort... but it can be at that high level of hour/week/day/month.
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.