How Stripe Built a Sales Organization to Successfully Sell to Developers

February 14, 2021

Software developers are rapidly becoming the most important buyers of technology and infrastructure in companies of all sizes. Yet all too often, developers are treated as an idiosyncratic and difficult audience—hard to reach, tricky to engage, and challenging to sell to. What’s more is that developers and software engineers are often treated as a monolithic group, when in reality there are dozens of disciplines with specific needs.

Related read: I Asked 50+ Developers How They Buy Software. Here’s What I Learned.

This is simply a bad stereotype and a hangover of outdated selling techniques. As the balance of power within companies shifts to technical roles, and sales teams understand that selling to developers is about building with them, not talking at them—progress is being made. Still, many shy away, creating an advantage for those companies that can engage.

At Stripe, we sell to developers all over the world. In our mission to increase the GDP of the internet, we work with both small startups and public companies, helping them remove the complexity of processing the payments that are the heartbeat of every business. Before Stripe, developers had to invest countless hours and dollars building infrastructure from scratch to carry out straightforward tasks like accepting payments and moving money around the world.

“The hard pitch, the feature list, rehearsed objection handling, competitor depositioning—none of these things matter when the buyer of a product is the person who builds with it.”

We’ve successfully reached developers thanks to an intentional sales strategy, and the creation of a team and company culture that treats the sales process as an opportunity to understand and solve our customers’ most critical problems and to improve our product.

Stripe is a company built by developers, for developers. As we’ve grown, we’ve come to understand that developer sales isn’t about selling in a traditional sense. The hard pitch, the feature list, rehearsed objection handling, competitor depositioning—none of these things matter when the buyer of a product is the person who builds with it, rather than a procurement professional.

At Stripe, sales isn’t about trying to convince a reluctant developer to sign a big deal. It’s about enabling developers to try our product, and understand how it can transform their business and build a case for them to use internally.

Step 1: (Really) know your audience

If traditional sales approaches don’t work with developer audiences, how can companies sell to them? We’ve found that the product experience is a crucial component of the sales process. If a developer is looking to solve a specific problem, the best way to show them value is to get them using and exploring the product.

The only thing that will convince a developer to consider your product is first-hand experience of its value. Your job is to make it as easy as possible for them to gain this experience. Developers expect a quality product, strong documentation, frictionless self-serve signup, and the ability to experiment without commitment.

“The only thing that will convince a developer to consider your product is first-hand experience of its value.”

Builders want to build. At Stripe, we provide instant self serve signup and API keys so developers can begin experimenting immediately. They don’t have to sign a contract. We don’t make them speak to a salesperson—unless they want to. We give open access to the tools they need to explore our products and build confidence with experimentation. Our job is to stand by and unblock any challenges they might face, and then help them make their internal case for adoption. The rest can come later once they know that our platform is what they want to build on.

Related read: The Do’s and Don’ts of Marketing to Developers

This isn’t the typical SaaS sales approach. That normally begins with an initial “discovery” conversation, a demo and a walkthrough of features. That said, our product-led approach doesn’t keep us from being proactive about sales. A lot of our business is built on developing larger relationships from inbound leads and self-serve signups. Of course, we’re very responsive when prospects reach out to us for support, but only in certain situations do we make the first move. When reaching out, it’s important to position yourself and enable them to ramp quicker on the product.

We also watch for specific behaviors and signals that tell us when a prospect or existing user has the potential to convert into a new or more valuable customer:

      • Product interactions: If we see an uptick in engagement—rising API calls in test mode, new products being activated or tested, increasing velocity of logins to the dashboard, etc.—that’s a strong signal of momentum building within an organization.
      • Direct contact: We are a product-led organization, but we see it as a good thing when prospects reach out to us directly. Sometimes, they reach out because they can’t find something (in which case, we know we have a problem we need to fix). But, usually any direct engagement is a positive signal for sales. If we reach out too early, our sales team has less signal at best and is annoying for customers at worst.
      • Customer value: We look at basic things like how big a company is, what their current revenue is, how much of that revenue is derived from online business, etc. But we also look at more nuanced information, like whether they’ve raised VC funding (a good indicator of future growth), and what other technical tools they use (as an indicator of ability to integrate Stripe).
      • Complex use cases: Typically, the more complex a use case or business model is, the more differentiated our product is. So, when we see something that’s more challenging than the average, it’s usually a good sign that we’re going to have a more in-depth conversation that will ultimately lead to a more robust relationship. These situations are where applying sales resource can be very valuable.

Step 2: Hire the right people

To work successfully with the discerning developer audience, you need salespeople who have sufficient technical prowess in order to earn their trust. They don’t need to be able to code, but they do need to deeply understand the logic and functionality of the API and be able to translate that knowledge into relevant solutions for each prospect, based on what they’ve understood the customer is looking to achieve.

Related read: Founders Shouldn’t Hire a VP of Sales—Here’s Why

The profile of people we hire into sales has evolved over the years. We began with a generalist profile, a common strategy for younger companies that are still figuring out product-market fit and defining the buyer audience. For the most part, that early team was comprised of people who had some technical experience—in product or consulting—but not necessarily a lot of hands-on sales experience. A common mistake that startups make is to hire a salesperson with too much experience as their first sales hire. This profile often fails, as early sales is about finding and refining product-market fit rather than closing as many deals as possible.

“To work successfully with the discerning developer audience, you need salespeople who have sufficient technical prowess in order to earn their trust.”

As our company matured and we gained more clarity about our position in the market, our sales process became more sophisticated and segmented. Now, we’ve refined our salesperson profile to focus on those who not only have lots of sales experience, but also have a specific type of experience. We need people who are familiar with selling to a technical audience, know how to sell a more complex product, and are comfortable with a consultative sales approach. Here it’s important to think of analogous products to yours and find people who’ve successfully sold those products. These may not be immediately obvious or similar products to yours.

We also look for people who can operate successfully in a product-led organization with a strong engineering focus, and with strong opinions about what products should and shouldn’t do. This is critical for us because we rely on sales to provide customer feedback to our product organization. They need to bridge the gap between the front lines and our own developer team, but we need them to do so impartially. We don’t want them trying to unduly influence the roadmap in order to close a specific deal. Our goal is to build products that help all of our users, not cater to one demanding customer.

That said, there is great value in partnering closely with a few larger customers to help inform how we evolve our product. Shopify is a great example of this kind of relationship. We listen very carefully to their needs and they work with us as a beta user on emerging features and products. Often they are building at the cutting edge of e-commerce and we listen very carefully to their needs and often adjust our roadmap to accommodate. What we build for them can often be useful for other users and so this speeds up our product development.

Step 3: Structure your organization carefully

Many SaaS companies struggle when faced with the question of whether to go broad or deep on their product offerings. At Stripe, we’ve been able to circumvent that issue by taking an API-led, platform approach. Our core payments platform (Payments and Connect) sits on top of our cloud-based infrastructure, and our suite of applications to manage revenue, prevent fraud and expand internationally sit on top of that platform.

While it’s powerful for our customers, this structure creates some additional complexity for our salespeople. Instead of only having to train them on a single product with a limited number of straightforward use cases, we now have to train our sales team on a range of interrelated products that address a wider range of more nuanced use cases and have variations in functionality depending on how they’re implemented using the API. It also means that each time we add a new product, we also have to consider the resulting connections and interactions between all the other products.

We believe the tradeoff is worth it. The platform approach delivers a much higher quality product and experience for our customers. We have several ways to make the situation more manageable for our sales team, both on the product side and the sales organization side.

Platform structure
Each of the Stripe add-on products—Radar, Sigma, Billing and Atlas—is anchored to our core payments platform. None of the applications can be used standalone. Instead, each one is additive to the overall Stripe experience. This makes it easier for us to scale because we can sell to our existing customers. It also makes it more straightforward for our customers because each component is pre-integrated, so it requires less work to implement.

Even though we’re adding more products, from a technical perspective we’re just adding to the scope of the existing API. This model makes a lot of sense because it gives customers the ability to easily do more without much incremental work, which creates a lot of product stickiness. This, in turn, results in higher retention, which leads to greater customer LTV. It’s a win-win.

Sales support
Over the years, we’ve iterated our sales organization but at the core is a commitment to making sure each salesperson has deep knowledge about not only each of our products and their various uses cases, but the larger ecosystem that encompasses all possible combinations and interactions. This allows them to adapt solutions based on specific customer needs.

As we’ve grown, we’ve used customer segmentation to enable sales specialization. In addition to segmenting by company size, we further segment based on vertical. This means that while each salesperson still has to be familiar with all the products, they can focus on the ones that are most common to the group of customers they are serving. Being able to specialize creates more opportunities to develop even more tailored solutions for that customer segment.

Finally, we’ve added additional supporting functions who step in to help facilitate larger, more complex sales. Our solutions architects help to flush out technical details during the sales process, while our deployment team helps with planning and managing the integration process. The lead sales person remains involved, but having these additional resources helps to ensure that each member of the team is spending their time as productively as possible.

Collaboration is critical

How you sell is as important as what you sell—especially when it comes to working with developers. You may have an amazing product, but if you aren’t able to capture your audience’s interest, it’s unlikely that they’ll take the first step and experiment with it.

To succeed, you need to align how your customers want to buy and how your sales team sells. If you’re selling to developers, this means taking a collaborative, product-led approach that leaves many of the more traditional sales approaches way behind.

“How you sell is as important as what you sell—especially when it comes to working with developers.”

Building the right kind of sales organization is no small undertaking, but it doesn’t need to be as complicated as you might think. Start by taking the time to gain a deep understanding of your buyers—who they are, what they need, and the kind of sales experience that will genuinely help them achieve their goals—and then over-deliver on their expectations.

Then, invest in hiring the right people to deliver this. These people are the face of your company. They are on your front line day in and day out, and their collaboration with and dedication to your customers can make or break the trajectory of your company. Choose wisely.

Always be strategic about how you structure and expand your sales organization alongside your products. Think ahead so that you don’t paint yourself into a corner on either front and maintain sufficient flexibility. Make sure that you keep your sales team well informed and well supported so that they can develop as your product does.

Editor’s note: This story was first published in September 2019 and updated in February 2021. The author is now Chief Revenue Officer at Fidel API.