This is fine for shallow problems in the business space, but eventually you will get to harder problems and will need to collaborate with experts. Experts are experts because they spend many hours on those subjects. You are an expert at engineering because you spend many hours on that subject.
Don't let your recently acquired domain knowledge make you overconfident enough to not reach out to experts. Everyone thinks they know how something works until someone more knowledgeable comes along.
>instead of expecting someone (e.g., product managers) to tell you which product features to develop, you should be able to tell what are the most critical problems your users or product are facing and find the best solutions that fit into your product and engineering strategy.
Which is fine if the problems are obvious and there are easy wins to be had. Your solution's effectiveness is limited by your expertise in the domain.
This is a regular pattern I see, which is "developers pretending to be experts at everything because they're good at picking up knowledge and skills". There is a time component you can't skip when acquiring domain knowledge.
Additionally, while it's great to strive to be an expert in both engineering and the domain, you're naturally doing two jobs for the price of one. Many domain experts with a singular expertise might also make more than developers striving to be double-experts at the lesser price of a developer.