I think it holds true throughout if you scope it to knowledge about your reports’ domain. If you’re managing managers you should have a good handle on what a manager does and different ways to do it.
It seems like one reasonable response from game companies is to include a service agreement with all games that explicitly limits the guaranteed server uptime. Ie “buying this game only guarantees operation until Dec 31 2028”
No clue if the market will go for that but it would meet the issue head on. “Companies will provide server binaries” on the other hand feels like pure fantasy.
Overall I’m glad folks are trying to do something about this.
This is so cool. The discussion section [0] does a good job of explaining where this fits in, scientifically, but all I can think of is spies sending messages encoded in a piece of scotch tape.
In my experience a good async culture is sustained by regular, high-quality check-in meetings. They serve as connecting moments that support team cohesion and camaraderie.
If there's two things HN hates it's UX designers, PMs and off-by-one errors. As a UX designer I have to laugh: one of the most important parts of building good UX is humility and a willingness to be wrong. The confidence with with many on HN assert that they know what the right UX is for any app is exactly the same error that bad UX designers make.
As always in product the user's frustration is real and important but their ideas for a fix are almost never the best choice for the product, the company, or most users.
> It’s like these products that are in a way some of the most valuable products in the planet, are given a junior web dev and a “UX designer” who really doesn’t know anything about UX.
What you pay attention to grows. And company's pay attention to those things that move the needle on revenue. For many successful platforms UX doesn't move the needle much anymore (if it ever did). LinkedIn has effectively won their space and a clunky UI isn't going to show up in the numbers.
LinkedIn might have amazing designers on staff, but if leadership isn't prioritizing updates and fixes it won't happen. And leadership won't prioritize it until the problem shows up in the numbers.
My take in this (ironic) comment was just "no feature is free", which I don't think should be odd coming from a UX designer!
> the idea is perhaps that users vibe-code their own distinct UX with everything valuable to them
I do find this interesting. I work on a complex business operations and reporting platform and every facility has their own lil quirks. More control in their hands would let them smooth out their workflows while still relying on the foundational work our platform does.
If you're building for individual users you're not going to succeed. We all prioritize for broad success from the beginning.
I'm very into the idea of inversion of control and giving users this flexibility but I agree with GP that the SaaS company critique is misplaced. I hope you find enough success with 100X that you end up coming to the same conclusion.
I'll also add that one of your video examples is essentially a Twitter spam generator; is that the kind of feature you think SaaS companies should be prioritizing?
Gonna need at least a single link to a source before I believe this. Googling provides Facebook links and YouTube videos from Fox News and AI generated “news” sites.
I believe that everyone deserves food housing and and security regardless of what they do or don’t do professionally. I have no logical argument only a moral one, which I sense would not be sufficient to convince you.
From the post it's clear that the shop has a set schedule of services and prices that the bot is pulling from. All the things you're saying are true for a shop that needs to custom quote each job but do not apply to the situation as presented.
Yep! That's almost always the correct solution. It can be a lot to figure out, tho: which perspectives are most valuable to present? Are the linkages clear? Does this kind of box belong on THIS chart or THAT chart?!
As the resident Diagram Maker at my job I really appreciate any and all discourse on the topic. Knowing the purpose of your diagram is a hugely under-appreciated part of the process. Service flow chart or system architecture? High level system overview or actionable, followable flow-chart? The engineer in me always wants to put All The Things in the chart, to make it maximally "correct". It's never the right move. But how to make it clear what's included or not, and why?
I still struggle with finding the best approach each time; I'd love more discussion of this stuff.
The issue is that in domains novel to the user they do not know what is trivially false or a non sequitur and the LLM will not help them filter these out.
If LLMs are to be valuable in novel areas then the LLM needs to be able to spot these issues and ask clarifying questions or otherwise provide the appropriate corrective to the user's mental model.
In my job the task of fully or appropriately specifying something is shared between PMs and the engineers. The engineers' job is to look carefully at what they received and highlight any areas that are ambiguous or under-specified.
LLMs AFAIK cannot do this for novel areas of interest. (ie if it's some domain where there's a ton of "10 things people usually miss about X" blog posts they'll be able to regurgitate that info, but are not likely to synthesize novel areas of ambiguity).