There is curse of being technical; you are always at risk of entering an echo chamber of “you know what would be even cooler?”. Being a developer can easily be confused with being God, and you run of implementing the next thing while on a euphoric high of being unstoppable.
The brutal truth is talent needs salaries to keep doing incredible stuff. But that only happens if someone asked and is willing to pay for the Michelangelo level genius creation you are bringing to life. In my experience, engineers easily tend to forget that.
I remember working 3 months in one of my first projects, lifting my head out of the code and looking around at my genius peers and going “yep, guys we need an intervention or we will build into infinity.”
You are right to believe that engineers are smart, but knowing what to build requires taste, social skills and commercial understanding of what sells (that frankly, many engineers are not interested in).
The best way I’ve found to solve this was to identify the best stake holders you have and ask them “what would impress your customers in a demo?” and make a prioritized numbered list. Then ask the technical team, based on the number of staff we have how much of this can get done from the top of the list in two weeks - that’s our deadline for our next internal demo with stakeholders.
Manufactured deadline and visible progress against a real product roadmap that doesn’t allow you to hide. A demo is a forcing function. It collapses a hundred “we should eventually” tasks into the handful that actually move the needle for a demo per sprint.