If you peek inside the list of strategic imperatives at companies in various industries and geographies, you’re more likely than not to find initiatives related to building out an internal “software company” that produces software that can be sold to the company’s customers.
The rationale for this is fairly straightforward. In a world of constrained supply chains and uncertainty, software can represent a consistent recurring revenue stream that’s not constrained by parts or labor shortages. While the startup costs are high, it costs Microsoft or Spotify essentially nothing to add another subscriber to its platform, and rather than wondering if semiconductors or plastics from a distant supplier will arrive in time, the new customer can be provisioned instantaneously.
Many IT departments have a newfound respect and even some degree of swagger after shifting workforces to remote work, launching new collaboration platforms in record time, and perhaps even building and launching several internal software tools.
It might seem logical and perhaps even easy to shift the focus to the external market and assume that you’ve already got all the pieces necessary to launch a commercial-grade software company with little investment or additional resources.
However, it’s not that simple to become a software company. Here are some typical approaches that are likely to lead to failure:
Going to Market Early
Many companies with interesting in-house applications might assume they only need to clean up some internal references and put a price tag on the application for customers to start beating down their door. This effect might be even more apparent if the software has been provided to a few external customers and they’ve willingly adopted it.
This approach assumes the external market will behave the same way as your internal users or as a limited set of external customers that may be using your software as a supplement to a broader relationship. Your employees might “love” your internal application, but they also were not given a choice of commercial alternatives.
To avoid falling into this trap, spend the time researching the market, and determining if customers are willing to pay for your software and what they expect. You may be surprised that the external market demands a vastly different level of support, security, service levels, or emphasizes features that aren’t as relevant to your internal user community.
This research might be disheartening, as you may quickly conclude that taking your internal application to market is a bit more complex than you may have assumed. But it’s better to come to this realization before prematurely launching and quickly failing.
Using Your Internal IT
Your internal tech staff are likely diligent and capable individuals. However, it’s unlikely that they are a commercial-grade product development team. This isn’t to suggest that they’re inadequate or substandard. A different set of capabilities is required for developing commercial software products than the typical work done by an internal IT team.
Suppose your company builds and sells physical products. In that case, you’ll quickly find that commercial software development resembles physical product development more than internal IT. IT also has different metrics, objectives, and organizational structures than an effective product team, which will handicap their ability to create software products even if they have deep software engineering experience.
Just as you wouldn’t assume that an excellent salesperson would be a great marketer, don’t assume that a high-performing IT department would readily transition to an effective commercial software development team.
If you want to launch a commercial-grade team quickly, consider augmenting your team with external resources. Like physical products, you can “outsource” everything from production to testing to support. Follow the same process of assessing internal capabilities and determining what’s worth bringing in-house that you would with any other business function.
Skip the Marketing
That software tool you developed that your employees love might cause you to assume that placing it out in the market will result in a flood of sales. However, your company isn’t the only one that sees the value in launching software. The market is filled with a half-dozen software solutions to even the most esoteric problems.
Similarly, you might assume that placing your tool in a popular marketplace will result in quick market traction. Or you may think that your existing salesforce will be able to quickly sell software alongside the products and services they’re used to. These assumptions are generally untrue, as software requires dedicated marketing and sales support like any other product.
However, the magic of recurring revenue and low incremental costs typically requires a different sales and marketing approach. Unless you’re selling a highly specialized and extremely costly application, you’ll likely need a lower-cost approach to marketing and sales that’s different from your existing field sales force.
The same considerations apply to your post-sales team. Paying customers will require and expect a different level of product support than internal users or customers that use your software as part of a larger relationship.
Like any endeavor, if you find your strategic planning seems too good to be true, and you’re predicting a flood of revenue by merely repackaging an internal software tool and throwing it out into the marketplace, you’re setting yourself up for failure.
Launching a software business is as challenging as creating a new product or service category and should be undertaken with the same diligence and risk analysis. Just because you have a competent tech department and have seen some success with existing tools doesn’t indicate near-certain success. Take the time to assess the market, understand your customers’ wants, and configure your software company with the right capabilities and structure.
