Hashicorp's ALEER Sales Process
An excellent model for others to study
It’s not often that you get a diagram that is explicitly clear as to how a company navigates from usage to enterprise contracts to expansion.
Hashicorp’s earnings slides are a masterclass in product positioning, storytelling, and information rich diagrams. Their slide below on their sales playbook is amazing and something every OSS and proprietary dev tools team should study!
The most amazing thing is that as a $5B market cap company at $480M ARR growing 50% YoY with 130%+ net retention, Hashicorp is still focused on landing with smaller dev teams and expanding from there. It would be easy for them to simply say we’re only going to focus on enterprise accounts, but the power of dev-first gtm is that you never know what seed can grow into a tree. So it’s always important to continue watering the seeds.
Let’s break down their ALEER playbook below:
Adopt: The most important thing for arguably any enterprise software company is usage. Do users love the product and believe it is solving an acute pain point such that they’re willing to put up with the immaturity of the current product state. Hashi focuses on getting developers to engage with their OSS projects first. By getting them to look at the code, maybe even start to implement one of the products in a greenfield workflow, and self-serve with rich documentation, developers are already learning how Hashi’s products work before pursuing a formal contract. The company is very active on issue requests and also has a rich community built around answering questions that devs have. This also allows for different industries and use cases to be uncovered through developers either enabling telemetry (of which clear reasoning is explained) or opting in to chat with a dev rel or community participant.
Notice also the consistent git-star and forking volume across all their products (crude metric that we can use for traction). Hashi has a big focus on meetups, user conferences, developer relations, conference talks, blogs, joint customer webinars. All these efforts are about expanding the surface area of developers that can see and experience their products.
Land: Once they’ve gotten some consistent usage, Hashicorp works to identify the use case that the developer is looking to solve. This may mean landing with an initial product that is more of a “scoped” use case. I.e. the whole org may not use it but the specific team that has played around with the OSS product clearly has some pain. Once the pain is identified, Hashicorp can move to discuss how the specific product can help and deliver that value. It seems like they’ve identified Terraform (infrastructure as code) and Vault (secrets management) as their core land products that most dev teams feel immediate pain for.
Expand: Notice the focus on additional use case. Too often, teams try to simply sell a new product at this stage. “You’re using Product #1 but we also developed Product #2 and you should check it out.” Instead working with the internal champions to develop the next use case first makes for a much more efficient upsell. This comes from being deeply embedded with the user which is why the focus on individual devs at the OSS stage up to Expand is so important. Hashi has earned the trust from the devs that the company can solve their pain points. So now expansion happens maybe from one team to the whole org or from Vault being used for secrets management only to fully powering just-in-time privileged access management across the org. The company is not yet trying to upsell new products, they are focused on increasing adoption of the existing product and expanding throughout the org.
Extend: This is finally where Hashicorp looks to sell a new product. Now the trust of the larger org has been earned. So Hashi can start talking about other adjacent or entirely new areas where they have products. While this is going on though, the new product motion to a certain extent reverts back to the earlier process for Product #1. Perhaps the OSS adoption step is skipped (although likely its still helpful to get devs up to speed on the product quicker and how it could help), but certainly the land & expand steps in terms of finding the use case, expanding adoption and moving throughout the org needs to happen all over again. Also, once a company has multiple Hashi products, the company has identified that zero-trust security products are an area to cross-sell into given at the very least two products (the Hashi ones) can adopt a zero-trust architecture.
Renew: Notice the focus on renewals is not just about getting the customer to resign the contract. It’s about making sure deployment and adoption has progressed well. A company can renew a contract but if the workforce adoption is low, 1) that means likely to churn and 2) makes it hard to up-sell/cross-sell when not getting critical mass of usage from existing product already. This is where the close developer relationship is so important to help arm internal evangelists to bring about change throughout the org.
Usage, usage, usage! If there’s one takeaway from this post, I hope it’s that. High usage = increased adoption throughout an org = earned trust with teams closest to the code = higher likelihood of extend into new products leading to best in class net retention above 130%.
What I’ve Enjoyed This Week:
Kubernetes on the edge (and first i’ve seen in fast food not telecom, healthcare, industrials, financials)! Latest example of every company is a software company with Chick-fil-A
Any multitenancy service works in concert with systems to ensure fairness. Fairness means that every client in a multi-tenant system is provided with a single-tenant experience. The systems that ensure fairness in multi-tenant systems are similar to systems that perform bin-packing algorithms, which are classic algorithms in computer science. These fairness systems do the following things:
Perform placement algorithms to find a spot in the fleet for new workload. (Similar to finding a bin with room for the workload.)
Continuously monitor the utilization of each workload and each server to move workloads around. (Similar to moving workloads between bins to ensure that no bin is too full.)
Monitor the overall fleet utilization, and add or remove capacity as needed. (Similar to adding more bins when they’re all getting full, and removing bins when they’re empty.)
Allow workloads to stretch beyond hard-allocated performance boundaries as long as the underlying system isn’t being fully utilized, and hold workloads to their boundaries when the system is fully utilized. (Similar to allowing workloads to stretch within each bin as long as they’re not crowding out other workloads.)
Long time readers have heard me rant about AI and ridiculous terminology that we come up with enough times…so now you can hear from someone much smarter than me. Encourage you to read the whole thread
CJ wrote an excellent post describing how finance influences company purchasing decisions. It’s a great explainer for founders to understand how purchase decisions are made
