The software industry has a number of business models. There are product business models that companies like Microsoft and Apple use. There is also a long tail of small to medium size software businesses that offer custom services. Joseph L. LeBlanc’s has a useful classification of the software business models. I have worked at a number of small to medium size software companies and have some observations from my experience. One observation is that the most expensive type of business model is to not know what business you are in. One example I experienced at a previous company I worked for is money would come in for the company to make a custom “solution” for the client. After the custom software solution was made, the business thought they had an asset and thought it a waste if they had to reinvent the wheel for every customer. The business came to the conclusion that it could re-sell this solution to other customers, offering it as a product. The business broke one of the most important business rules, which is to know what business you are in. Reusing the output from a custom solution for one customer to resell the software solution as a product turned out to be a problem because of how the software solution was built. In short the software was built with quality attributes of one specific customer in mind and on that one customer’s budget. Products have target customer markets and this places value on different quality attributes than writing code for one specific customer and their specific solution. For example, maintainability factors into the business profitability. The most costly part of this bad decision is that the waste was in not reusing the code, when the actual waste came in not building a maintainable product for a target market. The lack of understanding turned what they thought was an asset under one business model into a liability when they switched business models. If you want a more detailed explanation, then continue reading below.
You’ll note that the first thing the business did when it defined itself as a custom solution business was get a customer, find out what they need through conversation and observation and finally deliver value by delivering a custom solution. This is a service software business model where the customer pays money for the business to build custom code to do what the one client asks for. This type of business has a low barrier to entry and that’s why there’s a long tail of small to medium sized software solutions businesses operating on this model. In my specific observation, after the business created this custom code they changed their internal story and business model. The practiced methodology at the business turned from starting with the customer, understanding and delivering value to starting with an existing code base developed with someone else in mind and telling themselves it would be a waste if we had to reinvent the wheel with future customers. “Reinventing the wheel” is code for writing new code instead of using the existing code base. The reason this methodology of reusing the existing code base didn’t work is because the software was not designed with other customers in mind. At the time of software creation the quality attributes of the delivered software only considered the one customer paying money to have the software delivered on a predictable time table (as soon as possible) and with no cost overruns. Naturally, this limits the scope of the project and makes understanding and observing other potential customers in the target market impossible if you are doing it diligently and purposefully.
So the business says out loud that it will now reuse this existing code and sell it as a product, thus the business has changed its inner story to pronounce itself a product company. After time goes by and there’s no product sales, but still more service sales, then reusing the code for a product has transformed into an inner story that the existing code will be the starting point for the new service engagement and this new custom solution will just re-configure the code. The problem with this is the code was not built with re-configuration or a platform set of quality attributes. The code was originally designed for one customer and their specific requirements. The bounding constraints of no cost overruns and a predictable time table ensured by the service contract and project managers made sure that the original code base only took into consideration the specific requirements of the one customer so there’s no rouge engineers “over-engineering” or designers thinking “pie in the sky” or product managers observing and understanding other customers in the target market. Because there’s no budget for that.
The lesson of the story for me is to know what you’re doing and do it with purpose. Once the business starts setting money targets instead of strategy and chasing the money instead of chasing understanding then the business has nothing of value to stand on. The other thing I learned was to not trust what management says, but to observe the systems they put in place and the results the systems produce. In fact, observing the systems put in place and the results is what management should be doing. I’ve found this is not always the case. Tony Robbins once said something I’ve come to appreciate years later, which is that sooner or later you either have the results you are looking for or you have the reasons why you don’t. You cannot always change the system but you can always have the results or the reasons why you don’t have the results and make your own decisions bsaed on this information. If you look at it like this, then even in a constricting business environment you can empower yourself to move forward. The people that move forward are the people that use empowering thoughts instead of using disempowering thoughts.