wissel.net

Usability - Productivity - Business - The web - Singapore & Twins

When Sofware matures you need to cut development to stay profitable, isn't it?


Besides having Fun with Dueck I discover more and more how prevalent system patterns are in business. My special foes are " Quick Win|Fix|Start" which are strong indicators for a Shifting the burden archetype at work (remember the sales cycle). Software is a very profitable business that scales very well (your marginal cost to create another software license to be sellable is practically zero - don't confuse that with "cost of sales"). Nevertheless it is also the playground for the burden shifting pattern. Capitalistic theory demands that high profit margins attract competitors thus reducing the price a vendor can command until the profit margins aren't higher than in the general economy. Of course market incumbents try to raise entry barriers to prevent such competition (and when they overdo that, they get investigated, sued, convicted and fined). So the high profit margins require constant attention since the competition is closer than they appear. But what should a company do when competing in a mature market? Ask your average MBA: cut cost of course. So very successful businesses do that? Like the insurance industry in Singapore (which managed to sell more insurance per household than anywhere else)? Nope: no cut in staff training, no cut in the work force, but more incentives. What happens when cost are cut to fix short term profitability?
Shifting the Development Burden kills your product
Cutting back on R&D will improve the bottom line when the cut is made. But it will also slow down product improvements. The slowdown not only stems from a reduced team size, but also from becoming preoccupied with ones own survival (will I be the next to be cut?). Once the basic security is gone, the readiness for disruptive innovation disappears making the vendor even more vulnerable to its competitors' assaults. In result the pain of the symptom overshadows the root cause and more cuts are made. Go and visit the ERP Graveyard to get an impression for just one software category. Especially in a time of sliding revenues taking a controlled risk could revitalise your product unless you are chronically risk averse. And don't rely on a customer council (you get faster horses then) but on your ability to innovate. Unfortunately the cost cutting just removed the necessary funds and, more importantly, the personal security that leads to innovation.

Posted by on 17 July 2011 | Comments (2) | categories: Omnisophie Software

Comments

  1. posted by Nathan T. Freeman on Sunday 17 July 2011 AD:
    The pattern you've so eloquently outlined here applies not just to software, but to any business practice where the core value of the business is innovation. Automotive, biotech, materials... just to name a few, all have this problem. Interestingly, companies in these areas have proven MUCH better at erecting barriers to competition than software companies. Patents, import tariffs, job protection schemes, unionization, bailouts -- all used highly effectively by big companies in mature markets to subsidize their lack of innovation.

    One notion that does seem to me to be unique to the software industry is the incredible cost of legacy support. If BMW wants to make a new car with a twin turbo and four-wheel steering, they don't have to figure out how to still have their prior 3 series model INSIDE it. They don't have to put a "2-wheel steering mode" switch on it. They don't have to find a way for customers to buy the car, but only implement the turbochargers one at a time.

    Even when prior versions of software fall out of the SUPPORT cycle, the programs and data built from them remain in the market, and thus still have to be included in the R&D cycle. I can't think of any other industry where this issue has such a huge impact. And the cost is magnified in mature markets precisely because that's when you have the most legacy customers, and therefore the greatest concern over backwards compatibility.

    It would be interesting to look at mature dev cycles and examine what kinds of costs could be cut not by slowing innovation, but by cutting out legacy cancers.
  2. posted by Phil Salm on Monday 18 July 2011 AD:
    @Nathan I'd argue that some software companies DON'T worry about backward compatibility for this very reason. Add to this keeping a closed system that only works on limited OSs, hardware or with the vendors own complementary products, and a vendor can achieve very significant savings that it can then put to innovation. In markets often driven by RFPs that do feature comparisons, closed system companies unconcerned with backward compatibility will be better able to compete as long as customers prefer the next new software feature over TCO or open systems.