Developer productivity is undergoing a tectonic shift. New software development paradigms and tooling have accelerated the pace and productivity of modern software teams, quickening the "shipping speed" of new software.

To better understand the strategic landscape, my good friend and colleague, Clio Smurro, and I interviewed founders and executives at next-generation software and infrastructure startups pushing the developer productivity frontier to get their thoughts and insights. They shared their views on:

In this second chapter, we share our findings on the top strategic priorities of developer productivity startups, including:

Want to be notified when we publish part three of our findings? Subscribe below, and we'll also send you a nicely formatted PDF of our research!

Priority #1: Product-(go-to-)market fit

Developer productivity companies work extremely hard on the initial V1 of the product. As developers themselves, these founders are targeting difficult technical problems where elegant solutions do not yet exist, hoping to bring a product to market that is fundamentally innovative. While in "heads down" mode, however, it's easy to ignore market sizing. Many developer productivity founders do not sit down to make initial estimates of their addressable market until after the technology has already been built:

2020 is all about product-market fit. The last year and a half, we built a platform that solves a hard technical problem. Now we've come out of stealth. The question is — is this a market for 5 or 5,000? Is it 5 or 10 years out? — Founder, Data Science Startup
We are doubling down on product-market fit. We need to figure out who buys our tool, what their characteristics are, and how to find more of them. — Executive, Developer Tools Startup

Successfully growing a developer productivity startup from the seed stage onward involves more than simply "knowing" what your market is. More than that, it requires forging a path from the laptops of your engineering team to the credit cards of potential users, teams, and organizations. "How to distribute" is not necessarily the same question as "how to sell," a question which confounds many developer productivity companies. This slight variation of product-market fit, which we call product-go-to-market fit, is tricky for developer productivity startups, who often achieve significant adoption of their tools well before revenue catches up, similar to many consumer startups.

As technically-oriented companies founded by technically-oriented people, developer productivity companies struggle with marketing, positioning, and sales, which are rarely their strong suits. For example, early teams often lack someone with product marketing or sales expertise, leading to ambiguity and uncertainty around how to initially frame the product or company:

We need to nail down our positioning from a marketing standpoint. We were founded by 2 ex-engineers, and we haven't had a marketing person this whole time. What is our positioning? How do we present that in an effective way? — Developer Advocate, Application Infrastructure Startup

Many companies have aligned themselves to burgeoning trends they've presciently identified, but invariably they arrive at a solution in advance of most market demand. This puts many in the difficult spot of deciding both how to bridge the gap to where real flesh-and-blood customers are today and how much bridge is worth building. Oftentimes there's a significant distance between next-gen startups on the bleeding edge and old-school organizations where most of the revenue lies:

How many people actually need real-time prediction vs just batch prediction? If they aren't yet ready for real-time, do we need to start by providing them stepping stones to meet them where they’re at? — Founder, Data Science Startup

Part of that bridge comes in the form of product improvements that enhance the applicability of the product to real customer use cases. One founder framed this as "product geometry":

What we've built is a relatively new concept for people. But we have to make sure that the product geometry maps well to actual customers needs for enough people. — Founder, Data Science Startup

On the other hand, sometimes the product is fine as-is but education is required to both generate awareness and understanding of the potential value of the product or service. This doesn't always work, naturally leading to the question — is it them or us?:

If you talk to potential customers, there’s a lot of customer education required. If you’re trying to explain it and they’re not getting it, is that their problem or yours for not explaining it right? — Founder, Data Science Startup

Another vector upon which to achieve product-go-to-market fit is in the business model itself. Pricing can be a meaningful barrier to adoption. If it's too expensive to get started with the product, most developers and small organizations will never bother to try it out, which can be a missed a opportunity:

We want to bring down the cost of using our technology to the point where we can give it to developers for free, especially since Amazon and others provide a free version. — Executive, Application Infrastructure Startup

This is not simply a matter of changing the pricing on your website. For example, if your distributed database requires a node of at least a certain size to avoid performance issues, lowering the barrier to entry for prospective customers requires modifying the product. Certain technologies, especially infrastructure running clusters or nodes in the cloud may require significant architectural changes to run on smaller instances:

Our technology is expensive to run. Our cheapest cluster is still $50+/month. We'd love to get it down to $10/month so more people can get a small slice of it instead of fewer people getting a big slice of it. — Executive, Application Infrastructure Startup

Priority #2: Sow first, reap later

Developer productivity startups execute a very clear one-two punch — plant and nurture the seeds of grassroots adoption first, harvest revenue second. In other words, if they use it, they will (eventually) pay for it (or so the theory goes):

Our number one goal is to increase end user adoption. Our second goal is revenue. We believe that if they try our product, they will spend for it eventually. — Executive, Developer Tools Startup

Oftentimes, the first step is achieved via an organic open core model where core functionality is made available in the open source edition of the product, with extra team and enterprise-focused features available as closed source or open source activated via license key. Broadening open source adoption becomes a singular goal for many:

Our mission is straightforward — we want to 10x our open source community. — Founder, Data Science Startup
We want to make [our open source technology] a huge success. We want to grow the open source community. — Founder, Application Infrastructure Startup

Self-service is the key to bottoms-up adoption. Developers want to get up to speed as quickly as possible with minimal friction. They need to see value immediately and feel like they are in control. Typically, this means having the ability to spin up a small instance or process on their laptop via command-line interface (CLI) or other tool:

We need more bottoms-up adoption from developers. Building capabilities for developers to spin up their own instances is key. — Executive, Application Infrastructure Startup

But the "if they use it, they will pay for it" logic does not always play out. Sometimes, bottoms-up adoption works well for the free version of a tool but doesn't work so well for the paid version. It's not uncommon to see technologies, especially those that are open source, struggle to convert adoption into paid usage. And when users do want to pay for more features, developer productivity startups quickly find out its much harder to onboard paid clients who now have higher expectations, need more hand-holding, and require service-level agreements (SLAs). This makes paying customers much more difficult to adequately serve than open source users who can simply download and go:

We have tons of interest in our beta. We want to move them from beta users to paid customers. We need to figure out a better way to onboard clients to make us more efficient and scalable. — Developer Advocate, Application Infrastructure Startup
Every account is very manual right now. We're very much a "white glove" service. — Manager, Application Infrastructure Startup

One might expect ambitious growth plans to temper in the face of the COVID-19 pandemic. Interestingly, most of the startups we spoke with have seen little measurable impact from COVID-19. Most are beginning from a small starting point with little to lose, meaning that everything is effectively upside. Yes, the pandemic is certainly generated waves, but these early-stage vendors manage to stay largely under the surf:

We’re not big enough for COVID to affect us. We're starting from zero, so all growth is significant. All clients are growth for us. — Executive, Data Science Startup
We haven’t really been affected by COVID at all. Some consumer and travel customers have had to pull out or pause. Otherwise, no issues from COVID. — Developer Advocate, Application Infrastructure Startup

As companies targeting developers, who are more accustomed to working remote, developer productivity companies have not seen much disruption in buying or usage patterns. In some cases, COVID-19 has actually served as a tailwind, with work from home generating a need for better, more robust tools that individuals and small teams can use independently to get productive work done:

If anything it’s helped us. People are home doing data science and they need right tools. — Executive, Data Science Startup

Priority #3: Customers must succeed... or we will fail

We’re starting to move to a phase of our business where customer success is increasingly important. — Executive, Application Infrastructure Startup

Moving fast and breaking things makes sense in the earliest phases of development when shipping product out the door takes precedence, but early design decisions eventually catch up with you. The best things move quickly in the early days to achieve a minimum viable product that serves the more obvious use cases but pivot at some point to cleaning up the mess they made:

We started by shipping a lot of things really quickly, but what we shipped was buggy and broke a lot of design conventions. We’re working on re-skinning it, improving accessibility, etc. Fit and finish. Polish. — Manager, Developer Tools Startup

Here again, education comes up as important process getting users up to speed and reducing time-to-value. Ironically, developer productivity tools, especially on the infrastructure side, can be complex and difficult to learn, emphasizing the importance of high-quality documentation and customer support.

Improving the user experience is a priority. The process of signing up, using the product, all the different use cases. Our product is difficult and complex to learn. We need to make it easier. — Executive, Developer Tools Startup

Eventually, once the product is in good shape and serving initial use cases well, the focus shifts to customer success and retention. This often involves solving for issues that do not necessarily arise in casual usage but do crop up in large-scale production environments or other serious use cases. Sophisticated customers have little patience for a tool that fails when it counts most:

For the first few years, it was about getting our first use cases. Does it demo well? Can it survive contrived failure scenarios? Now that we have a lot of customers, we focus on retention. — Executive, Application Infrastructure Startup

Customer success means serving all stakeholders well. This means both individual contributors and managers, the front office and back office, and so on. For example, infrastructure companies must appease not only the principal architect tasked with conceiving the target architecture that will then be implemented, but the individual developers themselves who will either implementing or maintaining the technology on an ongoing basis:

We need to make our technology more developer friendly. Infrastructure architects love us, but once the architects make that decision, they need people to build that vision. — Executive, Application Infrastructure Startup

As developer productivity startups move up-market, customers demand more enterprise-grade features. Developer productivity becomes organizational productivity. In this sense, customer success becomes a source of product development feedback, informing the roadmap and guiding vendors toward new revenue opportunities and larger deals:

Our customers need to be able to plug our technology into the rest of their enterprise stack. Single sign on, lightweight directory protocol (LDAP), etc. We call this enterprise "ruggedization." — Executive, Application Infrastructure Startup

In addition to enterprise features, developer productivity startups must plug into a number of popular developer and collaboration tools already in place in many of the organizations they wish to penetrate. Integrations to Slack, Atlassian, Git, and other tools becomes "table stakes" — practically required to see wide adoption given how embedded these other tools are in the workflows of most developers:

We want to deepen our integrations. Jenkins, GitHub, Atlassian, GitLab, Microsoft. We want first-class plugins. — Executive, Application Security Startup

Conclusion

As with most startups, developer productivity companies must adapt to an evolving strategic context as they scale and mature. What worked in stealth might not work after public launch; what passed muster as a scraggly startup selling to other startups might not cut it for buttoned-down enterprise clients.

This strategic evolution comes in three broad phases:

  • First, developer productivity startups map out and blaze a trail from the source code to the credit card numbers of user and buyers at target organizations
  • Second, having identified fertile soil, they seed the market via organic adoption, making bets that will hopefully bear fruit the form of revenue in the coming month and years
  • Third and last, the best developer productivity companies ensure their fledgling customers do not die on the vine but rather grow their usage and expand their contracts over time

Successful execution of this three part plan lays a strong foundation for developer productivity companies to thrive and survive in the face of strategic threats (the public cloud casts a long shadow) or economic disruption.

Be informed of our next and final publication in this series, the biggest challenges and pain points of developer productivity companies, by entering your email below: