Enterprise Bottom-Up Sales: How Slack, Notion, and Figma Win Big Customers Without Big Sales Teams

Companies Using This Strategy

Why bottom-up works

Bottom-up sales exploits structural changes in enterprise software procurement: (1) **Department-level budgets**: department managers increasingly have $5K-$50K budgets approvable without enterprise procurement involvement. Small initial deployments fit within these budgets. (2) **SaaS delivery removes friction**: cloud delivery eliminates IT infrastructure requirements. Teams can adopt without IT involvement. (3) **Individual user evaluation**: modern enterprise software is evaluated by end users before purchase. Users who have used the product have ground-truth data on whether it works. (4) **Internal advocacy emerges**: users become internal advocates who push for broader adoption. The advocacy is more credible than vendor sales pitches. (5) **Procurement formalizes existing usage**: when usage reaches enterprise scale, procurement formalizes contracts but doesn't redecide whether to use the tool. The pattern requires product quality. Bottom-up requires the product to be genuinely valuable for individual users without enterprise features. Many B2B products that look successful in demos don't pass individual-user validation.

The stages of bottom-up adoption

Bottom-up adoption typically follows stages: (1) **Individual adoption**: single users discover product through search, social, recommendation. They use it for personal or single-task work. (2) **Team adoption**: individual users share product with team. Team adopts for collaboration. Initial deployment is small (5-20 users). (3) **Department adoption**: multiple teams within department use product. Department manager negotiates volume pricing. Deployment grows (50-500 users). (4) **Enterprise standardization**: procurement evaluates and standardizes. Enterprise license agreement (ELA) replaces team contracts. Deployment reaches organizational scale (5,000+ users). (5) **Enterprise integration**: SSO, SCIM provisioning, audit logging, compliance certifications activated. IT involvement increases. Each stage has different sales requirements. Individual adoption requires no sales — product must be self-service. Team adoption requires modest customer success. Department adoption requires account management. Enterprise standardization requires enterprise sales motion. Enterprise integration requires technical account management. Companies that build all the sales motions appropriately can capture the full adoption funnel. Companies that miss specific stages lose customers at the transitions.

Product requirements for bottom-up

Bottom-up sales requires specific product characteristics: (1) **Solo-user value**: product works for individual users without team features. This is the entry point. (2) **Self-service onboarding**: users can sign up, get value, and use product without sales involvement. (3) **Viral team features**: collaboration, sharing, team invites that make team adoption natural. (4) **Generous free tier or trial**: low friction for individuals to start. (5) **Pricing that scales smoothly**: per-seat or usage-based pricing that grows with adoption without contract renegotiation. (6) **Enterprise features available when needed**: SSO, audit logging, admin controls available for enterprise stage. Not required at individual stage. The product requirements are different from traditional enterprise software, which often emphasizes admin features and configurability over individual-user experience. Bottom-up products optimize for individual user experience first.

Sales motion for bottom-up enterprise

Sales motion supporting bottom-up has structural characteristics: (1) **Self-service first**: most adoption happens without sales involvement. Sales engages only when account exceeds threshold (typically $5K-$10K in usage). (2) **Account development team**: identifies accounts with growing usage and engages proactively. Different from outbound SDR work. (3) **Customer success vs. sales**: in bottom-up, customer success often drives expansion. Sales handles procurement formalization but not initial selling. (4) **Solutions engineering for enterprise stage**: when accounts move to enterprise, technical evaluation requires solutions engineering support. (5) **Procurement specialists**: enterprise contracts require contract negotiation, security review, legal coordination. Specialists handle these. The sales structure differs from traditional enterprise sales (which front-loads outbound prospecting and complex multi-stakeholder selling). Bottom-up requires less prospecting investment but more in account development, customer success, and procurement support.

When bottom-up doesn't work

Bottom-up has limits. Some products don't fit: (1) **Pure executive-decision products**: ERP, financial systems, compliance tools where executive decision-making dominates evaluation. (2) **Long sales cycles by regulatory requirement**: financial services, healthcare products where regulatory approval requires top-down evaluation. (3) **High-customization products**: products requiring substantial customization may not work for individual users without setup. (4) **Products without individual-user value**: products useful only at organizational scale (e.g., enterprise analytics requiring data integration). (5) **Products where individual users can't legitimately use without authorization**: products handling regulated data may require enterprise authorization before any use. For companies evaluating whether bottom-up applies to their product, analytical questions: (a) can individual users get value? (b) can adoption grow organically? (c) does pricing structure support the adoption progression? Products that fail bottom-up validation may still succeed with traditional enterprise sales — the strategies are alternative, not universal.

How to Implement

1. 01Design product for solo-user value as entry point.
2. 02Build self-service onboarding with no sales-touch requirement.
3. 03Add viral team features (sharing, collaboration, invites) for team-stage growth.
4. 04Pricing structure that scales across individual/team/enterprise without renegotiation friction.
5. 05Build account development team to identify and engage growing accounts.
6. 06Add enterprise features (SSO, SCIM, audit logging) available when accounts mature.
7. 07Develop procurement specialists for enterprise stage contract negotiation.

Common Pitfalls

• 01Designing for enterprise procurement first (admin features over user experience).
• 02Pricing structures that require contract renegotiation at adoption transitions.
• 03Outbound sales investment in product not suited for bottom-up.
• 04Premature enterprise features investment before product-market fit at individual level.
• 05Inadequate account development for expansion-stage opportunities.

Sources

• Slack S-1 filing
• Figma developer blog