Sometimes you have to shock the customer

When I raised some tickets related to cumbersome and ineffective workflows, these were treated low priority by the decision makers. 

I was convinced that one didn't take into account the unexpressed users’ requirements to not just get a user’s job done, but to also get it done quickly.

 Powered by my conviction to change our company's view on these tickets, I prepared a plan.

 When the customers were invited to our offices the very next time to test our new features, I didn’t prepare anymore a bunch of isolated and checklist based test cases. This time, instead, I prepared just one simple and realistic end-to-end scenario that combined the features of productive version 1 with the new upcoming features of version 2.

 I wasn’t astonished to be right with my original concern about the workflow effectiveness but I was really surprised about the reaction of the domain experts. It became obvious so quickly to all of them when they tried to execute the prepared scenario. All agreed that this process isn't at all efficient. One customer even said that they are going to boycot the productive usage if we are not significantly improving the current implementation.

 As a result, the initially low rated internal tickets became a much higher attention and even had to be implemented as part of late change requests in the middle of the stabilization phase. My bad. The timing was a disaster. But the timing was so bad, it was almost good. These late changes payed off. The implemented improvement was significant and worth it. The customer appreciated the correction and our ability to respond quickly to their concerns. 

They probably did because we "shocked" them with what they were getting next. Okay, it worked this time, but I guess we shouldn't do this too often.

(Source: Simply the Test)