When working to drive meaningful improvement in B2B environments, business professionals…myself included…will too often get tripped up by the edge cases and hypothetical scenarios that could happen, whether or not they are very likely to happen. In other words, we often get hung up on things that are possible, but not probable. And while the impulse is understandable, trying to craft solutions that anticipate and address every conceivable situation is a fool’s errand.
The reality is that designing a sales solution that covers any and all possibilities isn’t just daunting; it’s impossible. After all, there’s no way to even identify every edge case or “black swan” situation upfront. And even if you did somehow manage it, you’d be dealing with a problem set so complex and unwieldy that designing a solution would give Rube Goldberg a headache. The more scenarios you try to account for, the more convoluted your solution becomes, making it bloated, untimely, inefficient, and ultimately unworkable.
Sales Ops needs to plan around the probable, not the possible.
We need to design sales processes, procedures, and systems that address the heart of the Bell Curve—i.e. the things that are most likely to occur in the future because they are occurring most frequently in the present. For example, it’s not unreasonable to expect a new and improved forecasting model to “only” cover the most common 80-90% of opportunity profiles and configurations at the outset; leaving the rest to be treated as one-off exceptions. Similarly, we’d design a new quoting interface to be intuitive and user-friendly for the “meaty middle” of the salesforce, rather than designing with more tech-savvy or analytical users in mind.
All that being said, however, we do have to be realistic. As we’re planning and designing around the most likely scenarios, we can’t just ignore all those pesky “what ifs” altogether. In fact, as we highlight in Managing Successful Sales Ops Projects there are three very good reasons for addressing the edge cases, exceptions, and anomalies upfront, even if we don’t craft our solutions and interventions around them.
First, and perhaps most annoyingly, people can use edge cases and anomalous events as a conscious or unconscious means of resisting change. If I had a dollar for every time I’ve heard something like, “Yeah, but what if this thing that never happens starts happening everywhere all the time?” you wouldn’t be reading this because I’d have retired a long time ago. Intentional or not, these things can create FUD (fear, uncertainty, and doubt) around your proposed solutions and improvements. And left unchecked, FUD can stall or even kill your initiatives before they can get off the ground.
The fact of the matter is that the moment someone starts waving around unlikely scenarios, you’d better have a response ready or you’re in trouble. Recognize these arguments for what they are and neutralize them upfront by acknowledging that yes, those scenarios could happen, but they’re rare, and here’s how we’ll handle them if they do.
Second, the edge cases can happen eventually. While they’re not going to be daily things, the moment a low-probability event does happen to occur…and you haven’t already pre-positioned the edge cases and anomalies…you’ll get an earful. And suddenly, the perception can be that the entire solution or approach is flawed just because it couldn’t accommodate that one bizarre outlier. Perceptions matter and it’s much better to mold them upfront.
Finally, by putting edge cases on the table from the beginning, you’re in a better position to develop contingency plans. When these anomalies do pop up…and they will…you won’t have to scramble. Instead, you’ll have pre-established guardrails and decision-making frameworks that allow your team to react with speed and confidence. Contingency plans are what transform anomalies, outliers, and “black swans” into manageable nuisances, rather than full-blown crises.
So, what’s the bottom line here?
If we let every obscure “what if” drive our designs, we’ll end up with systems and processes that are too complex to implement, too cumbersome to use, and ultimately too ineffective to deliver real results. Instead, we need to speak to the possibilities while building our solutions around the probabilities. We need to focus our energy on solving for the scenarios we’re most likely to face, while at the same time acknowledging the exceptions as exactly that—exceptions.