Building Products for the Enterprise

Building Products for the Enterprise

Building Products for the Enterprise

Products for the Enterprise

You have a great idea that solves a real pain point for enterprises. Woohoo! You actually built a minimal viable product that people are interested in. Aye Caramba! You got a major enterprise to test your product in a paid proof of concept. Check and mate, right? You’re the next billion-dollar IPO, no?

Not quite. Remember the logic principle that something is true if and only if necessary and sufficient conditions exist? Let’s apply this to the startup world. Solving a problem that no one else solved before is a sufficient condition. It is the heart of your product and what enables you to inspire employees to bet on you with their careers, lure investors to bet on you with their money, and land early adopters to bet on you with their time. For Voxer, it was instant communication that delivers the richness of voice and the etiquette of text. For Evernote it was seamless notetaking in the cloud. For Lookout it was securing mobile devices.

From my experience, most startups forget or choose to ignore the necessary conditions, likely because those are dull and hard to implement. But when building products for the enterprise, there are a few things you have to do in order to even be considered as a viable product for large corporations. Box figured this out early on and focused on building all the controls, security, and integration with existing systems that large companies require, and as a result Box is now far ahead of Dropbox in the race for the enterprise cloud-based file sharing market.

To make sure I’m not overlooking necessary conditions when building products for the enterprise, I like to use this categorization framework:

If a feature is necessary, it’s because of a compliance requirement, which could be either internally or externally driven. Of the two, external regulatory compliance features are much easier to identify, though not always easy to implement. For example, a hospital will not be able to buy your new high-resolution ablation catheter before it receives FDA 510(k) approval. A factory won’t be able to buy your new algae-based biofuel if its byproducts violate EPA regulations. A bank won’t approve a purchase of a new mobile payments system if it violates Sarbanes-Oxley guidelines.

Things get trickier with internal governance compliance, since necessary conditions might be very idiosyncratic and seemingly random. In this case, you have to know the market, choose which unique requirements you want to develop based on what the majority of the industry does, and punt on the others. For example, home security provider ADT might lock down company-issued tablets and only allow apps that were distributed through an MDM system like MobileIron, while ADT’s chief competitor Tyco crowdsources apps selection to employees, tracks which apps they use, and then purchases software in bulk. For MobileIron, ADT is not a viable customer.

The good news is that there are some best practices enterprises follow, regardless of size, industry, geography, or subjective preferences. Figuring out what those are and adhering to the guidelines will help with your product adoption. And yes, those also come in two flavors. The first one is “CYA features” like security, encryption of data, or auditability. The second flavor is productivity-neutral or productivity-enhancing features. A good example for productivity-neutral feature is integrating your software with the enterprise’s LDAP system, to enable employees to use their corporate credentials when logging in, and the system admins to grant or revoke access to your app from the same console they already use for other tools.

So, go back to your successful MVP that we started with, and think about your current product and future roadmap. If you don’t have features in each and every one of the categories above, I bet you are missing something critical that will come back to bite you at some point.

Itamar Kandel


Wireframe your “IDEA”

Wireframe your “IDEA”

Introduction It all begins with an idea in mind, often asked question how do we write specifications and why do we