> In the larger picture this is marketing who must focus on knowing the customer and their needs. Is Marketing responsible for UX research in your organization

> In the larger picture this is marketing who must focus on knowing the customer and their needs. Is Marketing responsible for UX research in your organization? > Depending on your goals and context. Does boring sell? Are your customers requesting boring? I'd argue that your customers do not give a flying crap whether or not you're using GraphQL or a plain old relational database behind the scenes, as long as their experience isn't affected. Unless you are a vendor of a non-boring alternative to one of the aforementioned boring tools, boring is absolutely superior...until it doesn't fulfill the needs of your platform. But by then, your company will have reached the point where you can put dozens of engineers on that single issue, and come up with the new flavour of "boring" standard. > But they are essential returns. If the engineers can get the thing to work on their desks then it isn't likely to work for customers. I think one of core tenets of this approach is to make local development as close as possible to production. Staging servers do not always capture production issues either, and IMO their main use is for internal collaboration and demoing, not finding out about issues. If you can replicate an issue locally, you do not need to test on staging. If you can't replicate an issue locally, it's very unlikely that the issue would arise on staging either. Of course, if your codebase has vastly different runtimes in local and in prod, all of the above does not apply.