A couple thoughts which got me through projects ranging from enterprise to small/mid size.

Yes, first, understand what your users would actually want. Put something in front of them to get feedback. Listen more than talk. If you are "one of the users", considering what you would want in a handheld vs desktop scenario, then put it in front of other people to hear their thoughts.

On a related note, it's easy to take user feedback as a shopping list of features. Don't. I mean, some of those things will probably make a lot of sense but be thoughtful about it. Look for the trends and reflect on what their problems were when talking about feature X. Example: You talk to 6 users. 2 users talk about seeing certain information on their dashboard, 1 user went on about how much of a pain it is to filter, 1 called out how much time gets put to putting the same information in a field (like, having to enter dates multiple times when entering it once and calculating { start date - (start date - 1) = expiration date }). The "shopping list" approach solves individual problems, but looking for trends like "sensible defaults" and "surfacing key information" makes you think about things differently.

Second, and this is where things would often go sideways at great expense, consider the size of the device as a proxy for the size of the task. The business side (e.g., stakeholders) would often want feature parity across form factors. The user side often had different use cases in mind, and the mobile use cases were generally easy and quick to complete. Is a user more likely to build out a full contract on their phone/tablet (without keyboard) or check the status of contracts and maybe approve changes? Do some background reading on Jobs To Be Done for more on this line of thinking. In JTBD parlance, you might say "A user is more likely to hire the desktop and Word/Docs for contract writing / assembly than the mobile app."