I believe that it probably happened to you in the past where a potential customer tells you something like "You are not an expert with technology X then I am afraid I will not work with you".
That makes me think about the difference between being a specialist and a generalist. I had to work as a specialist (i.e an "expert") at my previous job as I worked for a software vendor so I was obviously expected to know the product deeply. The problem when you behave like this is that you only know and work with one technology. But this is what you are paid for after all.
After some time, you know the system so well that you have the feeling to get a giant hammer and suddendly everything looks like a nail. You stop thinking about where to put the nail in and how to put it. You just want to put a nail somewhere so your customer did not pay you for nothing and this is really bad.
This is a behaviour I already noticed with people who are experts in their field. When you start discussing about a problem there is alway a moment when you get a "Ho that is really simple, with technology X I could do it in 2 days" where technology X is obviously the one this person has a really a deep knowledge of.
In my opinion this is a bad idea to think like a specialist because the risk of overlooking the entire picture of the situation is too big. It is extremely important to get the big picture of a customer's situation tatooed into your mind first and then start discussing with your customer what you can do to help him. You also have to make it very clear that you work for your customer's customers (i.e final users) because if final users are happy with the system, your customer will be happy (everybody is someone's customer at some point).
If you ask a generalist you should get more questions than answers first, like "is it a network problem (DNS, latency, anything else ?)", "is it a distribution problem ? (maybe the CDN used -if any- has problems), "is it a front-end problem (ie is the slowness feeling a pure perceived performance problem or a real one ?)", "is it a backend problem ? (maybe something is going wrong on the server or at the datastore leve?)". The key to these questions if to understand the problem first because when you do not understand a problem entirely chances are it will not be fixed, or worst il will be fixed at the wrong level of abstraction. Then he will ask you for metrics and logs, analyze this ton of informations and provide a couple of theories explaining why the website is slow. The next step is to prove this theories. If all of them are wrong then drain, wash and rince again an find what has been overlooked previously. Then you should get an answer that really fixes the problem(s).
There is one thing I noticed with generalists, they have a better capacity to dive into a manual or the source code of products they have to work with most likely because they do not live in a cumfort zone but are constantly switching between different problems during the day.
If I had to hire someone I think I would prefer a generalist to a specialist.