I want to dismiss Rogan as much as anyone, but I think this underestimates the complexity involved. It's not just a button, it's what the button does, it's respecting opt-outs like that in a scalable way for many millions of customers, it's having a way to un-do those for users and for support agents when customers inevitably accidentally hide a podcast they want to see, it's GDPR data export and deletion of those flags to hide things, it's UX testing around whether users even understand what the button does.
I agree that a good product would do all these things and have a way to not show recommendations you don't want, but I get why these things might not exist.
When I worked in a <100 person startup we'd "just build it" and I'd probably spend a few hours on this, but we didn't have all these concerns. We didn't do user testing, we didn't care about scalability at this level. Now I work on Google Play, and if you want to add a button like this (that will need a database query) to a frontend it's a ton more work because the scale is so different.
> I want to dismiss Rogan as much as anyone, but I think this underestimates the complexity involved. It's not just a button, it's what the button does,
This is the kind of statement that leads to people saying "Should have fired 80% of their employees years ago when service was reasonably feature complete." by making it sound like a big development team creates an unwieldy product then struggles to implement even the simplest of features.
The button is absolutely not missing because of any technical difficulty implementing it. Spotify is already storing per-user preferences - and doing all sorts of algorithmic stuff to make smart recommendations and suchlike, all with the ability to scale.
The button is missing for a business reason: They want their purchase of Rogan to be a success because they've spent a lot of money on it.
> The button is missing for a business reason: They want their purchase of Rogan to be a success because they've spent a lot of money on it.
Precisely. If everybody was opted out by default, podcast growth would be anemic, and the product managers would find themselves on the list of people losing their jobs.
No, they're right: your understanding of each other diverges when you write "it's not because of any technical difficulty" --- correct, we all agree there. However, it is still difficult.
Big companies have big processes and that, at least at Google, would have prevented this from happening for at least 12-18 months. Then those things aren't pursued because of A) the literal cost of getting that arranged over 18 months B) the individual's decision not to invest in beating their head against a wall for 18 months for something that'd be done in a week if leadership cared. Leadership does not care, so QED, it will not be a positive for your career.
Things either get done because A) leadership cares and has skin in the game and everyone is afraid of getting in the way of whoever delivers B) leadership cares and will keep asking about it over and over again for a year or two or C) no one cares so no one will get in your way.
That's also the crux of why things at Google go sideways. A) is only true over a year long cycle (I.e. you need to get to launch) B) people are afraid to do because it's hectoring and C) if no one cares its probably not much of a game changer anyway, there's no incentive to do it, and especially in FAANG's Efficiency/Focus(tm) era[^1^], you can actually get pretty easily brow-beaten for it by middle management. Then what are you going to do? Appeal to a VP that your manager and managers manager are big ol meanies?
> Big companies have big processes and that, at least at Google, would have prevented this from happening for at least 12-18 months.
Well gee, if all these software developers are making them slower at software development, it sure sounds like they should have fired 80% of their employees years ago when service was reasonably feature complete.
It's not the software developers. Companies and processes aren't run by software developers. I wish you were more curious about the gap between your understanding and others, it'd be a much more enlightening discussion with your interlocution, as it stands, we keep circling back to "all companies with long launch lead times should fire 80% of their software engineers"
danpalmer believes ads for Rogan can't be dismissed because of 'the complexity involved' in specific technical areas such as being scalable; providing a GDPR export; offering an undo option; and providing a comprehensible user experience.
I would say questions like scalability and data exporting fall squarely upon the software development arm of the business; and if they had chosen an architecture which made it hard for them to deliver value, that would reflect poorly on them.
I am also arguing they probably didn't choose a bad architecture, because I don't think a technical issue is making it difficult to dismiss Rogan ads.
It's far more likely this is the same as Youtube making it difficult to dismiss Shorts, and Amazon trying to trick you into a Prime subscription every time you check out: They've decided their strategy is to make a number go up, and your personal experience is less important to them than that strategy.
I get you, but at the same time I'm more than little suspicious that they paid 200m for Rogan and just happens to plaster his face on my podcast tab like a permanent ad for months on end. IIRC it was right after also just acquired Bill Simmons also permanent thumbnail, basically fully visible unlike the third listing in the carousel that required scrolling. I find it hard to believe they couldn't rotate recommendations, or move it below the fold. This complaint was all over their forums, reddit, social media at the time. Their default answer on forum was, not yet, but features constantly coming. Avoided all the question of why can't they just remove the banner until feature implemented. I buy scaling features for 500m users is hard. I also buy using technical complexity is a cover for other motivations.
For something as simple as a dismiss button for a particular promotion, it's reasonable to store the bit on device. This will work for mobile and desktop apps, which I assume are the vast majority of Spotify usage.
Or they could invest in a generic "misc settings" column in their DB - to store random stuff like this in a blob. You could even query/index on them w/ something like Postgres's JSON support.
> For something as simple as a dismiss button for a particular promotion, it's reasonable to store the bit on device. This will work for mobile and desktop apps, which I assume are the vast majority of Spotify usage.
No it isn't. When you "dismiss", the service needs to have a point of view (or UX to clarify) whether you want to dismiss it permanently or temporarily (I'm not in the mood for it right now).
You also need to deal with the cases where someone accidentally hits the button.
You also need to think about people who use multiple devices.
Should the algo's now update to say you don't like podcasts? You don't like talk shows? You don't like podcasts with themes that Rogan covers - what themes would that be?
Well, sure, there's infinite room for scope-creep. That doesn't take away from a minimal solution that works well from the user's point of view - "I don't want to see this, make it go away".
Now take that thought and apply it to someone proposing to put a permanent Rogan-ad on the home screen. One of the first things that is going to come up is "but how can users remove it?" At the level of thought you're talking about here, someone somewhere already made the conscious decision to not make it removable.
I agree that a good product would do all these things and have a way to not show recommendations you don't want, but I get why these things might not exist.
When I worked in a <100 person startup we'd "just build it" and I'd probably spend a few hours on this, but we didn't have all these concerns. We didn't do user testing, we didn't care about scalability at this level. Now I work on Google Play, and if you want to add a button like this (that will need a database query) to a frontend it's a ton more work because the scale is so different.