When you build a piece of software (or present any other service), at some level you are making an implicit promise to the end user: you have thought through the problem domain carefully enough to understand it well, you have the skills and tools to build a solution that works for the problems described, you have tested and honed the solution so that it does in fact work the way you expect, and you can be relied on to keep the service or software healthy over a reasonable time.
All of these ask the customer to trust you, and respecting that trust is core to being successful. Different aspects of them are important to different degrees depending on the domain. Sometimes these are really obvious - reliability might be very important in some domains, or data privacy in another. These tend to be the things we focus on the most - if you write bank software and it can’t add accurately, you know pretty fast that you’ve breached trust.
But there are more subtle promises that get overlooked, like user experience and latency. It’s very easy for teams to focus on adding new functionality (we’re makers! We like making things! Removing them, not so much), at the expense of overall complexity "(“tech debt”) or performance (“the toolbar is slow to load, but look, so many buttons!”). This is a very common pattern that teams fall into - software over time makes compromises as it grows, and teams get slowly comfortable with the uncomfortable feeling of letting their users down. Great teams don’t do this - they recognize that every new feature involves a tradeoff, and they’re careful to consider the promises made already, before making new ones.
It’s important to keep these other promises in mind as we build. Our sense of frustration with software that loads slowly or works poorly is often combined with a feeling of being betrayed - I used your software! Why are you breaking my heart?