It’s fairly common practice in most small companies to sell software capabilities that do not actually exist at the time of sale. When the deal closes, the engineers are given the task of meeting the expectations that were vaguely created by the sales person during the selling process. Often, the obligation to build the feature is a complete surprise to the engineers, as is the delivery date commitment. The justification for all of this is this is “that sales is hard and the engineers did not build the right features.” The rationalization often goes farther stating revenue is mandatory, and there is no such thing as bad revenue. After all, the revenue allowed the company to live to see another day. If only things were that simple.
Let’s take a step back and think about what a software company is about. Software product companies are attractive because the investment they make in features can be leveraged into repeat sales, returning a multiple of the investment. This is what ROI is all about and the higher the better. Even if the cost of a feature is recouped in any single sale, it does not create leverage. It takes multiple sales to pay for and make profitable the investment in any particular feature. Hugely profitable companies sell the same software over and over and over.
In order to be able to sell the same feature multiple times, it needs to be general enough to appeal to many prospective customers. To make features suitable for large audiences, they require careful design and discussion with multiple types of users. The resulting trial and error design process converges on a design good enough to make the ROI necessary to grow revenue and make the company profitable. Following one particular customer’s needs for a particular feature usually does not lead to a high revenue opportunity. These bespoke features are defined in too narrow a way to provide the broader capability needed for repeat sales.
A software company usually needs to have some minimum set of capabilities, in any particular market, to have repeat and robust sales in that market. The Product Strategy identifies these features and targets in a desire to satisfy customers and improve sales (both existing customers and acquiring new customers). This Product Strategy is the result of careful study and discussion amongst the leadership of the company, involving broad input from all factions (e.g. Sales, Support, Engineering, Product Management, Marketing, Professional Services, Cloud Services), as they have a variety of viewpoints into what the company needs to survive and prosper. All Product Strategies are a set of compromises to achieve the broad needs of the various parts of the company. For example, a nice customer feature may be lowered in priority to add a feature allowing Support to be more effective when dealing with customer calls. There is always far more that people want in the product than there is money to create.
Now let’s return to the problem at hand. A bag carrying sales person is goaled to make their revenue number. The sales person finds that a number of customers like the solution but want some extension that may or may not be in the plan. The sales person concludes that the folks in charge of the Product Strategy are just not in tune with the market. After all, he reasons, look at how many features are being requested that are not in the product. He knows he understands what customers’ need better than the people inside the company. This ignorance of the people in HQ is often the subject of conversation when sales folks get together.
Taking matters into his own hands, while achieving his own quota goals, he sells the customer the capability being requested. This is not necessarily a malicious act on the part of the sales person. They often truly believe they are helping the company as they think they see the market better than the people inside the company. This commitment is self-serving but is often rationalized as a sincere belief that he is helping the company because he knows better. We will assume, in the present example, that the customer knows the feature is not in the product and is willing to wait for it. The problem only gets worse if the customer is lied to, which does happen. Let’s also assume that the feature in question is already in the Product Strategy, but down the road too far away for this particular customer.
Let’s see what actually happens once this sale is closed:
The sales person is off to other things and the problem of fulfilling the obligation falls on others. There is no additional financial incentive for the salesperson to make this work. The problem becomes something a Team from Product Management and Engineering needs to solve.
Since the capacity the Team was already committed to other items in the Product Calendar, this whole effort delays those features and potentially causes other customer commitments to be missed, which someone now needs to deal with.
The Team needs to understand the customer expectations and write them down in more formal ways. Given that commitments are usually vague, it is often hard to get the customer to agree to precise acceptance criteria. The customer will often say “I’ll know it when I see it.”
The Team needs to design the feature and iterate with this customer (and others) to create something of general value, to create ROI.
The Team then builds and tests the feature.
The Team delivers the software to the customer who is asked to accept the work. This is where the problem usually becomes more severe. In the sales cycle, the customer’s expectations are usually set with some vague language, after all “let’s not confuse selling with installing”. Only the customer can truly say when their expectation is met. Given that customers don’t really know what they want ‘till they see it, they generally do not accept the first version and make additional demands, which the company feels obligated to meet.
The additional work will cause the delivery date to be missed. The customer gets upset, making all sorts of demands on the business. The company now has a black eye which it wants to repair, making this now troublesome customer become a very high priority for Support and Engineering. The Team is blamed and is put under pressure to move faster. These demands and pressures, unfortunately, usually result in less testing and less complete features (i.e. quality suffers).
The Team adds the bespoke capabilities and skimps on testing in order to meet the now even more aggressive dates. The lower quality creates stability issues that show up later at no trivial cost.
If the customer is satisfied, move to the next step. Otherwise, go back to step #6.
Support and maintain the new feature forever, no matter how bespoke the solution is.
This is a simplified version of real scenarios that I have seen many times in many companies. Multiply this by some additional sales people and you quickly have a company that is out of control. It is an impossible situation that quickly leads to less productivity in gaining market share and attracting new and existing customers. Increasing the work on items brought randomly by sales means less work on features that were deemed important to achieving market success. We won’t even discuss the great tension it creates in the company.
The assumption we made earlier that the features being sold by the sales person were in the Product Calendar was generous, as that is often not the case. When the feature is not in the plan, the money being invested in making this one customer happy is not leveraged. The normal product revenue usually does not even cover the cost of the work, and certainly will not reap a reasonable ROI. Sometimes, sales will extract an additional charge to cover the cost of the bespoke feature, but it has low ROI. Product companies need high ROI to prosper.
But the largest cost of this mis-adventure is the lost opportunity cost. Companies barely have enough R&D money to build all the features they need to have robust sales. Every dollar spent on R&D must be carefully thought through in order to create a competitive advantage. The distraction of a scenario like the one described above creates a long-term disadvantage for the company’s competitive stance. They are not moving forward in the market, they are chasing revenue. They are acting like a custom software house, not a product company.
To avoid all of this, a lot more discipline is needed in the company. Selling a feature before it is built is a tough business decision that should be made by the same Execs that decided on the Product Strategy. The trade-off’s need to be understood and bought into. The exact definition and the acceptance criteria need to be written down and signed off on by the customer and the team that is going to build it before the sale closes, before the deal closes. Credible estimates need to be done by the team who will build the feature. And lastly, the sales person involved needs to have some skin in the deal so that false expectations (which can be a whisper in the ear of the customer) are eliminated and controlled.
Not all revenue is the same. There is such a thing as bad revenue. Bad revenue can create negative ROI and a bad reputation in the marketplace. Bad revenue pushes away good revenue, as the product will be less competitive in the future. Product companies need to build products that have a large positive ROI, not bespoke features that do not help the company win repeat sales. Sales discipline in “selling what is on the truck” is a necessary to achieve success. Rigorous approval processes should be mandatory and are essential when agreeing to sell a feature before it is actually built. There should be a penalty for not following the defined process. Lastly, selling a feature and then building it shoudl be a rare occurrence!