Understand why you got (or didn?t get) the RTOS business
August 15, 2017
Anyone working with embedded systems software is likely to be somewhat familiar with RTOSs. I?d like to give you some insight into the business of buying and selling such software products.
Anyone working with embedded systems software is likely to be somewhat familiar with real time operating systems (RTOSs). I’m not going to look at any RTOS technicalities here, but I’d like to give you some insight into the business of buying and selling such software products.
Commercial OSs for embedded applications have been available since the 1980s. The first such product was probably VRTX (pronounced “vertex”) from Hunter & Ready (they became Ready Systems, who were acquired by Microtec Research, who were acquired by Mentor Graphics, who were acquired by Siemens…). It is the case, with any product, that there are different ways to buy and sell, and numerous approaches to business practice. Software presents some unique challenges, which I will illustrate with a true story. (I have changed the names to protect the innocent and keep the attorneys off my back.)
Once upon a time, there were a bunch of smart guys. They were the embedded software development team at a company that I can’t name. They had concluded that their design required an RTOS and set out to find one. They reviewed the 200 or so available products and narrowed their search down to just two—the products from Alpha Corp. and Beta Corp.
The team developed a long, detailed list of their requirements, which they sent to both vendors, with a request for a quotation. Both companies were very interested in the business, as it was a large project and a substantial budget had been allocated.
All salesmen learn quickly that a request for quotation, particularly accompanied by a detailed requirements specification, is an indication that the business may be there for the taking. This is a time to jump. The guys at Alpha did just that and rapidly responded with confirmation that they could fulfill all the requirements. They quoted a price that was well within the customer’s budget (as the salesman had done his homework).
At Beta, the sales team was worried. They studied the requirements list carefully. Some things were readily accommodated by their product. Others could be implemented, and the size of the potential order made this viable. However, there were a few requirements that were either downright impossible or, at least, were incompatible with other parts of the specification. After some thought, they responded to the customer, giving a detailed outline of what they could and could not do and a price. That price was significantly higher than Alpha’s, but still just about within the budget.
After a matter of days and very little further discussion, Beta were awarded the contract.
So, what happened? A company offered a complete solution at a low price, but the order went to the company with the incomplete solution at a higher price. This doesn’t appear to make sense. The clue to the mystery is at the beginning of the story. The customer’s team were very smart guys. They had laid a trap. They knew that some requirements would be problematic or impossible, so when Alpha said “no problem,” they were out of the game.
Beta took the business because it operated in an ethical manner, communicating straightforwardly and honestly with the customer. This is always good policy. The team at Alpha knew exactly what they were doing. They simply wanted to take the order and let Tech Support deal with any issues later—a short-term attitude. For selling some types of product, this strategy can be successful, but an RTOS sale is (hopefully) the beginning of a long-term business relationship, which needs a solid foundation.
