This mini-series on hardware companies building software was prompted by a recent conversation with a friend. He is contemplating a job at a hardware company looking to build out its software revenue. This company has been making hardware for a long time (and no we are not going to name it). They have struggled, really struggled, in building up their software platform, but many of their customers have abandoned them for some cloud-based software-as-a-service (SaaS). The SaaS alternatives do not have all the features, nor allow the same level of control, but they are simpler to integrate and do not require big upfront capex spending, nor require staff to manage them. He has worked at both software and hardware companies before, and knows he is about to jump into a hurricane.
As we detailed in our previous post, a big part of the challenge is hiring a new team and implementing a new approach to culture. In many companies, this ends up being a very personal, sometimes political challenge. New members joining the executive team who have often spent their entire careers in a completely different social network – 3rd degree connections on Linked, no mutual connections. This is the reason companies making this transition often need a brand-new, outside CEO, who can arbitrate fairly among the exec team’s vying parties.
Even when the exec team additions run smoothly, change further down the organization are hard. Why do I suddenly have ten meetings with that new team on my calendar? What do you mean we have to get the new team’s approval on our months-old product roadmap? In most hardware companies, what software teams that exist tend to be siloed off from the rest of the engineering organization. Here are our specs, build some software for them. Successful companies find a way integrate the two teams as closely as possible, bringing in the software people on day one of product planning. Our friend is looking at a Product Management role which means he will likely end up right in the middle of that conflict.
And then there is the actual engineering work. Hardware people often look with envy at software companies’ ability to fix their product after launch. When hardware companies have to fix a product, it is called a recall, and is so catastrophic in electronics that it rarely happens. However, this gap is bridgeable. Aligning software and hardware timing is very tricky. Apple seems to be the only company that has really mastered it, but we do not need Apple-levels of planning for this to work. It just requires a lot of planning, and wide-open communication channels.
But there is more. Our friend made an important point, for a bundled hardware/software product, even the hardware side is manageable. The hardest part is the Service. For most hardware companies, service equates to a small side operation helping customers configure or troubleshoot products. But in order to provide true software as a service requires building up sustainable trust with customers. The relationship has to last for years, not weeks, after the sale. As much as everyone clamors for recurring monthly revenue, most people tend to forget the realities of churn – customers leaving the platform long before the cost of acquiring them has been reached. This cannot be fixed with a quick software patch, or even a replacement box Fedexed to the customer overnight. There is a huge body of literature written about to build these bonds, and these learnings do not come overnight.
Looking back at the many companies who have attempted adding software to their hardware, we think this is likely the root of their failures. While there are start-up software companies that can spring to seven digit revenue in months, most SaaS companies take far longer to reach real profitability. And even those overnight successes often eventually hit a wall and have to retool to regain momentum. This problem is particularly acute for publicly traded companies. Many investors are likely to get impatient with the millions of dollars and years required to build a scaled SaaS business. As a somewhat-related, timely example, look no further than the many media companies trying to build streaming platforms incurring billions in losses as the upfront costs came far in advance of subscriber growth. And this can lead to the stop-start problem we have seen in many organizations, where companies start a software program, run out of patience, only to bring in a new executive team whose job it is to start a software program. <Repeat>.
The more we dig into this topic, the harder it looks. Or more precisely, the longer we think it will take. Established companies, especially publicly-listed companies should budget years, maybe as much as a decade, to put software programs in place. (Maybe this would be easier for companies owned by private equity, but only a small subset of private equity firms would be willing to tolerate these time frames.) That being said, we think this is already taking place in many companies. Go down a list of large electronics companies and there are clear signs of this sort of gradual transition taking place. Probably the best example is Cisco, which seems to be slowly evolving into a software and licensing business. And there are many others.
Building a software capability inside an existing hardware company can be accomplished. It cannot happen overnight. It will almost certainly take longer than anyone expected at the start. This involves a lot more than re-doing a product roadmap, and more than just a few team building happy hours. It will require consistency, patience, and a lot of money.
I have been a software person in hardware companies on and off for a very long time. The cultural issue is that hardware people view software as an expense rather than an asset and that is a very hard mindset to change. Leads to under investment and as you pointed out, a lack of an integrated product plan. Instead, you get software bolt-ons to hardware product plans.
That’s a really good point. I have seen that too.