Uncover the growth strategies of products that were designed to infiltrate organizations from the bottom up. This book analyzes how tools like Slack, Figma, and Notion bypassed traditional enterprise sales by creating an indispensable utility for individual employees. Discover the principles of product-led growth that turn users into internal champions and sell the software for you.
For centuries, the city of Troy stood as an impregnable fortress. Its walls were high, its gates were guarded, and its leaders were the sole arbiters of who—and what—was allowed inside. For decades, the world of enterprise software resembled those ancient walls. To sell a product to a large corporation was to lay siege to a fortress. The process involved a small army of salespeople, months of strategic planning, and a relentless campaign aimed directly at the kings of the castle: the CIO, the CTO, and the CEO. The goal was to convince these powerful gatekeepers to sign a massive, top-down contract that would impose the new software upon their entire kingdom of employees. It was a slow, expensive, and brutal form of warfare. Victory, when achieved, was absolute. A single signature could mean millions in revenue and thousands of users overnight. But the landscape of this war was built on a fundamental assumption: that the leaders at the top knew what was best for the workers at the bottom. The software they chose was often clunky, complex, and despised by the very people forced to use it. It was designed to solve organizational problems, to check boxes on a security audit, or to integrate with legacy systems—often at the expense of the user’s sanity and productivity. The employees, the foot soldiers in this corporate kingdom, had no say. They used what they were given. Then, quietly, a new strategy began to emerge. It was subtle, almost invisible at first. It didn’t involve a frontal assault on the C-suite. It didn’t require lavish dinners with executives or armies of salespeople. Instead, it targeted the unguarded side entrances, the forgotten pathways into the city. This new strategy was embodied in a new kind of product, one that looked less like a battering ram and more like a gift. This was the Trojan Horse. Companies like Dropbox, Slack, and Evernote didn’t ask for a meeting with the CIO. They didn’t need one. Their target was a single, frustrated employee. Someone who just needed to share a file that was too large for email. A small team of developers tired of being buried in endless reply-all chains. A project manager desperate to organize their notes without using a spreadsheet. These products offered a simple, elegant solution to a personal, painful problem. And crucially, they offered it for free. Like the fabled wooden horse left at the gates of Troy, these tools appeared harmless, even helpful. An employee would discover Dropbox and start using it to store their own files. They’d find it so useful that they’d share a folder with a colleague to collaborate on a project. That colleague would sign up, and then share it with another. The same pattern repeated with Slack. A small team, fed up with inefficient communication, would create a free workspace. They’d invite a few more people. Soon, conversations that once cluttered inboxes were happening in channels, visible, searchable, and far more efficient. The product wasn’t being sold; it was spreading. It was an infection of efficiency, a virus of productivity. This is the essence of the Product as a Trojan Horse strategy. It bypasses the traditional gatekeepers by appealing directly to the end-user. It weaponizes user delight and individual utility to gain a foothold inside an organization. It doesn't ask for permission; it earns its place through value. The product itself becomes the primary driver of acquisition, adoption, and expansion. This is the core of what we now call Product-Led Growth (PLG), a movement that has fundamentally reshaped the software industry. While the old guards were busy reinforcing the main gates—perfecting their enterprise sales pitches and security checklists—an entire generation of software companies was quietly rolling their horses up to the walls. By the time the CIOs and IT departments noticed, it was often too late. The product wasn't just inside the gates; it was deeply embedded in the daily workflows of their most productive teams. The employees weren't just users; they were advocates. They were champions. And they were making it clear that taking this new tool away would be a declaration of war on their own productivity. The choice for leadership was no longer whether to let the horse in, but how to gracefully pay for the army that had already conquered the city from within.
The genius of the Trojan Horse strategy lies in its choice of target. Traditional enterprise sales aimed for the throne room, believing that power flowed exclusively from the top down. Product-led growth flips this model on its head. It recognizes that in the modern workplace, influence is no longer monopolized by titles; it is earned through expertise and effectiveness. The new infiltration point is not the corner office, but the individual contributor’s desk. Why is this so effective? Because the individual employee is the one who feels the acute, daily pain that older, top-down software often creates or ignores. A C-level executive is concerned with metrics like total cost of ownership, compliance, and strategic alignment. An individual designer, however, is concerned with the agonizingly slow process of sharing mockups, getting feedback, and managing versions. A software engineer is frustrated by scattered conversations across email, chat, and project management tools that make it impossible to track a critical decision. These are not strategic, million-dollar problems; they are immediate, workflow-destroying 'paper cuts' that accumulate into a mountain of lost time and frustration. Trojan Horse products are designed to be the perfect salve for these paper cuts. They don't try to solve every problem for every person in the company. Instead, they focus with laser precision on solving one problem, exceptionally well, for one type of user. Consider the early days of Slack. It wasn't built to be an enterprise communication platform. It was born out of an internal tool used by a small team of game developers who were sick of using IRC and email. It solved *their* problem: fast, organized, searchable team communication. The initial pitch wasn't to a CIO; it was to other teams like theirs. The promise was simple: 'Use this, and your small team will work better together.' This approach is the 'land' phase of the now-famous 'land and expand' model. The goal is not to capture the whole organization at once, but to secure a small, strategic beachhead. By offering a free, self-service product, companies remove all friction to adoption. An employee doesn't need to ask for budget approval. They don't need to file a ticket with IT. They don't need to sit through a sales demo. They can simply sign up with their email address and start solving their problem in minutes. This immediate, tangible value is the key that unlocks the gate. Once the product has landed with an individual, it begins to work its magic. The user experiences a moment of delight—a 'wow' moment where they realize how much better their workflow has become. This positive experience creates a powerful emotional connection. They become a believer. This is a stark contrast to the resentment often felt towards mandated enterprise tools, which feel like a chore imposed from on high. Here, the tool feels like a personal discovery, a secret weapon. This initial adoption is fragile, but powerful. It’s a seed planted in fertile ground. The user’s success becomes the product’s success. As they use the tool to do their job better, their improved output becomes visible to their colleagues. When a coworker asks, 'How did you get that done so fast?' or 'Where did you make that great-looking presentation?', the answer is the product itself. The user’s personal productivity becomes the most compelling demo imaginable. They aren't just using the tool; they are evangelizing it through their own work. They have, without realizing it, become the first soldier to emerge from the horse, ready to open the gates for others.
A Trojan Horse cannot be just any product. It must be meticulously engineered for infiltration. Its design isn't just about features and functionality; it's about psychology, economics, and viral mechanics. There are three foundational pillars upon which every successful Trojan Horse product is built: a frictionless onboarding, a truly useful free tier, and an inherently collaborative nature. First, and most critical, is frictionless onboarding. The journey from discovery to value must be measured in minutes, not days or weeks. A potential user hears about a tool, navigates to the website, and should be actively using it to solve a real problem almost immediately. This means no mandatory sales calls, no lengthy installation processes, and no complex configuration. Think of signing up for Notion. You can use Google single sign-on, and within seconds you are presented with a clean, inviting page and a set of templates. You can start typing, dragging, and organizing instantly. The product teaches you as you go, revealing complexity progressively rather than overwhelming you upfront. This 'time to value' is the single most important metric for a product designed for bottom-up adoption. If a user gets confused or frustrated in the first five minutes, they will abandon the effort and never return. The horse will have been turned away at the gates before it even has a chance. Second is the principle of the generous and perpetually useful free tier. The 'freemium' model is the economic engine of the Trojan Horse. However, not all freemium models are created equal. A bad free tier is merely a glorified trial; it teases value but erects a paywall the moment the product becomes genuinely useful. This creates resentment. A *great* free tier, the kind used by companies like Figma and Slack, allows an individual or a small team to use the product indefinitely to solve their core problem. Figma allows you to create and collaborate on a limited number of files for free, forever. Slack’s free tier has limits on message history but allows unlimited users and integrations. The goal of this strategy is not to immediately convert free users to paid customers. The goal is to get them hooked. It allows them to integrate the product so deeply into their personal and team workflows that the thought of removing it becomes painful. The free tier is the investment the company makes in its future expansion. It’s the cost of getting the horse inside the city walls. The monetization comes later, once the product's value is no longer in question. Third, the product must be inherently collaborative. A tool for one person is a utility; a tool for a team is a platform. The most successful Trojan Horse products are built around a core loop that encourages, and often requires, sharing. You cannot use Figma to its full potential by yourself; its power is unlocked when you invite a colleague to comment on a design. You cannot use Slack alone; its entire purpose is communication with others. Calendly, the scheduling tool, provides no value until you send your link to someone else to book a meeting. This collaborative DNA is the viral engine. Each time a user shares a file, sends an invite, or posts a link, they are acting as a salesperson. They are not just using the product; they are distributing it. The product’s core function is its growth mechanism. This creates a powerful internal network effect. The first person in an organization to use the tool gains some value, but the tenth person gains ten times the value, as they can now collaborate with nine others. This escalating value is what drives the product from a personal tool to a team standard, and eventually, an organizational necessity.
Once the Trojan Horse is inside the gates and a few soldiers—the early adopters—have emerged, the next phase of the operation begins: expansion. This is where a well-designed product transitions from a useful tool for an individual to an indispensable platform for a team, and then an entire organization. This spread is not random; it is powered by a specific, potent force known as the internal network effect. A classic network effect, like that of a telephone or a social media platform, dictates that the value of the service increases for every new user who joins the network. An internal network effect is a microcosm of this phenomenon, contained within the walls of a single company. For products like Figma, Slack, or Asana, each additional employee who joins makes the tool more valuable for everyone already using it within that organization. This creates a powerful gravitational pull that is difficult for both non-users and IT departments to resist. Consider the journey of Figma within a design team. The first designer who adopts it can create and manage their own files more efficiently—a clear personal benefit. But the magic happens when they invite a second designer to collaborate on a file. Now, they can work on the same mockup in real-time, eliminating the nightmare of version control ('Final_Design_v2_Johns_edit_FINAL.fig'). When they invite a product manager to leave comments directly on the canvas, the feedback loop shrinks from days to minutes. When they share a prototype link with an engineer, the handoff process becomes seamless. With each new user from a different role, the product becomes more than a design tool; it becomes the central hub for the entire product development lifecycle. It becomes the single source of truth. This creates a powerful pull. The engineer who receives a Figma link realizes it's much easier than deciphering static screenshots. The marketing team member who needs an asset sees that they can self-serve from the shared design library. Soon, non-designers are logging into Figma not to create, but to consume, comment, and collaborate. The value of the network is no longer confined to the core group of creators; it extends to the entire web of stakeholders around them. At this point, the product has achieved a critical mass. The cost of *not* using Figma, measured in lost time, miscommunication, and inefficiency, becomes far greater than the cost of a software license. Slack follows a similar trajectory. A small team starts a workspace. It’s their private clubhouse for quick chats and file sharing. Then, someone from another team needs to be looped into a conversation. They are invited as a single-channel guest. They experience the speed and clarity of channel-based communication and are intrigued. They start a workspace for their own team. Now you have two separate Slack instances. To collaborate, people are jumping between them. The inefficiency becomes obvious. The argument to merge them into a single, paid, company-wide Slack instance becomes overwhelming. The network effect creates the very problem that the enterprise version of the product is designed to solve. The product itself manufactures the demand for its premium features. This is the silent, relentless expansion phase. It’s not driven by a sales deck, but by the daily, practical needs of collaboration. The product spreads organically along the existing lines of communication and workflow within the company. It’s a force of nature, and once it gains momentum, it is almost impossible to stop.
The transition from a handful of users to widespread adoption is not automatic. It requires a crucial transformation: the passive user must become an active champion. A user is someone who finds value in a product for themselves. A champion is someone who sees the value the product can bring to their team or the entire organization and is willing to advocate for it. They are the internal salespeople you never had to hire, and their endorsement is infinitely more credible than any vendor’s pitch. This transformation is a psychological journey, and it begins the moment a user experiences a profound improvement in their work. It’s the designer who, using Figma, gets feedback and approval on a design in a single afternoon, a process that used to take a week of emails and meetings. It’s the project manager who, using Notion, creates a project dashboard that finally gives every stakeholder a clear, real-time view of progress. This 'moment of magic' creates a sense of empowerment and loyalty. The user doesn't just like the tool; they feel grateful for it. Smart products are designed to nurture this feeling and guide users toward advocacy. They do this by making the user look good. When a user shares a beautifully organized Notion page or a slick interactive Figma prototype, their colleagues are impressed. The product becomes a vehicle for demonstrating competence and professionalism. The user’s personal brand within the company is elevated by their association with this modern, efficient tool. This provides a powerful intrinsic motivation to share their 'secret weapon' with others. As adoption grows within a team, a tipping point is reached. The tool shifts from being a personal preference to a team standard. This is often an informal process. A team lead might say, 'Okay everyone, from now on, all project updates go in our Asana board.' At this stage, the value is no longer just individual productivity; it’s team alignment and shared context. The collective dependency on the tool deepens. If the free version has limitations—like Slack’s 10,000-message history limit—the team will inevitably hit them. This is the critical moment when the conversation about payment begins. This is where the champion emerges. It’s usually the person who introduced the tool, or the team lead who has seen the tangible benefits firsthand. They are the one who drafts the email to their manager or the IT department. Their pitch is not based on a feature list from a website. It’s based on a real, lived experience. 'My team is shipping projects 20% faster since we started using this tool,' they might say. 'We can’t lose our conversation history in Slack; it’s our entire project archive. We need to upgrade.' This is not a sales request; it’s a business case. It’s a plea to protect a newfound level of productivity. Companies that master this strategy make it easy for their champions to make this case. They provide clear pricing pages, simple upgrade paths, and sometimes even pre-written email templates or ROI calculators that a champion can use to justify the expense. They arm their internal advocates with the data and arguments needed to win over the budget holders. The champion’s role is to translate the grassroots enthusiasm into the language of business value—a language that managers and executives understand. They are the bridge between the bottom-up adoption and the top-down approval, the final key-turner who makes the infiltration official.
Widespread grassroots adoption is a monumental achievement, but it is not the final victory. The ultimate goal for any Trojan Horse product is to convert this organic, often chaotic usage into a formal, lucrative enterprise-wide contract. This is the most perilous part of the journey: crossing the chasm from being a beloved team tool to becoming a trusted enterprise vendor. It requires a completely different set of features, a new sales motion, and a deep understanding of the concerns that keep a CIO awake at night. By the time a product has dozens or even hundreds of employees using it on free or small team plans, it appears on the radar of the IT department. This can be a moment of conflict. From the IT perspective, this unsanctioned tool represents 'shadow IT'—a potential security risk, a compliance nightmare, and a source of uncontrolled data sprawl. The first instinct of a traditional IT department is often to shut it down and redirect users to a sanctioned, if inferior, alternative. To survive this encounter, the product must be ready to transform from a nimble horse into a battle-ready war machine. This transformation involves building a suite of 'enterprise-grade' features. These are features that individual users rarely care about but are non-negotiable for large organizations. This includes things like Single Sign-On (SSO) for secure and easy login management, advanced user provisioning to control who has access to what, detailed audit logs to track activity for compliance purposes, and robust security certifications like SOC 2. These features are the table stakes for playing in the enterprise league. They are the product's way of saying, 'We understand your concerns. We are safe, we are secure, we are manageable.' With these features in place, the sales motion can begin. But it’s not a traditional cold-calling operation. It’s a data-driven, highly targeted approach. The company already knows exactly which organizations to target because their employees are already using the product. They can see which companies have the most users, the most active teams, and are hitting the limits of the free or pro plans. This is the 'Product-Qualified Lead' (PQL), a lead that is infinitely warmer than one generated by a marketing campaign. Their first point of contact is often not the CIO, but their existing champions inside the company. The sales team reaches out to the team leads and power users who are already advocating for the product. They partner with them, providing them with security documentation, case studies, and ROI analyses to help them make a stronger case internally. They work *with* their champions to navigate the complex procurement process. The sales conversation shifts from 'Let me tell you about our product' to 'Let's help you get the security and administrative control you need over the tool your teams already love and depend on.' This is how Slack, Figma, and Atlassian built their enterprise sales empires. They didn't abandon their bottom-up roots; they built a bridge from them to the C-suite. They used the evidence of widespread adoption and proven value as their primary sales tool. The pitch to the CIO is incredibly compelling: 'Your employees have already chosen our product. They are more productive with it. Instead of fighting this adoption, let us help you secure it, manage it, and scale its benefits across the entire organization.' It reframes the purchasing decision not as a risky bet on a new technology, but as a smart investment in formalizing and amplifying a success that is already happening. The battle is already won; the enterprise contract is simply the signing of the peace treaty.
The Trojan Horse strategy, for all its brilliance, is not a bloodless victory. Its success in bypassing traditional gatekeepers creates a new set of challenges for the organizations being infiltrated. While employees celebrate their newfound productivity, CIOs and security officers are often left grappling with the consequences of this uncontrolled, bottom-up software explosion. The hidden costs and risks are real, and a new generation of corporate defenses is rising to meet them. The most immediate problem is the rise of 'shadow IT.' This refers to any software or service used by employees without the knowledge or approval of the central IT department. When a team starts using a new project management tool or file-sharing service, they may be inadvertently storing sensitive company data on servers that haven't been vetted for security. This creates potential vulnerabilities for data breaches and non-compliance with regulations like GDPR or HIPAA. Each new Trojan Horse product is another potential crack in the company’s security armor. Beyond security, there is the issue of cost and redundancy. In a large organization, it's common for multiple teams to independently adopt and pay for the same tool, leading to duplicative spending. Worse, different teams might adopt competing tools that serve the same function—one team uses Asana, another uses Trello, and a third uses Monday.com. This creates information silos and makes cross-functional collaboration more difficult, undermining the very efficiency the tools were meant to create. The organization ends up with a fragmented, expensive, and difficult-to-manage 'tool sprawl.' Finally, there's the risk of vendor lock-in. Once a tool like Notion or Slack becomes deeply embedded in a team's workflow, migrating away from it can be incredibly painful and costly. The company's data, processes, and institutional knowledge become trapped inside a proprietary platform. This gives the software vendor immense leverage during contract renewals, allowing them to raise prices with little fear of losing the customer. In response to this new reality, savvy organizations are evolving their defenses. The old model of a rigid, prohibitive 'no' from the IT department is no longer viable; it simply drives adoption further into the shadows. Instead, modern IT and security leaders are becoming facilitators and advisors. They are shifting from a 'Department of No' to a 'Department of Know-How.' Their new strategy involves several tactics. First is proactive discovery. They use SaaS management platforms to automatically detect new applications being used within the company, bringing shadow IT into the light. Second is the creation of a 'preferred vendor list' or an 'internal app store.' They vet a selection of best-in-class, bottom-up tools for security and compliance, giving employees a menu of pre-approved options. This allows them to balance employee choice with corporate governance. Third, they are centralizing procurement. Instead of letting individual teams buy licenses, they negotiate enterprise-wide agreements to get better pricing and maintain control. They are learning to identify rising stars of bottom-up adoption early and engage with the vendors on their own terms, before the vendor gains too much leverage. In essence, the walls of Troy are being rebuilt, but they look different now. They are not high, impermeable barriers. They are more like a series of sophisticated checkpoints and customs gates. They are designed not to block every gift horse, but to inspect it, catalog it, and ensure it serves the entire city, not just the small faction that wheeled it inside.
Having journeyed through the gates of Troy, analyzed the anatomy of the horse, and witnessed its conquest from within, we arrive at the final, crucial question: How do you build one? The principles of the Trojan Horse strategy are not mystical secrets; they are a repeatable framework for building products in the modern era. Applying these lessons requires a fundamental shift in mindset, away from selling and towards enabling. First, you must begin with an obsessive focus on the end-user's pain. Do not start with a grand vision for an 'enterprise platform.' Start by identifying a single, nagging, workflow-destroying problem felt by a specific type of individual contributor. Talk to them, watch them work, and understand their 'paper cuts.' Your initial product should be a sharp, elegant knife designed to solve that one problem better than anyone else. This is your entry point, your beachhead. All a developer wants is to merge code with less friction. All a designer wants is to get feedback without exporting a dozen PNGs. Start there. Second, design for immediate value and viral loops. Your product's onboarding must be a masterclass in simplicity. A user should go from signup to 'aha!' moment in under five minutes. From there, engineer the product's core functionality to be inherently collaborative. What is the action that a user will naturally take that also serves as an invitation to a non-user? This could be sharing a document for comments, assigning a task to a colleague, or sending a scheduling link. This is not a 'viral marketing' tactic bolted on at the end; it must be woven into the very fabric of the user experience. The product must grow as it is used. Third, architect your business model around adoption, not immediate revenue. This means embracing a generous free tier that is a viable, long-term solution for individuals and small teams. Your free tier is your single greatest marketing and sales asset. It is your product's demo, trial, and distribution channel all in one. The goal is to maximize the number of people who get your product inside company walls. Monetization comes later, through usage-based limits (like message history or storage) or features that solve team and organizational problems (like advanced security, analytics, and admin controls). You must earn the right to charge your customers by first delivering undeniable value. Fourth, listen to your users and build a community. Your early adopters are not just customers; they are your co-creators, your intelligence network, and your future champions. Create direct lines of communication with them through forums, Slack communities, or beta programs. Act on their feedback with visible speed. When users feel heard and see their suggestions appear in the product, it transforms them from passive consumers into passionate advocates. This community becomes a powerful moat, a network of champions who will defend your product and spread its gospel within their own organizations. Finally, be patient and play the long game. The Trojan Horse strategy is not an overnight success story. It is a slow, methodical process of infiltration and expansion. It can take years for a product to move from a few enthusiastic users to a company-wide standard. It requires a commitment to product excellence above all else. You cannot rely on a slick sales pitch to cover for a clunky product, because your product *is* the sales pitch. Your growth is a direct reflection of the value you create for your users. Building a Trojan Horse is about more than just a go-to-market strategy; it’s a philosophy. It’s about empowering individuals, trusting that great products will spread organically, and building a business on a foundation of genuine user love. The old gates of enterprise are crumbling. The future belongs to those who build the horses.