That is interesting. I have worked in the space too, and have seen similar attitudes.

I think it often comes down to who is responsible for making decisions with that data. If a product or business person is the one driving a feature, and looking for adoption, the engineers likely aren't going to be invested in building out sophisticated metrics. They get the metrics they are responsible for from their cloud provider (resource use/latency/scale).

I think that problem is compounded by the perception that these integrations are going to tank your products perf (may hurt the metrics engineers care about).

I think all of those dynamics change in really big companies with thousands of engineers. Then you can often end up in a situation where engineers are now required to maximize product metrics, and need visibility into their small slice of the pie.

So, I think its largely incentive, which is why I see all of the metrics vendors targeting product and sales people in small/mid sized companies.

So I did a lot of business development in the 2010s in a space that involved: semantic web, lo/now code, schema-driven development, business rules, entity matching, "centaur" systems where people work together with ML systems to do work, etc.

There was the obvious choice of "analytics oriented" or "LoB oriented" with the complication that "centaur" and anything subjective like "entity matching" needs some analytics no matter what.

My take now is that you're basically right: overall the spend on LoB is bigger because it right on the path to delivering value whereas analytics are secondary... if you're going to get any value out of analytics you're still going to have to execute in the LoB to realize that value!

On the other hand, analytics might be an easier sell because the analytics system can be dropped on top of what's there and the "low code" capabilities could efficiently accelerate the process. Whereas, "rip and replace" on the LoB would be a huge commitment, anything missing from the new system is a dealbreaker, and if it has to interface with the old system the old system is likely to diffuse the benefits of low code. (with the caveat that maybe a framework that implements "strangler fig" might break the impasse)

One thing that was seductive at the time was being saturated with ads and conferences and sponsored blog posts and such about analytics, but you have to realize this: if something is heavily advertised people want to sell it, not buy it That is, advertising is a bad smell.

What I have experienced in analysts work its been like I'm sitting in a dark corner seeing things people can't see, and they are either scared or not interested to enter that corner, so the main challenge is that you have to put yourself in many different shoes and communicate with a language they understand. You will come across data or ideas that you know there is a good chance of them working out, but the lack of familiarity for other people is what that'll make them resistant. The more I have been able to talk in their language (people who will make the final decisions) has always been more effective than the technical aspect of the job.

On one hand, analytics is similar to astrology. You observe real phenomena and draw lines. A lot of inaccuracy comes from the exclusion of delays.

Like if I removed the logout button, how would that affect churn? This is a question better answered by instinct than analytics.

On the other hand, analytics acts as a form of QA. I think this is the true value. But it should be in the form of flagging when quality drops, not being used to decide which corners to cut.