A good way to think of it is that you aren't looking for problems. You're looking for
smells.
Most business owners tend to be experts in their specific domain, where they have already used their knowledge and expertise to great advantage. But running a business entails more than just handling the problem domain itself. There's an entire category of tasks and responsibilities under the "business administration" umbrella that the business owner will not be an expert in, and will probably despise dealing with because it takes them away from the fun stuff that is their expertise. That's a good area to focus your gaze on.
For instance, the accounting clerk may be spending 4+ hours every day manually typing invoices into two different systems, but to the business owner this is probably perceived as a normal and expected course of business. The accounting clerk is unlikely to complain about it themselves either, since they are getting paid to do it (remember that Sinclair quote). But to you as a software engineer, double data entry is very obviously a red flag, and if you care enough about it you can do a deep dive and see if it can be eliminated using automation, and present it as a cost-saving solution.
Generally speaking, nobody is going to hand you a written list of their problems on a silver platter, and even if they do, the problems they have identified will be so general and vague (e.g. "we have a lot of inefficiencies in our accounting department") that you won't be able to simply go home and start hacking away at them. So you need to use a methodology to start peeling off the layers of the onion, so to speak. And that always entails follow-up meetings and learning other software systems and familiarizing yourself with various business practices.
At some point, you will come to the realization that you no longer view yourself as a "software engineer". Rather, you are a problem solver, and writing code is simply one of the many skills you possess. That's when you'll know you're on the right track.