I remember in Google Ads, we’d build all these cool looking dashboards but whenever we did user research it was pretty apparent that all they wanted was their data in a pivot table…
Spreadsheet export + pivot table gives you all that. Doable for any moderately competent office drone without a round-trip through some endless backlog-spec-sprint-program-test-respec-sprint-... loop
Hell, it cannot even do proper CSV import. You need to reformat your CSV to match the locale Excel is running under!
You can do things in PowerQuery, but that is far from obvious and still buggy. Not to mention all the woes after import, like date/time auto-interpretation and autocorrections that cannot be switched off.
I stand by what I said. Excel imports are a huge mess.
People don't really consume data, they read documents. I think that's (part of) the vision these projects lack.
There's a place for well-crafted analytics dashboards in today's business, too. They're mostly tailored to specific user requirements/use-cases and look nothing like the flashy stuff one sees on dribbble or elsewhere.
Tailored analytics dashboard can solve many pain points of Excel + Spreadsheets if done well. If ~1k people need to access the same data each day and 'analyze' it for similar things (patterns/outliers/seasonalities etc.) then a good dashboard will be quicker, better and cheaper than 1k office workers trying to create pivot tables. If that dashboard is tailored to the use case, then those 'color that one value that bugs you' can oftentimes be implemented within minutes after hearing a good use-case from a user. I say that from experience.
And from experience, I'd say that most Excel users know the basics of basics. I'd bet that 90%+
And of course, given a working system, the users can drop you a quick email, explain their problem (yes, in an ideal world they could do that, and you would understand them right away...) and you implement a 5min change. In reality however, their problem will first have to be specified in a user story, with a ton of clarification requests until the story is really understood by the dev team, then you need goodwill, time and money for the implementation. And maybe their problem can only be solved by an ugly hack, a weird special case for the ternary currency and ages-old lunar-calendar-based tax-system of lampukistan. Would that really be quicker than just the lampukistan team throwing together a few formulas and be done faster than the initial email? Even when multiplied by the special requirements of the other 100 country sales teams?
Also, I've had similar change requests where is was explicitly asked to provide a spreadsheet prototype of what the statistics should look like. Well, thanks, why again do we need a dev team?
I know that spreadsheets suck. They are ugly, undebuggable hacks, always and without exception. You need tons of time to implement in hours what would be a quick one-liner SQL query. With terrible error behaviour, weird edge cases and hell knows how many hidden bugs when the locale uses the lampukistan-currency-separator instead of a decimal dot...
...Except that they provide those office drones with velocity, which, as the usual wisdom around here goes, is everything.
And a tool like Superset enables users to customize their dashboards and charts.
Nobody cares that they looked cool (highly subjective, anyway) if they can't be used to get work done. Where your team thought you were adding value, you were just wasting time.
I quit shortly thereafter and got a job on the Google Sheets team.