Session 3 - You don’t need more leads. You need better timing: Intent Signals

How Intent Signals Powered HashiCorp’s $15B GTM Engine

In just over a decade, HashiCorp evolved from a side project into a cloud infrastructure powerhouse - trusted by over 200 Fortune 500 companies. When it went public in 2021, it was valued at more than $15 billion. But HashiCorp’s story isn’t just about building great tools. It’s about creating products that fit seamlessly into developer workflows - and using that to drive adoption, trust, and long-term revenue.

Origin Story

Back in 2010, cloud infrastructure was getting more complex, and developers were struggling with managing virtual environments.

Mitchell Hashimoto, a young software engineer, was frustrated by the tedious setup process required just to get a development environment running. He wanted something simpler, repeatable, and scalable.

So, he built Vagrant. An open-source tool to spin up consistent, reproducible dev environments.

It spread fast. Thousands of developers started using it. By 2012, Mitchell was flooded with support requests. But as Vagrant gained traction, Mitchell realized that spinning up environments was only the beginning. Developers still lacked consistent workflows for things like provisioning infrastructure, managing configurations, and enforcing security. Vagrant had solved the first step - but the rest of the journey was still fragmented.

Developers didn’t just need a better way to spin up environments. They needed a better way to provision, secure, and operate across the entire cloud infrastructure stack.

That is how HashiCorp was born.

HashiCorp wasn’t just built to support Vagrant - it was built to support the entire journey developers take across cloud infrastructure. From provisioning to security to orchestration, the goal was clear: own the workflow.

Product Strategy: The Philosophy

As developers adopted Vagrant and surfaced broader infrastructure pain points, Mitchell began to think bigger. It wasn’t just about virtual environments anymore - it was about fixing the entire cloud workflow. From the beginning, that broader ambition was shaped by a guiding framework - their foundational document, the Tao of HashiCorp. Think of it as a product philosophy meets company manifesto.

“The HashiCorp approach is to focus on the end goal and workflow, rather than the underlying technologies. Software and hardware will evolve and improve, and it is our goal to make adoption of new tooling simple, while still providing the most streamlined user experience possible.”

This wasn't just a set of values - it was the blueprint for everything they did.

They took a structured view of how infrastructure should be delivered - and committed to building tools that supported each phase of that journey. They were mapping the journey developers take to provision, secure, and operate infrastructure - and building tools for each step.  They weren’t solving isolated problems, they were building a system.

The Suite That Shaped the Cloud

HashiCorp’s vision came to life through a carefully constructed suite of tools-each solving a critical step in the infrastructure lifecycle:

  • Terraform for provisioning infrastructure as code
  • Vault for managing secrets and protecting sensitive data
  • Consul for enabling service discovery and secure networking
  • Nomad for scheduling and orchestrating workloads
  • Packer, Boundary, and Waypoint to handle auxiliary needs like image automation, access control, and application deployment

What set these tools apart wasn’t just what they did - it was how they worked together.

Each product was designed with interoperability in mind. Developers could start with Terraform and later adopt Vault without having to relearn workflows or change mental models. The learning curve stayed low. The productivity curve stayed high.

This approach created a natural progression: as teams matured in their cloud journey, they would reach for the next HashiCorp tool without needing to be sold on it.

The suite didn’t just solve individual problems - it offered a coherent way to run infrastructure at scale. That’s how HashiCorp became the “go-to” in the modern infrastructure stack - By showing up at every stage of the developer’s journey. Whether provisioning with Terraform or securing workloads with Vault, their tools earned adoption by solving real problems, right when developers encountered them.

But building great tools wasn’t enough. To win adoption at scale, HashiCorp had to make sure those tools were discovered and used by the right teams - at the right time.

Adoption Strategy: How HashiCorp Made Adoption Effortless

So far, we’ve seen how HashiCorp built a suite of tools that aligned tightly with developer workflows. But how did those tools actually get adopted? And why did developers choose them-over and over again?

HashiCorp didn’t just build great products. They engineered the path to adoption. From day one, the experience of discovering and using their tools felt seamless -  utility, delivered at exactly the right moment.

Every product started the same way: open source.

This wasn’t just a distribution hack. It was a strategic advantage.

Open source made it frictionless for developers to adopt a HashiCorp tool when they hit a problem. It also ensured HashiCorp became embedded before any buying conversation even started.

And because each tool sat in a different part of the workflow, HashiCorp could be discovered multiple times within the same org by different teams. It was a sideways expansion machine.

More importantly, being open source gave the team visibility into how developers actually used their tools. HashiCorp built systems to track everything - from GitHub issues and engagement on docs to activities on forums and  and questions on community channels

  • GitHub issues and contributions revealed feature gaps and usability problems
  • Documentation feedback and search behavior surfaced where people were getting stuck
  • Community questions on forums and support channels highlighted recurring pain points

This created a tight feedback loop between users and product teams. Instead of relying on guesswork or delayed enterprise feedback, HashiCorp could see in real time what developers needed-and ship improvements quickly.

This depth of visibility laid the foundation for something even more powerful: a GTM engine driven entirely by intent signals.

Monetisation Strategy: Turning Developer Adoption into Revenue Opportunities

HashiCorp achieved widespread developer adoption early on - but adoption alone doesn’t build a $15B company.

Despite having one of the most organic, high-volume developer adoption motions in infra, HashiCorp knew that an enterprise sales motion was still essential.

What made them truly successful was their ability to convert developer activity into revenue opportunities - by turning usage signals into sales intelligence.

Hashicorp tracked every single Developer Activity and used these product signals to guide Sales - who to target, when to target, what to pitch. What made it so powerful wasn’t simply the fact that Hashicorp had developer activity signals. It was the fact that each developer activity reflected meaningful milestones inside the developer’s workflow. Sales didn’t step in after a random sign-up, they stepped in when a team had deployed infrastructure, hit scale, or needed to standardize. Outreach felt like a continuation of the workflow - not an interruption.

HashiCorp invested in internal systems that prioritized workflow maturity over surface-level signals. Their revenue engine was built on a deep understanding of how developers progressed through real infrastructure milestones.

HashiCorp monitored a variety of signals that gave them insight into both adoption depth and expansion potential:

  • Depth of usage - This indicated which Companies had deeply embedded Hashicorp products. If a team was using Sentinel policies or advanced Vault configurations, it meant core infrastructure workflows depended on HashiCorp tools.
  • Breadth across teams -This indicated the Hashicorp had spread Org wide, or at least across multiple teams.When multiple departments or teams were using the tools, HashiCorp knew the product was no longer solving a niche problem—it had become foundational.
  • Cross-product activity - Indicated workflow maturity. When teams started using tools like Terraform and Vault together, it showed they were stitching together a broader HashiCorp-powered workflow.
  • Maturity signals - Indicated when teams started scaling, or when they started exploring Enterprise features such as Security, Team collaboration and Scale
  • Trouble ShootingDevelopers ask for help when they’re invested. HashiCorp monitored forums, GitHub issues, and community posts for signs of urgency, blockers, and expansion potential.

These signals were aggregated at the account level and pushed into Salesforce, giving sales teams a clear, data-driven view of how each account was progressing. They had automated Slack feeds that tagged each individual sales rep when one of their accounts was ready to buy. Reps were equipped with these account-level insights to reach out with relevance, and timed perfectly to where the user was in their workflow.

To make those moments count, HashiCorp also enabled its sales team with context-aware materials developed through strong sales enablement and technical product marketing functions. These included product demos, presentations, technical white papers, and scenario-based enablement content tailored to account maturity and workflow stage. Whether a team was just starting with Vault or rolling it out org-wide, reps had the resources to guide the conversation effectively.

Expansion Strategy

HashiCorp didn’t treat initial product adoption as the finish line - it was just the beginning. Their go-to-market strategy was built around expanding successful accounts by understanding their workflow maturity and spotting the right moment to go deeper. They weren’t just adding seats or pushing upgrades. They were watching for meaningful product usage patterns - real signals that told them where each customer was in their journey, and what expansion path made the most sense next.

Once a product was in active use, HashiCorp used intent signals to guide the next move: Should they scale adoption across more teams? Or introduce the next tool in the stack that solved a nearby problem?

This was their land-and-expand motion in action - rooted in product usage, driven by developer behavior, and executed with precision.

Path 1: Expand Adopted Tools Across Teams

In large companies, HashiCorp tools often entered through individual teams - each solving their own infrastructure problems. One team might be provisioning with Terraform, another managing secrets with Vault, another experimenting with Consul.

The Problem: This kind of siloed adoption led to fragmented workflows, duplicated efforts, and inconsistent security practices. Without centralized standards, teams struggled with operational inefficiencies and increased risk.

HashiCorp’s Approach: Rather than treating each team as a separate opportunity, HashiCorp looked at the broader org-wide pattern. When their systems flagged siloed usage across departments, they didn’t just pitch a bigger license - they reached out to Platform Engineering teams.

These teams were responsible for setting infrastructure standards and had already felt the pain of managing inconsistent workflows. HashiCorp helped them see the value of consolidation-not just for governance, but for speed, security, and scale.

HashiCorp offered enterprise versions of its tools-designed to unify workflows across teams, enforce consistent policies, and scale infrastructure securely under a central governance model. The pitch wasn’t about buying more licenses - it was about simplifying operations and enabling long-term alignment.

The Outcome:  Once platform teams bought in, they often became internal champions - driving adoption across teams and unlocking broader enterprise deals.

Path 2: Introduce the Next Tool in the Workflow

HashiCorp’s product suite was very modular. Each tool served a different layer of the cloud stack. This architecture made cross-sell opportunities feel natural, not forced.

When teams adopted one tool and started exploring adjacent problems, sales saw an opening. But they didn’t rely on guesswork.They tracked product usage alongside docs activity - like teams reading Packer tutorials, a sign they were automating builds and going deeper into provisioning workflows.

If usage of Product A was high and there were signs of interest in Product B, reps stepped in with context-rich conversations. The trust earned from one product created space to introduce the next.

Several HashiCorp tutorial pages (Terraform+Vault, Terraform+Packer) provide information about how developers can use other tools from the HashiCorp Stack to increase their efficiency and ROI. These weren’t just educational assets - they were quiet conversion surfaces.

Cross-sells happened when developers naturally hit the limits of one tool and began exploring what came next. Sales wasn’t forcing a suite - they were extending a workflow.

The result? Steady, sequential adoption powered by real developer intent.This was product-led revenue expansion.

Scaling GTM for Enterprise

HashiCorp’s enterprise contracts often took 6–12 months to close and involved 10–15 stakeholders. To succeed, they activated a multi-threaded ABM playbook - complementing product-led growth with tailored engagement across different layers of the org:

  • Engaging executives directly - Sales teams built high-trust relationships with CTOs, CIOs, and VPs. Executive dinners and strategic discussions focused on infrastructure governance, risk mitigation, and long-term scalability.
  • Educating the middle layer - Platform, security, and procurement teams were nurtured with personalized campaigns, technical workshops, and content that showcased emerging tools and best practices. These assets helped them see what was possible—and how to scale what was already working.
  • Empowering developers - At the ground level, HashiCorp made developers' lives easier with powerful, usable tools. Developers weren’t just end users - they became internal champions who influenced decision-makers and rallied other teams around HashiCorp products.

This wasn’t just about landing deals - it was about aligning stakeholders across the org. By mapping its engagement to the structure of modern engineering orgs, HashiCorp built consensus across role

By 2023, HashiCorp had 200+ Fortune 500 clients.

Key Takeaways from HashiCorp’s GTM Playbook

1. Become a part of the workflow

Each product that Hashicorp built solved a real bottleneck - whether it was provisioning, managing secrets, or scheduling workloads-and became a key part of how teams operated day to day. This tight fit with actual developer behavior meant that adoption didn’t need to be forced. It felt inevitable. Teams didn’t have to change how they worked to use HashiCorp - they got to work better because of it.

2. Turn developer activity into sales signals‍Instead of chasing shallow signals like form-fills or webinar clicks, HashiCorp relied on real in-product milestones to guide sales engagement. When a team hit production with Terraform, enabled Sentinel, or activated SSO, it signaled readiness to scale. These were the moments where outreach felt relevant-because it was rooted in usage maturity.

3. Surface intent signals beyond the product

HashiCorp didn’t just track what happened inside the product - they watched how teams engaged with learning resources and community content. Whether reading documentation or exploring integration guides, these behaviors often revealed when a team was preparing to expand. For example, pages like Terraform+Vault weren’t just learning resources - they revealed which teams were actively exploring the next step in their infrastructure journey. Sales picked up on these signals and started conversations.

4. Identify expansion patterns using intent signals

HashiCorp looked for signals that showed where adoption was headed next. If usage had spread across teams, if multiple tools were being used together, or if developers were discussing blockers in forums - it meant the account was warming up. Sales didn’t force expansion. They showed up at the right time with the right play.

5. Equip sales to act on intent, not just observe it

HashiCorp didn’t stop at surfacing signals. They made sure sales reps had the resources to follow up with precision - product demos, technical white papers, and scenario-based assets matched to each account’s maturity. Whether a team was onboarding or rolling out org-wide, reps were ready to guide the conversation.

6. Reach the right role with the right message

Enterprise deals weren’t about a single decision-maker. HashiCorp built a GTM playbook that targeted developers, platform owners, and execs - each with tailored messaging. Developer champions helped build momentum, while exec-level content focused on governance, risk, and ROI.

Together, these takeaways reveal a larger theme: HashiCorp didn’t just use intent signals - they operationalized them across product, marketing, and sales. From anonymous open source activity to enterprise-grade expansion, they tracked everything and turned it into GTM precision.

How Reo.Dev Can Help You Build a Winning Go-To-Market Strategy

We are helping 100+ companies set up a GTM motion similar to Hashicorp.

Need help?

Great sales isn’t pushing harder- it’s showing up at the right moment.

Developer intent signals from public forums like Reddit, Quora, Discord, Stack Overflow, and Product Hunt showing problem discussions and tool evaluation behavior
Engineering signals including competitive intelligence, tech stack usage, hiring changes, funding events, and roadmap priorities

💡35% Of Companies showing Purchase Intent were missing from the CRM, or were not marked as “Opportunity” in the CRM. No one, was targeting them!
💡Upto 50% Of Companies that are marked as “Opportunity” in the CRM were not showing any signs of Purchase Intent. Often it was just an enthusiastic developer trying something out!
💡70% Sales Team have a static Target Account List. Not based on which Accounts are showing intent “right now”
Website intent signals including homepage visits, pricing page views, product pages, technical blogs, and developer documentation usage
GitHub interaction signals such as stars, watches, issues, comments, forks, and pull requests indicating developer interest and usage
Product usage intent signals including cloud signups, repeat logins, free tier usage, paywall hits, and multi-user adoption
Technical intent signals from package downloads, CLI commands, deployments, and production usage across developer environments
First-party intent signals for DevTools including website visits, documentation usage, API key generation, GitHub activity, and telemetry
Comparison of B2B SaaS vs DevTools intent signals showing differences in website visits, product usage, CLI commands, and developer ecosystems

Understanding Intent Signals - Market Intelligence [1/2]

Category Strength Description
Competitive Intelligence Strong Scenario 1: Evaluating competitor product – indicates window of opportunity
Scenario 2: Struggling with competitor product – displacement opportunity
Scenario 3: Using competitor product – future opportunity or disqualification
Complementary Tech Stack Usage Medium Can indicate a revenue opportunity, especially if the company is facing problems your product is designed to solve.
However, it signals potential fit rather than immediate buying intent.
New Engineering Leader Strong New engineering leaders come in with a specific mandate to scale, streamline or build new capabilities. Have budget and are often open to investing in tools.
Champion Job Change Strong Existing user switches job and lands in a new company. Opens up opportunity to land the new company.
Engineering Org Growth / Decline Medium Growth in engineering team often signals increasing software development activity and system complexity, which can create demand for tools that increase reliability, scalability, streamline infrastructure management, developer productivity.
Engineering Investments Very Strong Engineering investments signal that a company is expanding development efforts for a certain business objective – which often requires new developer infrastructure and tools.
Engineering Roadmap and Priorities Very Strong Knowing an engineering team's immediate priority reveals the problems they are actively trying to solve, making it easier to position a dev tool as a direct solution. When a tool aligns with a current priority, the urgency and likelihood of purchase increase significantly.
Funding Raised Strong Newly funded signals that a company now has fresh budget to invest in building and scaling its product, which often includes developer infrastructure and tools. During this phase, teams are typically more open to adopting dev tools that help them move faster and scale efficiently.
New Engineering Leader Strong Often reveals a company’s strategic priorities, product initiatives, and technology investments. These insights help devtool teams identify where engineering spend is likely to increase and position their tools accordingly.

Social Listening & Community Signals

DevTools buying behavior highlighting short opportunity windows, technical buyers, long evaluation cycles, and build vs buy decisions
Need help?