| You should step back and see the big picture. 1) they don't have to use your software. they could write their own, or choose another vendor, or do whatever your software automates manually. if they are using your software, they have chosen that option because, on balance, it meets their needs. that's not to say it's perfect, but it must do more right than it does wrong. > For example they might spend an hour working on a task and then suddenly our code runs into an exception and their data is not saved properly. Nobody should ever do this! Spending an hour working on unsaved work is not sensible. Either your software should save it along the way, or they should do their work in some other place (notepad?) that saves it incrementally, then copy and paste it in as a last step. This is an example of where you need to step back and see the whole picture - it shouldn't be a case of doing unsaved work for 1 hour then saving with 100% reliability, it should save incrementally. Even if the save code were 100% reliable, they would still lose their work if they lose power, have a network disconnect, etc. Unless you step back and understand why they are choosing your application, despite these problems, you won't be able to see the most important aspects of the business. |
> if they are using your software, they have chosen that option because, on balance, it meets their needs
This doesn't hold in any enterprise setting.
Coming to this case that OP describes, I think OP, you have high empathy and are passionate about your product. Since you're likely an entry-mid level engineer, sometimes others have more context of the business setting.
It would be good to implement ideas like: 1. Tracking crash reports 2. Coming up with a test framework that helps avoid regressions 3. Coming up with a script that can analyze errors, which reduces manual ops. 4. Setting up a job that compiles these errors and send it out over email every week, so managers and business automatically learn about what users are seeing.