Becoming ”enterprise ready” means your software meets the security, compliance, reliability, and support needs of larger customers. These are typically businesses of considerable size (>1000 employees) with complex evaluation and procurement processes.
The decision to move upmarket is typically driven by either a “pull” or a “push” motion. Pull occurs when a user base grows organically, naturally leading to enterprise conversations. Push happens when an organization proactively goes after enterprises and Fortune 1000 companies in pursuit of more sustainable and bigger streams of revenue. Either way, it’s a company-wide transition that can be complex, but early preparation simplifies the process and will help future-proof your product.
Beware the earl push motion. If your company is struggling to find product-market fit and moving upmarket is a last-ditch effort to spur growth, it will be tough to align your team with limited resources. But if there’s even a hint of interest from enterprise customers, it’s crucial to educate your team on the importance of preparing for compliance certifications like SOC 2 and supporting features like SSO, SCIM provisioning, and RBAC as early as possible.
Personas: Know your customer(s)
Engineering leaders will need to reconsider their user needs as they move upmarket, where the software purchasing process includes new groups of stakeholders, such as:
Security and compliance: Security focuses on features like end-to-end encryption, multi-factor authentication, detailed audit logs, and compliance (GDPR, HIPAA, SOC 2).
Procurement and legal: Procurement pays closer attention to how the software is used and licensed, while legal goes over the terms of service, privacy policies, and service level agreements (SLAs) to keep the company protected from any legal or financial risks.
Senior leadership: C-suite executives will look for vendors that provide a long-term product roadmap, proven track record of innovation, and evidence of usage from industry peers.
from workos.com
Enterprise features, unpacked
Compliance
Although compliance isn’t a feature you can develop, it is a major milestone when moving upmarket. Most common compliance certifications include SOC 2 and ISO 27001.
There are two types of SOC 2 certification:
- Type 1 indicates a company’s systems and controls at a specific point in time are designed properly to meet the SOC 2 criteria. In a nutshell, SOC 2 audits the company across 5 criteria: security, availability, confidentiality, privacy, and processing integrity. The security criteria is the only one required to attain a SOC 2 certification, but companies may choose more.
- Type 2 indicates a company’s systems and controls over an extended period, typically 6-12 months, effectively operate as intended.
ISO 27001 is an international standard for managing and protecting data. Getting certified requires identifying threats, evaluating impacts, and establishing robust controls.
SOC 2 is more common in North America for businesses dealing with customer data, whereas ISO 27001 is more prevalent in Europe.
from workos.com
Secure user authentication
Once compliance requirements are met, organizations tend to focus on improving their existing user authentication capabilities. Implementing basic features like email/password login and session management is straightforward, whereas multi-factor authentication (MFA) and Single Sign-On (SSO) are much more sophisticated and provide deeper value to enterprises.
Directory Sync
Directory Sync, or SCIM provisioning, is another important feature that usually accompanies requests for SSO.
It functions as a single source of truth for the identity and characteristics of employees at an organization. Use cases include:
Automatic Deprovisioning:
Deprovisioning ensures that when employees leave, their access to all applications is immediately revoked. However, without SCIM, IT admins must manually deactivate accounts in each application. SCIM automates this process by syncing updates from identity providers (IdPs) like Okta across all connected applications.
Pre-provisioning: Pre-provisioning automates the exchange of employee information between the IdP and connected applications. When a new employee joins, their accounts are automatically activated, removing the need for manual setup by IT admins.
Automated Access Management: SCIM automates most of the process of assigning roles and permissions. It works by syncing information from an organization’s IdP, where employee details like team and group memberships are stored. For instance, if a tech lead is in the “admin” group in the IdP, SCIM can automatically apply the right roles and permissions in your application. At a certain scale, manually assigning roles and permissions becomes unmanageable. Plus, whenever roles change (like after a promotion), SCIM automatically updates them, saving a lot of manual work.
Audit trail and log streaming
An audit trail is a detailed, chronological log that tracks events and operations within an application. It records who performed actions, when and where they occurred, and what changes or access were made. This is crucial for security monitoring, forensic analysis, and regulatory compliance, as it helps identify unauthorized activities and ensures accountability.
Log streaming transfers these logs in real-time from applications to centralized logging systems like Datadog and Splunk. This allows enterprises to immediately collect, process, and store logs, enabling rapid detection and response to security incidents.
Build vs. Buy
The build vs. buy dilemma depends on factors such as engineering bandwidth, committed timelines with customers, product roadmap, complexity of implementation, and more. This topic is also one of the hardest to navigate for engineering leaders, since quantifying the true cost of building in-house can be challenging.
When deciding whether to build or buy a feature, consider these three key factors:
- How closely the feature aligns with your business’s core value proposition?
- The resources needed to build and maintain the solution
- The risk of vendor lock-in
How close is the feature to the core product capabilities?
Deciding whether a feature is part of the product’s core capabilities is a pivotal decision. For example, Render, which provides cloud infrastructure services that are more developer-friendly than traditional cloud providers, built Audit Logs in-house to have deeper control over log format and event types. Similarly, Asana decided to develop most of its enterprise features internally. This decision stemmed from its philosophy that a homegrown solution offers better user experience and enhances its unique value proposition – the intersection of data modeling and workforce management.
How complex is the feature to build and maintain?
What if a feature is integral to the product’s core functionality but is incredibly complex to build and maintain? How should engineering leaders approach the situation then? The answer depends, but here are some key considerations.
1. Plan more time than you think is necessary.
Patrick Malatack, the former GM of Twilio Messaging, told me that supporting enterprise customers is a never-ending, constantly evolving process. “Yes, it is sometimes necessary to build features in-house, but it is critical to realize that processes will be even more complex and time-consuming than you expect,” he said.
2. Finding motivated engineers with expertise in enterprise features is difficult.
Inherently, building enterprise features like SSO and SCIM provisioning requires engineers to work with more traditional tech stacks that may not be at the bleeding edge of technology. Driving these tasks is also under-appreciated, compared to projects related to the company’s flagship products. According to a former engineer at Slack, the atmosphere of maintaining enterprise features is linked to a perpetually high-stakes setting. Their team sometimes functioned like an emergency response unit, always on page to tackle the next critical issue.
3. How many alternative options to a vendor exist?
Potential vendor lock-in is another legitimate concern. When assessing the broader market for a specific feature, the recommendation is to avoid purchasing a solution in a noncompetitive market, which has a higher possibility of vendor lock-in. Thoroughly review the contract and align on the details around auto-renew, check the provider’s reputation with customer references (always try to backchannel), and have a backup of your data if possible.
Conclusion
Becoming enterprise ready is about future-proofing your product and positioning your company for sustained growth in an increasingly competitive market. As companies evolve, those that successfully move upmarket will be the ones capturing the market share and shaping the standards of the industry.
Strategically investing in enterprise features on day one across compliance, authentication, authorization, encryption, and user lifecycle management will help your product scale with the needs of the most demanding customers.
Promoted Partner Content
