I will say that our experience is that the happy path for virtually any customer is to ship the MVP as soon as humanly possible. This also means each new/revised feature after the fact. Only once the customer is actually screwing around with your app or feature will they start to develop a true understanding of what is unfolding relative to their daily life or business.
Our customers have extremely high expectations for the quality of output from our application. Their entire business hinges on whether or not we marked a specific checkbox correctly on one of many insanely-complex forms. We started out on this project with a mentality of "its gotta be perfect and we gotta be done at some point". As a result, our development cycles dragged on for months with the customer testing everything all at once on a single "drop dead day". Thankfully, we were able to get away from this mindset. We went from 'almost killing the company' to 'everyone is extremely happy' simply by delivering features to customers on a daily basis. Having that nearly-immediate feedback on new code from the customer means that the responsible developer likely still has most of the abstract concerns loaded into their mental cache and can quickly iterate if needed.
One other aspect that really started putting leverage behind us was building our own integrated tools for easily investigating exceptions or other issues in customer environments. If a user of our application experiences an exception, we are typically reviewing it within 5 minutes (without them having to report it to us explicitly), and if its a trivial affair, a build with a fix would be available for update that same day. Having the ability to trace user events through our application is probably the single most impactful troubleshooting tool available to us aside from the raw logs.
Ultimately, all of the above is the acknowledgement by us that software development is a very hazardous affair, and that we need processes and tools available for rapidly engaging these hazards when they arise. The sooner you realize you have the wrong answer to a problem, the sooner you can go off and find the correct one.
Our customers have extremely high expectations for the quality of output from our application. Their entire business hinges on whether or not we marked a specific checkbox correctly on one of many insanely-complex forms. We started out on this project with a mentality of "its gotta be perfect and we gotta be done at some point". As a result, our development cycles dragged on for months with the customer testing everything all at once on a single "drop dead day". Thankfully, we were able to get away from this mindset. We went from 'almost killing the company' to 'everyone is extremely happy' simply by delivering features to customers on a daily basis. Having that nearly-immediate feedback on new code from the customer means that the responsible developer likely still has most of the abstract concerns loaded into their mental cache and can quickly iterate if needed.
One other aspect that really started putting leverage behind us was building our own integrated tools for easily investigating exceptions or other issues in customer environments. If a user of our application experiences an exception, we are typically reviewing it within 5 minutes (without them having to report it to us explicitly), and if its a trivial affair, a build with a fix would be available for update that same day. Having the ability to trace user events through our application is probably the single most impactful troubleshooting tool available to us aside from the raw logs.
Ultimately, all of the above is the acknowledgement by us that software development is a very hazardous affair, and that we need processes and tools available for rapidly engaging these hazards when they arise. The sooner you realize you have the wrong answer to a problem, the sooner you can go off and find the correct one.