While enterprise software has advanced every industry from retail and finance to security and IT, it still has a well-known issue: it’s often hard to deploy and even harder to use. In some cases, rollouts have taken up to a full year, which is why many enterprises have been forced to move toward a software-as-a-service (SaaS) platform instead. What’s worse is that the user interface of the software is often still a mess, which is a reason why there has been major buzz around “consumer-grade interfaces” in the last few years.
And an even bigger issue still remains: enterprise security software often doesn’t work. This problem is common in enterprise tech development, and can be even worse in security product development. Typically, security products are tested in a lab, which is a controlled space without any “real world” external factors that can affect development. This type of research and development (R&D) can be problematic; when the product is finally deployed at a customer site, it could suddenly face hurdles that it did not previously encounter, leading to countless issues with the practicality of its design.
Thus, the following scenario happens all too often: a developer will have a brilliant idea for a new piece of technology that will save companies millions or disrupt an entire industry. So, he or she will go off and build it with the help of an internal team, leading the company to turn around and sell its new technology to customers right away.
What’s worse is, according to a Trustwave report, 65 percent of respondents feel pressure to roll out IT projects before they have undergone the necessary security checks and repairs. The silver lining is that this number has dropped from 77 percent in the previous two versions of the report, which speaks to improved software and application secure development, as well as companies’ realization that catching vulnerabilities early is less costly than dealing with them later. But even when developers make sure to run through the necessary checks and repairs with a new product, the software itself is often so complicated to use that it takes a long time to roll out. During this waiting period, developers may be required to make so many custom builds that the product could be scrapped entirely—wasting time, money and talent.
The challenge of this kind of in-lab R&D is that many developers make assumptions that do not translate to real world environments. For instance, say a company develops a utility to handle the installation of an agent on 50,000 company computers. In theory, this utility would save the company time and effort, but what if the customer has to deal with the nightmare of managing 50,000 agents with regular install and update failures? Or, what if the conditions that allowed the product to work well in a lab setting suddenly make it ineffective and error-prone once it’s used on customers’ often dirty data?
Many enterprise software companies run into this exact predicament. So, how can they avoid the disconnect between the lab versus real-world R&D, and mitigate any problems before the roll out? Companies can do so by establishing the following goals from day one. They should aspire to make the software easy to deploy at a large company, enable employees of varying skill levels to be able to use it, and perhaps most importantly, make sure the product is effective in the real world. Put in these terms, the idea may seem so obvious that many people are often surprised to learn that the majority of software isn’t already developed this way.
A technique that solves all of these challenges is actually rather simple: design partners. Such a partnership entails working alongside several customers through the earliest stages of product research and development. This process enables both the developers and the customers to see what works and what doesn’t in real-time, as well as which features and functions are easy for non-developers and engineers to use and vice versa. There is a unique advantage to being able to connect directly with customers during the software creation process. That, in turn, leads to a product that’s far simpler and faster to deploy and use, as well as more effective than alternatives on the market.
While R&D in real customer environments can lead to great end results, it is not an easy process. There are a few key elements to consider in a successful customer-developer relationship in order to create an improved end product. For starters, the customers that companies choose to involve matter. The R&D process requires customers to trust their developers, as they will need to access both their data and people onsite. Some may see this openness as a vulnerability, but it’s a necessary risk customers need to take for the partnership to work. Second, companies need to be willing to show customers their IP long before they would normally start to do so, which could be a concern to companies that aren’t comfortable with customers seeing a partially finished product. Many may see both of these choices as leaps of faith, but in reality, creating enterprise software is in many ways a leap of faith as well.
At the end of the day, it’s important to remember that both sides face a level of risk, whether it’s a company worried about its product suddenly becoming ineffective, or a customer constantly having to deal with install and update failures. Communication is key, as the ability to troubleshoot real-world issues with the customers who encounter them can help ensure that the software is effective and running smoothly for both parties involved. While not all firms may be able to test in a controlled lab environment, it’s an idea worth considering if they have reliable customers who are willing to take the risk with them. If we’re truly living in the “age of design,” then taking the design partner route can prove very effective for a more successful new product roll-out.
Nir Polak, Co-Founder and CEO, Exabeam
Image Credit: NakoPhotography / Shutterstock