Whether you're looking for an angel investor, a growth advisor, or just want to connect — I'm always open to great ideas.
Get in TouchAI, startups & growth insights. No spam.
TL;DR: Bottom-up adoption flips the B2B sales model on its head. Instead of convincing a procurement committee to sign a 12-month contract before anyone uses your product, you get individual contributors using and loving your tool first — then let that internal pressure convert into enterprise deals. Slack grew from 0 to $7.1B in nine years without a traditional top-down sales motion for most of that journey. Figma got adopted by individual designers who then pulled in their whole organization. Linear started with individual engineers and is now inside some of the world's best engineering teams. The playbook works. This is exactly how to execute it.
For most of enterprise software history, the sales motion looked like this: a vendor's sales rep identifies a target company, works their way up to the economic buyer (usually a CTO, VP of Engineering, or CIO), schedules a demo, navigates a six-month procurement cycle, negotiates a contract, and finally — if everything goes right — the product gets deployed to actual users who had no say in the decision.
This model worked. Salesforce built a $200B company on it. Oracle built an empire. But it created a specific kind of software: bloated, hard to use, optimized for demos to executives rather than actual daily use. Products that were designed to win procurement decisions, not to win users.
Then something changed.
The consumerization of enterprise software arrived in the mid-2010s. Developers started using GitHub at home and demanded it at work. Designers started using Sketch personally and convinced their agencies to switch. Then Slack happened. A messaging product that felt nothing like enterprise software spread through organizations virally, one team at a time, until IT had no choice but to recognize it. Within five years, Slack was doing billion-dollar enterprise deals — but most of those conversations started with a single engineer who signed up with a personal email address.
This is bottom-up adoption: the pattern where individual contributors or small teams discover, adopt, and champion a product within their organization, eventually driving enterprise-wide adoption and budget allocation from the top.
Product-led growth is the broader strategic framework. Bottom-up adoption is how that strategy manifests inside real companies — through the human behavior of people who find something that genuinely helps them, and can't help but share it.
In 2026, bottom-up is no longer a scrappy alternative to enterprise sales. It is the dominant entry motion for the fastest-growing B2B software companies. According to OpenView's PLG benchmarks, product-led companies that go public trade at a median revenue multiple of 21x, versus 11x for their sales-led peers. The market has spoken. Bottom-up wins.
But building a product that actually converts through this motion is hard. It requires a fundamentally different approach to product design, pricing, onboarding, and sales. Let's break down exactly how it works.
Before diving into the mechanics, it's worth understanding why this model outperforms traditional enterprise sales on the metrics that ultimately matter.
Customer acquisition cost (CAC) in top-down enterprise sales is brutal. A fully-loaded enterprise AE costs $200,000–$400,000 per year in salary, OTE, benefits, and overhead. They might close 8–15 deals per year on a good year, which means your CAC is often $20,000–$50,000 per enterprise customer before you even count marketing, SE support, and legal costs.
In a bottom-up model, users acquire themselves. Your CAC for individual sign-ups might be $5–$50 through content and organic search. When enough of those users exist inside a company, a sales rep gets involved — but the deal is half-sold before the first call. CAC on bottom-up-sourced enterprise deals can be 60–80% lower than pure top-down equivalents, because you're not paying a sales rep to generate awareness and desire from scratch.
When users choose your product voluntarily, with their own time and money (or their personal work accounts), you get the purest PMF signal available. If they stick around, bring in colleagues, and create shared workspaces, you have genuine product-market fit. If they churn after two weeks, you have a product problem, not a sales problem.
Top-down enterprise deals can mask product quality for years. If a CTO signs a 3-year contract because your sales rep played golf with them, you don't get real feedback until renewal time — and by then you've built a lot of product on a faulty foundation.
Enterprise sales cycles average 6–12 months for deals over $100K ACV. Bottom-up enterprise deals close faster — typically 30–90 days — because the economic buyer is already seeing internal demand they didn't create. Instead of being sold to, they're responding to organic pull. The sales rep's job shifts from generating conviction to removing procurement friction. That's a fundamentally different (and faster) conversation.
Bottom-up products are engineered for expansion. When a product has per-seat pricing and spreads through teams organically, net revenue retention (NRR) can exceed 130–150% in strong bottom-up companies. Every enterprise customer has natural upsell pressure built in — because more people in the organization want to use the tool. Compare this to top-down products where expansion requires a new sales cycle.
Expansion revenue is where bottom-up companies really separate from the pack. The best ones barely have to "sell" expansion — it just happens as usage grows.
Here's the least-discussed advantage of bottom-up: your users become your sales force. A designer at Company A who loves Figma will recommend it when they move to Company B. An engineer who uses Linear at a startup will push for it when they join a scale-up. Every satisfied user is a potential future champion inside a new organization. Top-down companies have to hire sales reps to get into new accounts. Bottom-up companies have thousands of unpaid advocates doing it for free.
Bottom-up adoption doesn't happen all at once. It follows a predictable four-stage curve inside every company that converts from individual usage to enterprise deal.
Everything starts with one person. A developer who signs up after seeing a tweet. A designer who tries the free tier after a conference talk. A PM who starts a trial because they googled a problem and found your blog post.
This person — the pioneer — experiences your product alone. They're evaluating it against their current workflow. They'll give it 2–3 sessions before making a decision. Your job at this stage is ruthless: deliver value in the first session, ideally within the first 10 minutes. If they don't get a "wow" moment before their first session ends, they're gone.
The pioneer doesn't think about procurement or IT policy. They're just trying to solve a problem. Make their problem disappear and they become your biggest internal advocate — entirely by accident.
If the pioneer's workflow genuinely improves, they share the product with immediate colleagues. This isn't altruism — it's self-interest. A Figma user shares a design because they need feedback. A Notion user shares a doc because it's the easiest way to collaborate. A Slack user invites their team because they literally cannot use the product alone.
This is where viral mechanics in product design become critical. The product must create natural sharing moments where individual value increases when more team members join. If your product works fine in isolation without ever touching another person, team spread will be slow and manual. If your product is genuinely better with two people than one, spread is built into the product itself.
This is also when shadow IT begins. The team is using your product without IT's knowledge or approval. This is not a bug — it's a feature of bottom-up growth. We'll cover the shadow IT dynamic in detail in section seven.
If the team spread continues, usage crosses a critical threshold: the manager or department head notices. This can happen organically (the manager sees their team using it) or through active championing (a team member advocates for making it official).
At this stage, two things happen simultaneously. First, your internal champion emerges — usually the most vocal and technically credible advocate on the team. Second, organizational resistance also emerges, typically from IT or finance who want to rationalize software spend and enforce security standards.
This is a tension point in the adoption curve. Many bottom-up tools die here because the champion doesn't have the ammunition to fight the objection. Your product, pricing, and security documentation need to make the champion's job easy.
If the champion successfully navigates internal objections, or if usage grows so widespread that centralizing makes obvious sense, you get the enterprise conversation. An IT admin or VP-level buyer reaches out about procurement, SSO, audit logs, and consolidated billing.
This is where your self-serve enterprise infrastructure matters. If you can make the transition from scattered individual accounts to a centralized enterprise contract low-friction, you'll close. If the buyer encounters a six-week procurement process and unclear security documentation, many deals die here even with strong internal demand.
The conversion from individual to enterprise is your revenue event. But the whole journey from Stage 1 through Stage 4 can take anywhere from three months to two years, depending on your product category, deal size, and organizational complexity.
Bottom-up adoption doesn't happen because your marketing is good. It happens because your product is designed to spread. Here are the specific product decisions that drive organic viral adoption.
The single highest-leverage design decision for bottom-up products: make collaboration the core value proposition, not an add-on feature.
Figma is the clearest example. Sketch was a better design tool than Figma in 2016 on almost every individual feature dimension. But Figma was collaborative. You could share a design link and anyone could view it in a browser, without installing anything. That single product decision made Figma inherently viral in a way Sketch could never be.
Notion's block-based documents are shareable by design. Every page has a public or team URL. Every database can be embedded elsewhere. The product creates so many natural sharing moments that adoption spreads almost automatically.
When you design your product, ask: what are the moments when a user naturally wants to bring in another person? Build those moments into the core workflow, not into an upsell modal.
The most powerful growth mechanic in bottom-up B2B is the invite-to-collaborate moment. This is when a user's workflow creates a genuine need to invite a colleague — not because of a growth hack, but because the product only works well with two people.
Linear does this well. When you create an issue and assign it to someone, that person gets an email. If they're not on Linear, they need to create an account. The invite is embedded in the product's core workflow (issue tracking) rather than feeling like an artificial push for "refer a friend."
Slack's invite mechanics are obvious in retrospect but were novel when launched: if your team creates a channel, you need to invite people to it. The value of Slack goes up with every person you add. There's no way to use Slack in isolation and get full value.
Design these moments deliberately. Map out every point in your core workflow where a user's goal requires or is enhanced by another person's involvement. Those are your viral touchpoints.
Products that create persistent shared artifacts spread faster than tools that are purely session-based. A Notion workspace persists. A Figma project file persists. A Linear project with issues assigned to multiple people persists.
These artifacts become organizational infrastructure over time. Once a team's knowledge base is in Notion, switching becomes costly. Once a design team's component library is in Figma, switching is nearly impossible. The persistent artifact creates both stickiness and spread — new team members get added to the workspace, which introduces them to the product.
Compare this to a tool where each user's work is siloed. Even if the product is excellent, there are no natural moments to share and no persistent reason for others to join.
Free tiers in bottom-up B2B are not charity. They are customer acquisition infrastructure.
The optimal free tier structure for bottom-up products has three properties:
Genuinely valuable for small teams — The free tier must be good enough that individuals and small teams can build real workflows on it. If the free tier is so crippled that no one bothers, you lose the viral adoption engine.
Naturally limited for growing teams — The limits should be things that naturally bind as teams grow: number of users, number of projects, storage, admin controls, SSO. Not artificial limits designed to annoy users.
Upgrade triggers aligned with team growth — Hitting the limit on your free tier should feel like a graduation milestone, not a wall. "You've grown beyond what free can support — here's how to scale" is a different conversation than "pay us or lose your work."
Notion's free tier allowed infinite pages but limited block storage. When power users hit the limit, upgrading was obvious. Linear's free tier supports small teams with most features, but adds-up billing per seat as teams grow. The trigger is team size, not feature access.
The pioneer who signs up alone has no patience. They have a real job. They're trying your product in 20 spare minutes before a meeting. Your onboarding must deliver a meaningful value moment inside that window.
This means:
Linear does this brilliantly: you can create your first project and see it organized with example issues in under two minutes. You understand what the product does before you've had to commit to anything.
One of the most practical questions for bottom-up founders: at what point do you initiate a sales conversation with a company that has multiple individual users?
This varies by product category and deal size, but the frameworks are consistent.
Track user density by company domain. When you see three or more users from the same email domain (e.g., multiple @acmecorp.com addresses), flag that account for outreach. This is your signal that organic adoption has started and there's a potential enterprise conversation to have.
The specific number depends on your product:
User count alone is a blunt instrument. What you really want is engagement depth: are the users actually using the product, or did they sign up and forget?
Define your engagement signals specifically:
Users who meet two or more engagement signals are activated users. When you see three or more activated users from the same company domain, that's your trigger for a sales conversation.
Salespeople who reach out based on sign-up data alone will get ignored. Salespeople who reach out with "I noticed your team has been using X to do Y" get replies, because they're demonstrating that they understand the customer's actual behavior.
The product qualified lead is the bottom-up equivalent of a marketing qualified lead. A PQL is a user or account that has demonstrated through product behavior that they are likely ready for an upgrade conversation.
PQL definitions typically combine:
Your product-led sales motion activates when an account hits PQL status. This is when a sales rep reaches out — not to generate interest (that already exists), but to remove friction and accelerate a decision that the account is already moving toward.
A practical rule of thumb from SaaS operators I've talked to: when an account has three or more activated users and at least one has visited the pricing page, conversion probability exceeds 40%. Reach out within 24 hours of this signal. The window is narrow — motivated buyers who don't hear from you will either figure out payment themselves (good) or stall and lose momentum (bad).
The internal champion is the person inside your customer's organization who advocates for your product, fights procurement battles on your behalf, and holds the deal together when IT pushes back or a competing vendor shows up.
You cannot build a successful bottom-up motion without champions. Here's how to find, develop, and equip them.
Champions share three traits:
Individual contributors make the best champions in early-stage adoption. A senior engineer, a lead designer, a power-user PM. They're close enough to the problem to speak credibly about the solution, and they're often frustrated enough with existing tools to advocate energetically for something better.
You can't force someone to become a champion, but you can design experiences that make it easy and rewarding.
Success stories and case studies they can share: If you publish a case study about how a team like theirs used your product to achieve X outcome, champions can share it internally as proof. "I'm not crazy — other companies are doing this too."
ROI calculators and productivity data: Give champions specific numbers. "Our team has resolved 47 issues in Linear this month with an average cycle time of 2.3 days, down from 6.1 days in Jira." Numbers that translate into business value make internal advocacy conversations much easier.
Direct communication from your side: Don't just talk to the champion about product features. Talk to them about their organization. "What does IT care about? What does the budget process look like? Who else do I need to make happy?" The best sales reps treat champions as co-sellers, not just warm leads.
Executive alignment email drafts: This is underused. Offer your champion a draft email they can edit and send to their manager or VP, making the case for enterprise adoption. Most champions know what they want to say but don't know how to say it in language that resonates with executives. Write it for them.
Champions leave companies. This is a structural risk in bottom-up adoption — if your main advocate walks out the door, the deal can evaporate.
Mitigation strategies:
Shadow IT is the reality of bottom-up adoption. Individual contributors adopt tools without IT's knowledge or approval. In 2026, the average enterprise employee uses between 8 and 15 applications that IT doesn't know about. This is not recklessness — it's pragmatism. Users adopt tools that help them do their jobs, regardless of policy.
As a bottom-up vendor, you will almost always start as shadow IT. The question is how to navigate from unauthorized to sanctioned.
IT's objections are predictable:
Address every one of these preemptively in your documentation. A security trust center — a public page documenting your certifications, data handling policies, pen test results, and compliance posture — lets champions send a URL instead of asking you to respond to a questionnaire.
The biggest unlocker for enterprise adoption is SOC 2 Type II. If you're targeting organizations with more than 200 employees and don't have SOC 2 Type II, you're leaving significant enterprise revenue on the table. Get it done by the time you're doing real outbound to accounts with 3+ users.
"We already have a tool that does this" is the most common enterprise objection for bottom-up products. Your existing users know how to answer this — they chose your product over the incumbent. But you need to help them articulate why.
The honest answer is usually: "Yes, you have Jira. But our engineers actually use Linear." Tool quality and user adoption are different things. Help your champion communicate this distinction: the incumbent is the official tool, but the effective tool is yours. That gap is exactly the organizational problem you're solving.
The moment IT wants to sanction your product is a critical window. Make the transition from shadow IT to official deployment as frictionless as possible.
This means having ready-to-deploy:
Every hour of IT friction during the transition is a risk to the deal. Build the enterprise infrastructure before you need it.
Let's make this concrete with specific examples from the four companies that have executed bottom-up adoption most effectively in the last decade.
Slack launched in August 2013 and became the fastest-growing business application in history, reaching 8 million daily active users in 2018 and completing a $27.7B acquisition by Salesforce in 2021. Almost none of that growth was driven by top-down enterprise sales in the early years.
The mechanics of Slack's bottom-up growth:
The product was inherently team-based. You cannot use Slack alone. The moment you sign up, the product pushes you to invite colleagues. Every message you send, every channel you create, every file you share requires other people to have accounts. The product was viral by necessity.
Free tier with generous limits. Slack's free tier allowed unlimited users, unlimited integrations, but retained only 10,000 messages. This was a brilliant limit: small teams could use Slack indefinitely for free and build deep workflows on it. Only when teams grew larger or needed to access older messages did the upgrade conversation make sense.
IT couldn't block it. By the time enterprise IT departments realized employees were using Slack, dozens or hundreds of users were already dependent on it. The cost of removal exceeded the cost of sanctioning it. Slack turned shadow IT into a feature by making the product indispensable before IT had a chance to evaluate alternatives.
The land-and-expand model at scale. Slack's NRR consistently exceeded 140% in its growth years. Enterprise customers who started with one team expanded to multiple teams, then to the whole organization. Billing per active user meant Slack's revenue grew automatically as customers grew.
Notion's growth story is about content virality as much as product virality. Notion's block-based documents are shareable by URL, making Notion the source of millions of templates, wikis, and public-facing databases that non-users encounter every day.
A user builds a beautiful team wiki in Notion, shares the URL publicly, and thousands of visitors see it. Many of them sign up for Notion. Some of them build their own team wikis and share those. This template ecosystem became one of Notion's primary growth channels — a genuine viral loop where every user's public output was also an advertisement for the product.
The lesson for bottom-up founders: your product's outputs can be viral even if the product itself requires an account. If you can make the artifact (the document, the design, the dashboard) shareable without requiring the viewer to log in, you've created a massive distribution surface.
Notion's enterprise adoption follows the classic bottom-up curve: individual knowledge worker signs up → shares templates with their team → team builds on Notion → IT gets involved → enterprise deal closes. The company raised at a $10B valuation in 2021 with minimal traditional enterprise sales until relatively late in its growth.
Figma is the purest example of using collaboration as the core product mechanic rather than a feature. Sketch was the dominant design tool when Figma launched in 2016. Sketch was a better design tool by most individual feature measures. Figma won anyway, and did so decisively.
Why? Because Figma made design a shared artifact rather than a personal file. In Sketch, design files lived on individual designers' hard drives. Sharing required exporting to PDF or image files, which created version control nightmares. In Figma, the design file lived in the browser, accessible to anyone with a link. Developers could inspect actual CSS values without a separate Zeplin subscription. Product managers could comment on designs without installing anything. Stakeholders could view designs on mobile without special software.
Every person who received a Figma link was a potential new user. Developers who browsed Figma designs started using Figma to build prototypes. PMs who commented on Figma designs started using Figma for wireframes. The tool spread beyond its initial design team footprint.
Figma's acquisition by Adobe for $20B (later blocked by regulators) was valued on enterprise contract value built almost entirely through bottom-up adoption. Design teams adopted Figma without enterprise contracts. Enterprise contracts followed.
Linear is the newest of these case studies and the most instructive for founders building today. Linear launched in 2019 targeting the most skeptical possible audience: software engineers who hate project management tools.
Linear's bet was that Jira is so universally despised that a better product would sell itself. They were right. Engineers adopted Linear through personal sign-ups, built workflows on it, and then forced the organizational conversation: "We're using Linear. Can we make it official?"
What makes Linear interesting from a bottom-up perspective:
Speed as the core product value. Linear made a hard engineering commitment to feel instantaneous. Every interaction in Linear is optimized for sub-100ms response times. In a world of sluggish enterprise software, speed is a genuine differentiator that users feel immediately. This created a category of user who genuinely evangelized Linear based on the experience of using it, not based on its features.
Design quality as a trust signal. Linear's aesthetic is deliberately minimal and considered. This communicates to users — especially engineers — that the people who built this tool care about craft. Product quality creates a different kind of champion: one who stakes their professional identity on the recommendation.
Early focus on individual contributors, not managers. Linear explicitly did not build reporting dashboards and manager-facing analytics in early versions. They built for the person actually doing the work. This won engineers, which won engineering teams, which eventually won engineering organizations.
Linear's pricing is still primarily seat-based, but they have enterprise contracts in some of the world's best engineering organizations — companies that adopted Linear because individual engineers loved it, not because a vendor pitched a CTO.
Pricing in bottom-up models is structurally different from top-down enterprise pricing. You need to optimize simultaneously for individual adoption (low/no friction) and enterprise extraction (capturing value as organizations scale).
Most successful bottom-up products use a three-tier structure:
Free/Starter: Genuinely useful for individuals and small teams. No credit card required. Limits are real but not punitive. This is your adoption engine — every user on this tier is a potential enterprise champion-in-training.
Pro/Team: Per-seat pricing, usually $10–$25 per user per month. Unlocks collaboration-specific features, higher limits, basic admin controls. This captures the long tail of small-to-medium teams who don't need enterprise features but have grown beyond the free tier.
Enterprise: Custom pricing, usually starting at $20–$50+ per user per month with volume discounts. Adds SSO, SCIM, audit logs, SLA guarantees, dedicated support, and compliance documentation. This is where your largest revenue concentrates.
The pricing between Free and Enterprise should have enough friction that large organizations naturally gravitate toward Enterprise, but enough value at each tier that switching feels like a genuine upgrade rather than a forced hand.
Per-seat pricing is the dominant model for collaboration tools because it scales naturally with team size. As more people join the workspace, the bill goes up proportionally. This creates natural expansion revenue without requiring any additional sales effort.
Usage-based pricing is emerging as an alternative, particularly for AI-augmented tools. It has the advantage of aligning price with value delivered, but creates unpredictable billing that enterprise buyers hate. If you're building a usage-based model into a bottom-up product, make sure there's a cap or committed spend option for enterprise customers.
A common mistake: being too generous with the free tier to the point where enterprise conversion doesn't happen. The right freemium balance:
Notion tried feature-gating and found that the free tier's block limits were creating negative experiences for heavy users. They adjusted multiple times. The point is: your freemium model is a hypothesis that needs to be tested against conversion and retention data.
Enterprise pricing should be anchored on features that:
These are features that individual users don't need but enterprise buyers always ask about. They justify the enterprise price premium and make the tier feel like a legitimate product upgrade rather than just a bigger bill.
Bottom-up companies need a different metrics stack than traditional enterprise SaaS. Here are the indicators that actually predict success.
Sign-up velocity by source: Which channels are producing your best individual users? Break this down by domain type (individual, SMB, enterprise, government) to understand whether you're building an enterprise pipeline or just a consumer business.
Activation rate: What percentage of users who sign up complete your onboarding and perform the core action? Below 20% activation means your onboarding is broken. Top bottom-up products see 40–60% activation rates within the first week.
Time to first value: How long does it take from sign-up to first meaningful product interaction? Target under 10 minutes for most B2B tools. Track this obsessively.
Weekly active rate (WAR): What percentage of registered users use the product at least once per week? Strong bottom-up products see 40–60%+ WAR for their most engaged user segments.
Collaborative depth: What percentage of users have created at least one shared artifact (invited a colleague, created a shared workspace, assigned work to another user)? This is your virality indicator — users with collaborative depth have 3–5x better retention than solo users.
Feature engagement breadth: Are users using three or more core features, or are they stuck on one workflow? Users who explore the product more broadly have higher retention and higher upgrade conversion.
Organizational spread rate: How many users does the average company have after 90 days? 30 days? Track this for different company size cohorts. Healthy spread rates indicate your team-spread mechanics are working.
Domain-based cohort analysis: Group users by company domain and track their collective behavior over time. What does the lifecycle of a company with 5+ users look like? When do they typically upgrade? This tells you where to intervene in the buyer journey.
PQL-to-opportunity conversion rate: What percentage of product qualified leads become sales opportunities? This tells you whether your PQL definition is calibrated correctly and whether your sales motion is effective.
NRR (Net Revenue Retention): The ultimate bottom-up health metric. Best-in-class bottom-up companies see 120–150%+ NRR. This means your existing customers expand faster than they churn. If NRR is below 100%, you have a retention problem that no growth investment can fix.
ACV distribution: How is average contract value distributed across your customer base? A healthy bottom-up company has a long tail of small accounts and a concentrated head of enterprise accounts. If you have no enterprise accounts, you're leaving 80% of available revenue on the table. If you have no small accounts, you've lost your growth engine.
CAC payback period: How many months of revenue does it take to recover the cost of acquiring a customer? Top-performing bottom-up companies have payback periods of 12–18 months for self-serve customers and 18–24 months for enterprise customers. Worse than 24 months signals either pricing or CAC problems.
Is bottom-up adoption only for developer or designer tools?
No, but it's easiest to execute in categories where individual contributors have high software autonomy. Developer tools, design tools, and productivity/knowledge management products have the fastest bottom-up adoption curves. Bottom-up also works well in data analytics, HR tech, and customer support tooling — anywhere individual contributors make daily software choices. It's hardest in categories where procurement is always centralized (ERP, financial systems, security) or where the product has no value without organization-wide adoption from day one.
How do you handle pricing when individual users are paying out of pocket?
Some bottom-up products see significant individual user subscription spend before an enterprise deal. This is actually valuable data — users who pay personally are your highest-intent champions. Some companies (notably Figma, historically) allowed individual billing to persist alongside enterprise contracts, treating them as different use cases. Others require a clean migration to enterprise billing. The right answer depends on your unit economics and enterprise buyer requirements. Either way, have a clear policy and make migration easy.
What's the difference between bottom-up adoption and product-led growth?
Product-led growth is the strategic framework: the product itself drives acquisition, conversion, and expansion. Bottom-up adoption is one specific motion within PLG — the pattern where individual user adoption propagates upward to enterprise contracts. PLG also includes pricing strategies, onboarding optimization, and usage-based models. Bottom-up is specifically about the organizational spread dynamic from individual to enterprise.
When should you hire salespeople for a bottom-up business?
Hire your first sales rep when you have evidence that your product is being used by multiple users at the same company without any sales involvement. That signals there are enterprise conversations waiting to happen that you're not initiating. The first sales hire in a bottom-up company should be focused on inbound follow-up with PQLs, not on outbound cold calling. Outbound makes sense later, when you have enough data to identify the company profiles most likely to convert.
How long does the individual-to-enterprise conversion typically take?
Based on data from multiple bottom-up SaaS companies: the median time from first individual sign-up in an organization to an enterprise contract is 9–12 months. The 25th percentile (fastest deals) is around 4–5 months. The 75th percentile is 18–24 months. Deal velocity increases significantly when: (a) you have an active PQL-based sales motion, (b) your champion is in a VP or director role, and (c) you have strong IT-facing documentation ready to go.
What if IT blocks the product before you can close the enterprise deal?
It happens. The best mitigation is making your existing users so dependent on the product that the cost of removal exceeds the cost of compliance. Have your security documentation, SOC 2 certification, and SSO integration ready before you hit significant scale in any one organization. When IT objects, the goal is to make sanctioning the easiest path, not to fight IT directly. Give your champion the tools to win the internal argument — they know the political landscape better than you do.
Can you do bottom-up in a highly regulated industry (healthcare, finance)?
Yes, but it's harder. Shadow IT in healthcare is a genuine compliance risk that IT teams take seriously. The path is: build your compliance posture before you approach regulated industries, not after. SOC 2 Type II, HIPAA BAA readiness, and FedRAMP (for government) are prerequisites, not afterthoughts. In regulated industries, your free tier may need to be compliance-lite by design, with a clear and fast path to compliant enterprise tiers for serious buyers.
What's the biggest mistake founders make with bottom-up adoption?
Treating it as a marketing strategy rather than a product strategy. Bottom-up adoption is not "build a free tier and hope people share it." It is a total product philosophy that requires collaborative-by-default design, ruthless onboarding optimization, viral mechanics built into core workflows, pricing structured for expansion, and enterprise infrastructure ready before you need it. Founders who execute all of these well build companies like Slack, Notion, Figma, and Linear. Founders who slap a free tier on a top-down product and call it PLG are disappointed by the results.
The bottom-up revolution has fundamentally changed what B2B software can look like. Products no longer need to win procurement committees before they can win users. They can win users first, and let that organic adoption create the enterprise pressure that closes deals.
But the mechanics are specific and the execution is hard. You need collaborative product design that creates natural sharing moments. You need onboarding that delivers genuine value in the first session. You need a free tier that's generous enough to drive adoption but structured to trigger upgrade conversations. You need enterprise infrastructure that makes the transition from shadow IT to sanctioned IT frictionless. And you need a sales motion that activates at exactly the right moment in the adoption curve — when the account is ready, not when your quota says to call.
Get all of those pieces right, and you build a company where individual contributors become your most powerful sales force — people who love your product so much they create organizational demand without you asking them to.
That's the real bottom-up advantage. Not that you skip sales. But that by the time sales shows up, the work is already done.
The complete guide to signal-based selling for B2B startups — how to use intent data, product signals, and buying triggers to close deals 3-5x faster than cold outbound.
Enterprise buyers want to try before they talk to sales. Here's how Notion, Figma, and Vercel built self-serve pipelines to six-figure contracts — and how your startup can too.
How reverse trials — giving users full product access before downgrading — convert 2-3x better than freemium. The complete playbook with case studies from Ahrefs, Loom, and Calendly.