For many companies, internal software can be a competitive differentiator. No one knows your company’s culture, business processes, and proprietary practices better than you do, so the ability to create software that leverages this knowledge can be quite compelling.
In some instances, that internal knowledge also applies to the broader market. Your internally-developed application could become a commercial offering and create a new revenue stream for your organization. The most famous example of this commercialization of internal tools is the development of Amazon Web Services. A drive to standardize internal IT tools around standard services ultimately resulted in Amazon’s giant cloud computing business, which drives the preponderance of the company’s revenue.
Internally-built software might solve a simple, discrete problem for your organization or extend an internal tool into something relevant for other companies and present a revenue opportunity. Or, an internal application might be wildly complex, solving a unique need that no other technology tool on the market can fulfill.
Creating these applications may seem daunting initially, especially if your company hasn’t developed these types of tools before. However, some techniques and approaches can help ensure you create high-quality, valuable tools.
Start Simple
It can be tempting to start your software development journey targeting a comprehensive platform on the scale of AWS, especially with the massive revenue some of these platforms generate. However, software development at scale may be an unfamiliar exercise for your company. While subscription revenue is extremely attractive, starting with a smaller, straightforward internal application may be better to test your organization’s ability to create software before adding the complexities of a full-blown software sales capability.
Starting small has the added benefit of increasing the likelihood that you’re successful. The best way to promote your organization’s ability to create software is to do it successfully. Small wins are a great way to build momentum and get the support (and funding) to pursue more ambitious projects.
You’ll also have the chance to test your teams’ capabilities and support mechanisms, ranging from tech support to ongoing maintenance, in a lower-risk environment than launching a major commercial platform.
Look for opportunities to build a “point solution” that solves a discrete problem. It might be tempting to start with the digital equivalent of a Swiss Army knife, with a half-dozen tools that solve related but fundamentally different problems. However, the more features and functions you add to an application, the more complexity and risk you create. With a bit of forethought, it may be easier to make a small set of point solutions today that are designed for future integration.
This technique can reduce cost and risk and allow you to get tools into your users’ hands sooner and start collecting feedback. Just as you might only use one or two functions of your Swiss Army Knife, you may quickly hear from users that the point solution you provided only needs one or two other connected tools to solve a significant problem.
From a commercial perspective, a thoughtful point solution can often be better tested and supported than a complex application. Releasing additional, interconnected functionality in the future also provides an opportunity for additional revenue or value to your customers. One of the secrets to the success of early subscription software like Adobe Creative Suite or Microsoft Office 365 was the seemingly constant addition of new applications to the subscription. While many subscribers only used a handful of the applications, the perception that the subscription got more valuable as time went on kept users renewing.
Engage the End Users
Incorporating end users into software design and development is nothing new and is a cornerstone of most modern software development approaches. However, companies often fail to do this well, assuming that merely adding a team member or two with experience in that content area will suffice.
Having members of the development team that know the problem you’re solving is a good start, but it’s often insufficient from two perspectives. First, one or two individuals are unlikely to understand the breadth, depth, and nuances of a particular business problem. That limited subset of individuals might not have experience with every user type or how different departments or teams will use the platform.
Secondly, limiting end-user engagement misses an opportunity to build support for your software before and during launch. The more end-users you involve, the more likely they are to become personally committed to the success of your software development effort and become advocates among their peers. Even if you don’t need dozens of end-users involved, identifying influential individuals and seeking their input can do more for adoption and “change management” than endless slide decks and communications emails.
Understanding the Difficulties of Software
History is rife with examples of companies that performed well in one industry or discipline and then struggled mightily to conquer one that seemed superficially easier. The automotive industry provides an intriguing example. EV pioneer Tesla famously entered “production hell” when it tried to scale up its manufacturing. The company and many of its fans predicted that Tesla’s superior software skills and engineering would translate into revolutionary advances in automotive production. Yet, the company struggled mightily to achieve the scale of its “legacy” competitors.
Similarly, competitors who have largely mastered automobile production at scale have faced significant challenges as they added software and technology functionality to their vehicles, ranging from hardware shortages to difficulties deploying software updates.
Just because your company is excellent in one domain doesn’t mean those skills readily translate to another domain. You may have superlative sales staff, bullet-proof operations, and a long track record of sales success, but that doesn’t mean you’ll immediately be successful entering the software business.
Don’t underestimate the complexities of entering a new domain, whether you’re creating software for internal consumption or as a commercial business. Set expectations and objectives accordingly, and avoid the hubris of assuming your current skills readily translate to what is ultimately an untested competency for your company.
Don’t Forget Support and Maintenance
Getting software built and successfully launched within your organization is only part of the battle to create a new internal application. Too often, tech organizations assume that pre-existing support mechanisms will be equipped for software support. This may be true for basic issues like logins and defect reporting, but you’ll likely also be getting questions on how to productively use the software tool and integrate it into existing applications and business processes.
If you’re launching an application commercially, you’ll be dealing with significantly different customer expectations. Service Level Agreements (SLAs) and reporting tools that are fine for internal tech platforms are likely grossly inadequate for paying commercial customers. You’ll also have additional needs in terms of general customer support. What happens when an external customer has an invoicing question or hasn’t paid their bill? How do you collect and account for software revenue?
Even without the complexities of serving external customers, internal software applications will require ongoing support and maintenance, versus a piece of hardware that can be released “into the wild” and then generally expected to perform for its useful lifespan with minimal intervention. A software application will likely need updates as business processes and market conditions change, and if it’s well-received, you’ll get an ever-increasing number of enhancement and integration requests.
Get the Right Help
Challenges abound when creating software internally. Outside expertise can provide some low-cost insurance for success with the current effort and in building capabilities for future software efforts. Consider two fundamentally different types of help: strategic and capability augmentation.
Strategic help involves ensuring you have the right operating model to produce software effectively. This could include everything from appropriate performance indicators and measurements for productivity to understanding how well your software teams know the user community they are ultimately assisting.
Strategic help should also be used to identify the core capabilities of a high-performing software organization and assess any gaps or weaknesses in your current structure. This exercise may be uncomfortable for technology leads since it’s rare that no gaps exist, and it may feel like you’re searching for flaws. However, understanding the capabilities required to meet your objectives and developing a plan to acquire those capabilities sets your teams up for long-term success.
These gaps can often be filled through specific interventions, from acquiring new tools to outsourcing particular software development tasks to a third party. If you’re early in your journey with developing software, carefully consider the capabilities you want to build internally. They should give your company a unique advantage, and other capabilities can be acquired as needed.
For example, if your company has a significant field service force, having an in-house team with mobile app experience might be incredibly beneficial as you deploy tools to support these individuals. If your company is focused on consumer products, an internal team that understands remotely-updated hardware could be vastly more important than in-house app development.
In some cases, you can completely outsource software production for internal or commercial consumption. While costly in the immediate term, it might allow you to “test the waters” and see which capabilities you’d like to acquire in the longer term.
Be Cautious About Commercialization
Thinking about turning internal software applications into commercial products can be enticing. The dream of “revenue while you sleep” is compelling, especially for companies that are product or service based and don’t have recurring revenue streams that software subscriptions can offer. However, it’s easy to assume that the most challenging part of commercializing internal software is managing all the incoming revenue!
Companies often underestimate the difficulty of marketing and supporting commercial software products and the higher standard of service and support expected from a paying customer. The unique advantage of internal software—customization for your particular business processes and strategy—may also become a detriment in the open market. A tool that optimizes a differentiated process can be a great advantage internally but a handicap to a broad set of customers that might have varying needs.
Another mistake that’s frequently made when considering commercializing internal software is a lack of understanding of the external market. There are millions of great ideas, but not all will be commercially successful. Companies often assume great software will sell itself, but this is rarely the case. Like any other product, software requires deep knowledge of the market, competition, and where to position your product, among other offerings.
Merely offering something cheaper, more technically sound, or with some other minor benefit is not enough to generate sales traction. Your customers generally don’t care that you have better software engineers, a long history in an industry or technical niche, or are offering some unique feature that no other company has considered. Avoid falling in love with your product and failing to understand what the market tells you as you develop and launch a product you’re ultimately considering turning into a commercial offering.
While internally developing comprehensive software applications isn’t a simple task, these tips and the use of partners and well-established development methodologies and practices can help you be successful.
Starting small, understanding and addressing your capability gaps, and gaining a deep knowledge of your market and end users will help you along this journey. Approaching commercialization cautiously will also help position you for success.
Many organizations understand that their core business is fraught with complexity and have spent years adapting to their industry’s and market’s challenges. If you enter the software domain with the same respect and healthy caution, you’ll increase your chances of adding a successful and potentially lucrative internal software development capability to your organization.
