You might think of salespeople as workers in a very distant part of your organization, but there's probably a need for one much closer than that—maybe even at your own desk. As Linda Hayes explains in this article, if you want to win or keep a project, you might just need to try channeling your inner salesperson.
If you want to get or keep a job or a project, you—or someone responsible for you—must get funding and keep it. Simply said, someone has to buy your services. And, while it may be paid in the form of facilities, payroll, and expense checks instead of a direct, lump-sum payoff (don't we wish?), it is nevertheless real money that has to come from somewhere. That means someone had to make a sale, because getting budget allocation is a sales process, whether we realize or admit it.
I mention this because my experience is that we in the software testing business tend to overlook it. In all of our zeal to ferret out defects and trumpet quality, we don't pay enough attention to the bigger picture, which is "What is it worth and to whom?" Because of this, we often have trouble defending our miserly budgets, let alone expanding them.
I realize that not everyone is cut out to be a professional salesperson, but we should all learn to think like one. If we can do this, then we can get all the money we need to do an excellent job, as opposed to fighting a rear-guard action against reductions or even total extinction. Thinking like a salesperson means:
- Identifying prospects—Who stands to gain or lose if testing is good or bad?
- Understanding their pain—What keeps them up at night?
- Communicating your value—What is your work worth?
Let's look at each through the lens of a salesperson.
A prospect is a potential buyer for whatever you are selling. Generally, prospects for software testing are those who are at risk, because it costs them time, money, or reputation as a result of errors or downtime. This obviously includes the end users but may also include less obvious people. Developers, for example, may be required to perform late-night fire drills in a failure situation. Auditors—believe it or not—have a stake in whether the software correctly enforces internal controls. And, if the failure is bad (or public) enough, top management may feel the repercussions. In today's highly connected world of integrated supply chains, suppliers and consumers the world over may feel the pain.
Be creative here. Think outside your own organization and management chain. What is the ripple effect of software failures? Realize that the more prospects you identify, the better your chance of making a sale. Once you identify your prospects, the next step is to get inside their heads.
Salespeople love pain—not because they are sadists or masochists, but because where there is pain, there is usually a motivation to cure or prevent it, and that translates into a sales opportunity.
A good question to ask a prospect is "What keeps you up at night?" This will elicit fears, which is good, because professional salespeople know that emotions drive most decisions, no matter how analytical we all think we are. Most people would rather avoid a black eye than get a gold star. The goal is to uncover the motivation your prospects may have for what you offer. Don't tell them what you have, ask them what they need.
For example, a test manager at a large car manufacturer asked this question of the plant manager. The answer was "Having the line stop." This was a highly automated facility with software controlling almost every aspect, so the plant manager wasn't worried about software defects per se, he was worried about the impact on production. Why? Because downtime translated into a loss of $1 million per minute in lost productivity.
Based on this feedback, the test manager changed the name of his proposed automation project from "Automated Regression Test" to "Automated Production Readiness Verification." He added one extra item to the project plan, which was to run a test daily against production before the first shift started. His restyled project went from famine to feast because it ceased being perceived as a time saver for the testers and was instead viewed as a money saver for the company.