Things to Consider - Moving your product upmarket to the enterprise
It's a lot of additional work to sell the same product to a different kind of customer.
I’ve developed several products that were initially sold to directly to individual users that I then transitioned up-market.
We went from offering a straightforward product wedge directly to users to working directly with larger entities that controlled the activities of thousands and tens of thousands of users.
It required a lot of work. Our sales team made promises - metaphorically writing checks we didn’t have money in the bank for. We lost several customers after they came on board and were disappointed with the state of the offering.
What went wrong? Turns out, we under-estimated the amount of effort it would take.
The enterprise value proposition
To actually move up-market, your product needs to have some value proposition that applies to the enterprise - the larger organization that sits above your actual individual users.
What are you giving the organization purchasing your product?
Greater control? Do they get more administrative tooling, policy enforcement levers, or access controls?
Greater visibility? Do they get reports across multiple users, actionable insights, or usage?
Greater interoperability? Do they get the capability to integrate with other systems they use, such as login providers, SIEMs, CRMs, or ERPs?
Greater scale? Do they get access to capabilities useful at scale, such as automations, faster resources, or SLAs?
Is it surprising these don’t sound like anything related to your core product? Remember that this value proposition can be quite distinct from your actual product offering, or may not even be related at all.
A lot of product managers get this wrong and imagine moving upmarket as giving more advanced, broader, or deeper features of the wedge, when in reality the purchasing decision may be made because of the color of the doorknob.
I once worked with a potential customer who loved every single capability of our product, except for the fact we used Amazon Web Services to host our offering. They were a retail organization and as a result had internally banned usage of Amazon, whom they viewed as their largest competitor. To sell them on our offering, we had to explore transitioning their instance to Microsoft Azure - a completely irrelevant and useless detail in the grand scheme of what we offered, and a lot of work to boot.
Your product will change
When you “go enterprise”, you’ll likely end up incorporating some elements of the below into your product. Enterprise product functionality that companies eventually expect include:
Account management
Account provisioning
Analytics
Auditing
Authorization
Billing
Branding and white-labeling
Configurations
Cost projection
Custom domain names
Data interchange options / integrations
Data residency, lineage, and ownership rules
Email control
Exports
Infrastructure
Ingestion
Invoicing
License management
Reporting and insights
Security controls
SOC2 or other compliance (eg. WCAG, PCI)
SSO
Team member management
Webhooks
These represent the iceberg that is enterprise products. It’s not just offering a tool or wedge to “process a payment” or “streamline a process”. It’s offering that on top of a cohesive platform. In effect, your product offering becomes your meta-product.
Your org will change, too
There’s also enterprise capabilities that your organization will need to be able to support and operate via various programs:
Completing RFCs, RFPs, and RFIs
Supporting unique billing such as invoicing
Multi-tenancy and data segmentation
Monitoring and reporting, service SLAs
Disaster recovery, including failovers, backups, RPOs and RTOs
White-glove service, account management, escalation paths, response SLAs
Support plans and roadmap influence
Legal ownership of intellectual property ad data ownership
Compliance with laws and regulations, both real and perceived
Change management, including notification
These need to be defined, operationalized, documented, and facilitated for customers and prospects. It also increases internal coordination needs as well - for example, you wouldn’t want a Salesperson committing to an Uptime SLA that the Engineering organization couldn’t meet.
The secret - you may not need all of these
The dirty secret is that some of these may be absolute requirements to sign the contracts, but ultimately doesn’t matter to the customer after contract signing. They just needed to check a box or meet some internal political need.
What you need to commit to and what you actually need to implement can sometimes be determined by people who weren’t part of the contracting and purchasing process at all - the operations and implementation team on the customer’s side.
While the purchasing team may happily be operating under the assumption they received everything, sometimes only a few capabilities end up getting used operationally.
It’s important to identify and prioritize the capabilities that are actually used, and find wiggle room in the ones that aren’t actually important. Be up-front and really dig in to why something is being asked for.
Sometimes you have negotiating leverage to strike away an item. Other times you can get a feel during negotiations that an item isn’t actually all that important post-signing.
Don’t lie to the customers - that’s a fast way to lose all reputation and irreparably harm your organization plus open yourself up to lawsuits. However, you may be able to find an alternate, simpler solution that mutually fulfills the customer’s internal requirements even if it doesn’t meet the letter of the contract while allowing you to spend your investment allocation chips elsewhere. Working directly with your customers on finding these alternate approaches can be in everyone’s best interest.
I once spent several months developing an enterprise-customizable role-base access management system to enable an enterprise prospect. When they finally started using the product, the overwhelmed operations admin couldn’t make the time to learn how to configure it, and asked our internal account management team for help. We set it up internally, and they were quite happy, and never changed the tool again. What was initially a critical contract piece ended up never being used by the customer once they started using the product.
Operationalization
Of course, not everything can be deprioritized. At some point, you’re going to have to actually deliver on the capabilities you agreed to. That’s where you have to recognize that it’s not just about the Product.
Enterprise capabilities are just that - enterprise capabilities. They cross functional boundaries and impact almost every part of the organization.
You have to work with many, many different functions to deliver successfully on the contract. This means playbooks and runbooks for various processes that multiple parts of the organization participate in. Documentation is
key here, as is training and pro-active facilitation of any new process: you can’t just release a new process and expect it to be followed.
Even something taken for granted such as “onboard a new customer” may have a surprising amount of nuance and complexity that involves:
Reviewing the contract terms
Provisioning the account according to those terms
Configuring the account according to the customer’s specific needs
Training the customer on how to use the product
Answering questions from the users
Coordinating with marketing for announcements, if any
Monitoring usage to encourage adoption
Scheduling and developing any committed customizations
Starting billing and invoicing
Preparing tier-1 support teams for new questions
Things can start to fall through the cracks as communication and steps occur between roles like account management, sales, solutions, legal, marketing, finance, support, security, and product. Without effective tracking, checklists, and process, you’d end up with an inconsistent, non-repeatable customer experiences with a lot of key steps being missed.
Multiply that by the number of other things you have to do to support enterprises, and you start seeing why the product itself is just the tip of the iceberg.
Larger companies have dedicated people for each of these steps, but in smaller companies it may be a single person performing all of these steps on top of their day job. At prior small companies, I’ve had to do all of the above on top of actually developing the product!
To move to supporting enterprises successfully, you need strong relationships with all of your peer functions and disciplined facilitation and execution. No customer will remain with you if you string them along or break promises. Think deeply about not just the product, but how the very act of selling to a new kind of customer changes how you operate at the company.