You have to define what matters the most to the customers (or users) in a cross functional manner, e.g dev, PM, Support, execs, SRE.
For example, memory usage alone does NOT usually directly matter to the customers and most of the roles above. It does matter for capacity planning though -- so while it is not an application SLI/SLO, it may be important for devs/SRE and eventually execs (funding). There may be an internal SLI/SLO around keeping efficiency high.
A mobile application taking too long to perform an operation or failing too often are likely to negatively impact many customers or a subset of customers that's very relevant to the business. These often turn out to be a customer facing cross functional issue, i.e support tickets are filed, execs may get called, SRE may be oncall trying to resolve the issue and will need to loop in feature [dev]elopers.
Given all that, there is a need for cross functional metrics (SLIs) and boundaries (SLOs) that will represent customer pain/unhappiness. The absence of such common metrics tend to cause the following effect: "memory usage is low" (devs/SREs), "features have been shipped" (PM), "I didn't get a call" (execs), "users are not happy" (Support).
Google has also published their workshop (under CC-BY 4.0) on how to define SLIs and SLOs:
There is also a blog post on how to tune-up the SLIs (and SLOs) over time:
Disclaimer: I work for Google.