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.
Once you know who your prospects are and where their pain is, you must be able to explain how what you offer directly addresses that pain. Of course, you probably will have to do the standard ROI analysis just to check the financial box, but it's the fears that aren't realized and the costs that aren't incurred that may be the most valuable to your prospect.
But, it's not enough to communicate your value to get the initial sale. You have to keep it up, constantly uncovering new pain that may have developed and continually reminding all your stakeholders how you are fulfilling their needs. It's a strange—but—true phenomenon that some people do such a good job so quietly that they make it look easy. I know at least one test manager whose company thought the software was stable, so they slashed her process team—only to eventually discover that her process team was the reason it was stable.
Again, remember to communicate in your customer's terms. Don't bore everyone with your S-curves, test case inventories, and defect rates. Those metrics are important to you and your team but not necessarily to others. Instead, couch your value in terms near and dear to your customer's heart. For example, the car manufacturing test manager reported each week how many production processes were verified and, if any issues were uncovered, how many incidents were avoided and their potential cost. Instead of saying, "We found a Sev 1 defect due to database corruption," he said, "We prevented a failure in the electronics assembly process that saved $60 million in lost production." Both were true, but the latter spoke to his audience.
And, please forget all those stereotypes and clichés about the pushy and relentless salesperson. As a friend once noted of the Amway empire: Sooner or later, someone has to sell some soap. Just because you test software doesn't mean you don't have to sell.