There are a lot of biases that come into play when testers think about business criticality. Sometimes, because something's easier to understand, we think it's more important. We get it. If a feature is hard to understand, it can be difficult to really appreciate how critical it might be.
I'll illustrate...
I once worked on a project where we collected data from chemists and then provided tools for them to analyze that data. I distinctly remember two large features of that application. There were these large reports (data dumps) that were generated that contained rows and rows of numbers. There were also 3D modeling tools that allowed you to visibly interact with the compounds being analyzed to help you understand the data.
Because I could easily grasp the 3D modeling, I naturally thought that feature was more critical. I could imagine how someone would use it. I could envision the business process. The data dumps were gibberish to me. It turned out that the data dumps were by far the more important feature. The 3D stuff was used by a much smaller population of the users and had a lot of developer gold plating in it.
There are other biases that can come into play as well, especially if you have a background in the business. What was critical eight years ago when you were practicing in that field might not still be critical today. It's important to ask, ask, and ask again to understand what 's critical to the business. You can't assume you know.
