The RTOS business – a story

If you work with embedded software, you probably have some familiarity with real time operating systems. Today, I am not going to talk about any of the technicalities of an RTOS – that can wait for another occasion. What I would like to give you some insight into is the business of selling an RTOS product. Commercial operating systems for embedded systems have been available for over 20 years – the first was probably VRTX [pronounced “vertex”] from Hunter & Ready [which later became Ready Systems, which was acquired by Microtec Research, which itself was acquired by Mentor Graphics]. As with the selling of all products, different companies operate in different ways, but selling software gives interesting opportunities for challenges. I will illustrate this with a true story.

Once upon a time …

There was a team of developers [at a company whose name I cannot reveal] who decided that they needed an RTOS for their latest project. They were smart guys and did some careful research and looked at the 200 or so RTOS products on the market. After careful consideration, they narrowed down their search to two RTOS vendors, whom I will call “Company A” and “Company B”.

They approached both of these vendors with a detailed list of requirements – a very long, detailed list – and asked them to respond and provide a quotation. This was interesting to both companies, as this was a large project and the money on the table was of the order of $1m.

All salesmen know that, when asked to provide a quotation against detailed requirements, they have a good chance of getting the business, so responding rapidly is sensible. Company A did just that. They came back with an acknowledgement that they could fulfil the requirements and proposed a price. The price was well within the customer’s budget.

Meanwhile, the sales team at Company B were worried. They looked at the specification carefully. A large part of the requirement was straightforward and fully supported by their product. Some things would require a little work, but that was OK as there was sufficient money on the table. The problem was that a few of the requirements were either impossible or inconsistent with others. After some very careful thought, they responded to the customer, outlining their concerns and offering a price. This price was significantly higher than that offered by Company A, but within the budget.

Shortly afterwards, with very little further discussion, Company B was awarded the contract.

So, what is happening here? One company offers a complete solution at a lower price, but the order goes to the company offering the incomplete, more expensive solution. The clue was at the beginning of the story: the development team were smart guys. They had laid a trap. They knew that some of the requirements were problematic. So, as soon as Company A said “No problem”, they were out of the game. Company B took the order because they were honest and straightforward – always a good policy. The guys at Company A were not stupid – they just decided to get the money and allow Technical Support to deal with the problems later. Under some circumstances, that strategy might have worked, but is not a good way to build a long term relationship with a customer.

I am not prepared to say who Company A is, but you can probably guess the identity of Company B.