3 Guiding Principles for Creating Enterprise Apps That Succeed in the Market

Anyone that has spent meaningful time working in the app creation space in any capacity will confirm — with no small amount of frustration — that designing a digital product users truly love is no simple feat.

There are hundreds of constantly moving variables to track, test, and balance against one another during the initial conceptualization phase, and a seemingly infinite number of questions to answer subsequently:

What is the core problem our product has been designed to solve? What intrinsic value does it offer? What are the mechanisms for monetization that we have available to us? Is our price point justifiable? Is the market well-positioned to adopt our technology at scale at this moment in time?

These questions and many more are just the tip of the iceberg in the consumer software sector.

Unfortunately for many new industry entrants, as well as seasoned consumer tech practitioners, that iceberg becomes much larger and more foreboding when the customer for the product in question is an entire organization, as opposed to a single private citizen.

Having just wrapped up with the 5th cohort of startups that I’ve had the great pleasure of mentoring at the City University of New York’s Baruch College, I thought it would be a great time to share some of the enterprise product wisdom I’ve picked up over the years from some of the world’s most talented product designers, engineers, and strategists.

Any person directly responsible for the creation of digital products — be they a manager, visual designer, or engineer — will benefit from keeping by their side a set of battle-tested guiding principles they can reference when encountering uncertainty.

For anyone entering the seemingly infinite discipline of enterprise software, I hope the below three principles provide a solid foundation for your own product toolkit, and the practical collection of solution frameworks it will store.

I. Who Controls the Purse Strings? Who Controls the Controls? Are They the Same Person?

After a tech organization’s business model has been adequately conceptualized, selling the idea of an app meant to be used by a private citizen in the pursuit of private goals is a pretty straightforward process.

Need a busted pipe in your home repaired? A less congested route to pick the kids up from school? How about getting some groceries delivered? For these problems and many more, the answer today is absurdly simple: There’s an app for that.

A consumer application is typically a single digital tool, designed to solve a single problem, for a single individual.

In this setting, the buyer and the user are not two or more separate entities. The person that purchases (downloads) the app and the person that actually utilizes the app on a daily, weekly, or monthly basis, are one in the same.

In an enterprise technology context, however, the dynamics of day-to-day digital tools become a bit more nuanced.

An enterprise application is a piece of software designed to solve a series of strategic, operational, or technical problems for a business, government, or nonprofit organization. To that effect, it is intended to be used by a variety of different employee-users occupying drastically different roles, each with their own unique objectives and agendas.

The user and the buyer are no longer the same entity, and the R&D cycle of your application, as well as the marketing, sales, and user testing processes will take on new and somewhat unfamiliar forms.

From a sales standpoint, one must now be prepared to initiate a months-long rolling pitch to CEOs and CTOs (and potential cadres of other senior executives depending on the size of your prospects) in order to secure buy commitments.

But of course, these folks will probably never touch your technology themselves.

Instead, they will deploy it at scale to their employees in accounting, human resources, sales, or whichever business segment the product was designed to optimize. The heads of these departments are likely to be looped-in as well, seeing as they oversee the actual employee-users of your product.

One must keep very close in mind that the pitch to the c-suite and the rest of the high command must not be the same pitch made to the junior corporate officers that have been looped in.

The former must understand how your product will contribute to the organization’s bottom line by demonstrating improved economics, or potentially providing a mechanism to achieve a previously unachievable organizational objective.

The latter must be shown how your product will improve the performance of their business unit, either by supercharging each individual employee-user with additional capabilities, or by injecting a thin layer of technology into their existing routines and processes to allow for more efficient workflows, and thus a more efficient organization.

If during the presentation your prospect fails to grasp the value of your product, ask yourself if this particular pitch (and the accompanying presentation material or demonstration) has been designed for this specific stakeholder in mind.

For young technical founders especially, this is oftentimes the first hurdle to overcome as they instinctively gravitate to pitching the usefulness of the app’s features, instead of the macro-level business benefits that must be communicated to senior-level decision makers.

II. Nothing Sustainable Can Be Built on a Poorly Laid Foundation

As Kevin Kelly the techno-vangelist so wisely says in ‘The Inevitable: Understanding the 12 Technological Forces That Will Shape Our Future’, internet technology, because it is connected to a never ending stream of flowing information and millions of intelligent human beings, is always in a state of becoming. The Facebook of today is not the Facebook of yesterday, and it is most definitely not the Facebook of five years ago.

A high-quality enterprise application, not dissimilar to a high-quality individual, is one that continues to evolve, improve, and develop new skills and capabilities over the course of time.

In order to allow for this evolution, the structure and design of both the codebase as well as the UI/UX systems of a digital product must be adequately planned before anyone types a character of code into a keyboard or moves a single pixel on a screen.

For product managers and interface designers, that means whiteboarding modular page frameworks and navigation systems that new features can easily be dropped into without the need to rework the product’s existing visual structures.

For programmers and engineers, that means creating clean, commented, and well-documented source code with the flexibility to install additional modules during later stages of the product’s life cycle.

I have found that putting myself into the metaphorical shoes of an urban planner tasked with plotting the design of a town from scratch is an incredibly useful mental exercise.

A town or city, similar to a digital product, rises from a tract of empty space and over the course of time, becomes a living, breathing, ever-expanding organism. The growth rate of said organism may be artificially accelerated if one decides to run a multi-lane freeway through it’s center in order to catalyze some initial tourist activity, but short-term decisions such as these only work to generate temporary growth, often eroding prospects for long-term sustainability in the process.

Lay the foundation that allows for the most rapid testing of the highest volume of new ideas and features, because it is not the features themselves that will win market share.

What will win market share is the ability of the founding team to continuously improve the product without disrupting existing customers’ established habits and routines.

III. Enterprise Technology is Primarily Reductionist Technology

When I discuss digital tools and technologies of any kind, I must always mention the fact that our modern, internet-connected world is exponentially more complex today than it has been at any previous point in civilized history.

Information and data are as ubiquitous as the air we breathe, and with every passing day it becomes a greater challenge to distinguish the accurate from the inaccurate in both personal and professional settings.

In his watershed textbook ‘Persuasive Technology’, renown technologist, psychology maven, and then-Stanford professor B.J. Fogg groups digital products into a handful of core classes, each one named after the benefit it helps to enable.

Fogg postulates that our digital tools can be categorized under one or more of the following seven technological ‘purposes’:

• Reduction
• Tunneling
• Tailoring
• Suggestion
• Self-monitoring
• Surveillance
• Conditioning

Each of these categories are of course expansive enough to warrant individual textbooks of their own, but for our objective of creating enterprise applications that succeed in the marketplace, we will focus on what I consider to be the most critical one: Reduction.

Have you ever glanced over at the clerk’s computer screen while in line at the supermarket? How about the receptionist’s monitor when you are checking in for a doctor’s appointment? I truly hope that none of you have had the distinct displeasure of visiting the emergency room and sneaking a peek at the coordinating nurse’s computer terminal. It is a miracle that our hospitals function as efficiently as they do (under non-pandemic circumstances) with the nuclear submarine-like software that medical and support personnel are forced to utilize to prevent loss of life.

Prod the cashier, the receptionist, and the nurse a bit further and you will learn of the multitude of inefficiencies that these headache-inducing softwares generate on a recurring basis.

Despite having been designed to take the jobs of the folks above and reduce their complexity, many enterprise technologies do the exact opposite, and through omission of design thinking, ironically manufacture more of the same cognitively demanding processes they hoped to engineer away in the first place.

I am of the philosophy that unless a digital tool has been designed to be used by rocket scientists, astrophysicists, or other equally complex and esoteric disciplines, it’s control mechanisms should not force users to pause and think about where to click or what to do in order to achieve an objective.

I find it very useful to think about the concept of reduction from it’s most extreme standpoint. If we were forced to imagine one, what would the ultimate reductionist technology look like?

It would look like the Magic Button.

Given the option, we would gladly take a ‘magic button’ approach to problem solving over any other kind.

The magic button, as its name implies, is the metaphorical super-app of super apps. When one opens this application, there is nothing present on the screen except for a single prompted button. Any problem that needs solving or task that needs handling, simply push the magic button, and voila, it is done. The dog has been walked and the expense reports have been submitted.

If only life was that simple.

Setting aside this abstract thought experiment for a moment, one shouldn’t be surprised to learn that this level of interface minimalism does in fact exist in specified microcosms of today’s digital technology.

The most consistently innovative companies are always striving to get as close to magic button solutions as possible.

The swipe-up-from-bottom-of-screen motion on the iPhone, formerly the analog home button, is in itself a magic button of sorts. The function takes three of the most important activities an iPhone user may need at any given moment — unlocking their device; returning to the Home Screen; and viewing all currently open programs — and beautifully attributes them to 2 variations (left or right flick after initial swipe-up) of a single thumb gesture.

Amazon’s one-click-purchase function is an excellent screen-based example. So long as the user’s shipping and payment information has been correctly configured in advance, all one needs to do in order to make online purchases is search item —> tap.

Wonderfully simple, no? So wonderful, in fact, that Amazon has been swift to bring legal action upon anyone foolhardy enough to emulate the feature.

The fact that one of the largest corporate multinationals in history is willing to spend tens of millions of dollars, hire a battalion of world-class patent and technology attorneys, and risk waiting years for an adjudicated outcome should tell us exactly how much time and effort should be dedicated to making our enterprise technologies truly reductionist.

The most effective way to achieve reductionist status, in my experience, is to start with a magic button and work backwards from there.

When ease of use and intuitive simplicity become a product team’s default guiding principles, there’s no telling how many magic button opportunities will present themselves over the course of time and intelligent experimentation.