1. Library
  2. How to Launch an AI Startup: Lessons from GitHub Copilot

How to Launch an AI Startup: Lessons from GitHub Copilot

Light Mode
Getting 1.2M Devs to Adopt Your AI Product
1. Pre-Release Surveys and Information-Gathering Are Crucial
2. Build and Empower Communities Early
3. Understand the Differences Between AI Product and More-Traditional Dev Products
4. There Are No Shortcuts
Preparing for Launch
Important Pre-Launch Learnings:
More Resources: How to Incorporate Early Feedback Pre-Launch
Getting the Story Right
Important Learnings on Messaging:
More Resources: How to Hone Your Early Startup Messaging
Early Launch Prep: Community, Promotion, Events
Important Community Learnings:
More Resources: Learn About How to Execute on Community and Promotion
Balancing Business Goals vs. Community Goals
Important Learnings on Working Against Revenue Goals
More Resources: Learn About How to Hit Revenue Targets
Launching an AI Startup vs. a Non-AI Startup
  • Alyss Noland
    Alyss NolandFormer GitHub & Atlassian GTM expert
    Honeycomb
29 min

Getting 1.2M Devs to Adopt Your AI Product

GitHub Copilot is one of the most talked-about AI coding assistants on the market. As 92% of surveyed software engineers reportedly use generative AI products as part of their development process, GitHub itself claims adoption at 37,000 organizations and counting. At a glance, Copilot’s success might’ve seemed like a foregone conclusion, given GitHub’s enormous reach and parent company Microsoft’s marketing muscle. However, Copilot entered the market at a time when generative AI was unproven territory. The launch was a significant effort that involved strategic preparation and collaboration across a team of thousands of employees working in a variety of functions, each with competing priorities, and substantial pressure to drive commercial business and grow revenue.

Go-to-market expert Alyss Noland, who was a product marketing lead at GitHub at the time, spearheaded the launch and suggests that the process was a lot more complicated than it might have seemed. Fortunately, the launch also offers important lessons for any startups looking to break into the competitive AI space. Noland recounts some of the most important learnings from her time leading the launch, and speaks further about it in a Speaker Series event:

1. Pre-Release Surveys and Information-Gathering Are Crucial

Given how GenAI has many documented attributes, including well-known strengths and weaknesses, it’s important to seek out early feedback when launching an AI product for developers–to not only gauge interest and most impactful use cases, but also to identify early objections and better understand how to help your audience understand the message.

2. Build and Empower Communities Early

Building a community has many benefits. Beyond soliciting feedback and sharpening messaging as above, creating a community gives you opportunities to drive early adoption as well as to build credibility for your product by activating vocal users, provided you amplify their voices in an authentic and respectful way.

3. Understand the Differences Between AI Product and More-Traditional Dev Products

AI products carry additional considerations, such as potential regulatory issues, as well as potential security and data privacy risks unique to prompt-based products trained on specific datasets. Given the enormous amount of hype around AI products, developers may be understandably skeptical about what your AI startup does–and may require thorough documentation and full explanations of how you protect your users from risk.

4. There Are No Shortcuts

Launching an AI startup that produces software for developers to use? You’ll still have to put in the hard yards that all other developer-first startups working on DevTools also put in: Starting a developer-first company from first principles, including understanding your customer persona, building a messaging framework, creating a community and building trust and credibility within it, and achieving product-market fit.

Next: An extended interview with Alyss Noland on the toughest challenges and most important nuances involved in launching GitHub Copilot.

Preparing for Launch

Important Pre-Launch Learnings:

  • Pre-Launch Interviews and Surveys Help Confirm Theories, Handle Objections: Noland’s crucial interviews with early design partners and customers helped GitHub better understand how to position Copilot and handle objections about the software potentially being a threat to people’s jobs.
  • Developer-First Go-To-Market Must Include Enough Context for Developers: Developers, being universally curious about how things work, were unlikely to be receptive to a poorly documented, black box product. Copilot’s customers would need enough context and understanding of how it worked to adopt it.

To contextualize the launch, Noland concedes several factors. For example, GitHub was already an established player in the developer space with a massive footprint. Also, there were already early AI predecessors to Copilot, such as Microsoft's IntelliCode and models based on GPT-2, but there had never been a launch on Copilot’s scale. OpenAI had made headlines with GPT-3, but at the time, it was not a commercial product or integrated into workflows.

One of GitHub’s biggest concerns during Copilot's early development was how people would react to it. Would it be seen as a threat to replace developers’ jobs? “There were a lot of considerations for Copilot based on how the product would be received. We had to account for how people would react to a new technology. We had to figure out how we could peel back the curtain and make this black box seem less scary and less intimidating,” Noland explains. The team decided to focus on positioning Copilot more like a partner in users' efforts, rather than something that would replace them–an approach that influenced the product's design and development that GitHub covers in a separate blog on designing AI tools.

To figure out how to properly position Copilot, Noland ended up working closely with researchers on GitHub Next. Before launch, Noland made it a priority to conduct customer interviews and surveys led by Dr. Eirini Kalliamvakou to understand how people actually used Copilot in the real world and prepare for technical preview. The idea was to confirm whether GitHub’s assumption about Copilot’s usage matched reality, as well as to understand how valuable Copilot would be among developers of different levels of skill and levels of familiarity with AI tooling.

There were a lot of considerations for Copilot based on how the product would be received. We had to account for how people would react to a new technology.”

Of surveyed audiences, the interviews revealed that researchers were intrigued by Copilot’s potential, even if they weren’t a strong fit for the tool. However, developer audiences, particularly senior engineering leads, experienced numerous "wow moments" when they realized how Copilot could assist them even with tasks that required using unfamiliar programming languages or frameworks.

While Copilot seemed to find early signs of product-market fit with developers, Noland knew that for GitHub’s launch to be successful, its message would have to land with an audience that is known for being naturally curious about how things work. She compiled notes from her research colleagues on Copilot’s statistical nature. “The idea was...there is a probability of what the next token will be, of what this representation is, of what the language that you're using is, of what the context window would look like,” Noland offers. “While those are the types of things that people understand better now, when you're having to talk to someone about using this tool at work, you need to be able to articulate how to think about what you’re sending back in response to being prompted. How you think about what Copilot is getting prompted with.” Noland suggests that conversations with design partners and early customers were something of a shortcut that informed Copilot’s launch messaging and early marketing materials.

More Resources: How to Incorporate Early Feedback Pre-Launch

Getting the Story Right

Important Learnings on Messaging:

  • Successful Developer Community Launches Empower Community Members: Understanding that Copilot would be a product for developers, Noland opted against catchy billboard slogans, preferring to make sure Copilot’s launch would put developers in the spotlight and give them opportunities to tell their own stories.
  • Objection Handling Is Different for Developing Spaces: When going to market in a relatively new space, such as AI in the early 2020s, it’s a good idea to consider baking objection handling from skeptical developers directly into your launch messaging.
  • Investing Early in Foundational Messaging Pays Dividends: Making early marketing investments into foundational exercises such as messaging and positioning helps validate your message and keeps it in close alignment with your product.

Noland’s approach to Copilot’s launch focused on empowering users, rather than trying to hard-sell products. “The way Kathy Sierra writes about in ‘Badass: Making Users Awesome,’ about how to make users feel awesome. We wanted to make sure our launch would let users tell that kind of story about themselves.” As a result, the plan was to launch with messaging that would emphasize how Copilot complements developers, rather than replacing them. The story to tell would be about how developers still play a crucial role by providing clear instructions and context for Copilot–a point that became a core element of the marketing story across the Copilot website and other marketing assets.

Noland concedes that even then, what we now know as GenAI was still very early–and as a result, there would be many questions about the role Copilot would play across the rest of the software development lifecycle. “But that’s another component of creating a successful launch,” Noland points out. “You’ll want to consider how the story you’re telling will have to cover objection handling, even if it’s for things that are unsolved across the entire tech industry.” The team had to position Copilot’s June 2022 technical preview launch for an innovator/early adopter type of customer–without the critical mass that AI coding assistants have since built up today.

Startups can also convey messaging and storytelling visually. “The brand design around Copilot was an important component,” Noland adds. “Any company should think about how it iterates on its brand visual design and marketing. We pulled visual inspiration from other sources of technology–including other major tech launches–and explored current color trends. An interesting example of this was reducing how much green is in the Copilot logo and icon because of the similarity to the GitHub merge button and green light signals.”

More Resources: How to Hone Your Early Startup Messaging

Early Launch Prep: Community, Promotion, Events

Important Community Learnings:

  • It’s Absolutely Possible to Have a Community-Based Product Promotion Plan: When launching a developer product, it’s not always necessary to separate traditional PR from community planning. Community influencers can promote your product while also bringing in new people.
  • Objection Handling Is Different for Developing Spaces: When going to market in a relatively new space, such as AI in the early 2020s, it’s a good idea to consider baking objection handling from skeptical developers directly into your launch messaging.

Again, GitHub at the time had a significant leg up on many other AI startups that may not have its established brand name, huge community, or PR reach. But Noland explains that she and her colleagues pulled as many of GitHub’s levers as possible, including its GitHub Stars champions program, which let the GitHub team demo the product to an extremely engaged community group for valuable feedback.

GitHub also looked to leverage the community by engaging its most high-profile members. Noland suggests that other startups going the closed beta route could offer incentives such as bumping up members’ waitlist status once they hit a certain threshold of referrals. Noland also looked for more-traditional, public relations-style channels to promote Copilot’s technical preview, with submissions of GitHub’s technical preview announcement blogs to HackerNews, Reddit, GitHub’s own content calendar, and its social channels.

If you can engage a community of developers, net-net you end up with more eyes and facilitate more word of mouth. So the more that you can also promote and give a platform to your biggest champions that don't have an affiliation with your organization, the more reach and trust you're going to have.”

Another tactic in play was identifying relevant segments for communities that were the best fit for Copilot at the time, focusing on languages such as Python and JavaScript–popular languages for users of VS code, the platform with which Copilot integrated. Targeting specific developer niches helped Noland then identify relevant use cases to showcase to that community segment, such as data processing and analysis.

Even though Copilot wasn’t specifically limited in which specific languages or for which specific developers it could be useful, it was important to be realistic of platform biases and developer population. Specifically, Copilot clearly had strong appeal to JavaScript developers–a large community of vocal developers who could do more for Copilot’s launch than any expensive Superbowl commercial would.

“If you can engage a community of developers, net-net you end up with more eyes and facilitate more word of mouth. Ultimately, that's really what you're going for,” Noland advises. “There's only so much evangelizing you and your brand can do for yourselves. There's so much more that individual people can do for you. So the more that you can also promote and give a platform to your biggest champions that don't have an affiliation with your organization, the more reach and trust you're going to have. Especially when you let them say what they are going to say and take that as feedback and as an opportunity to make them a co-designer of the product.”

Unfortunately, Copilot’s launch window coincided with the deepest throes of the pandemic, so its event options were limited. The company used large-scale events such as GitHub Universe to announce the technical preview and the general availability of Copilot, highlighting specific product features during the AI tracks. Given the size of GitHub’s user base, as well as prevailing health-and-safety regulations circa 2020-2021, the company didn’t focus on small local meetups.

You’re more likely to get someone to try your product out for a real, valuable, painful use case that people know. You’re a lot less likely to get traction with a ‘hard sell’ type of pitch about how great your product is.”

Noland concedes that a different event strategy might make sense for startups at earlier stages. “For a smaller startup, getting your first customer, or your first 10, is way more important than thinking about scale problems. So for smaller startups, I would likely try to start there, with what's close to you. What is cost-effective for your time, whether that’s a small event you sponsor, or an event for which you can apply to be a speaker. The best advice I can give in that vein for events is to think about how simply you can explain the type of use case for which your product is best suited. Talk about how you're solving this important problem and get empathy from that audience because hey, they probably experienced this problem too. You’re more likely to get someone to try your product out for a real, valuable, painful use case that people know. You’re a lot less likely to get traction with a ‘hard sell’ type of pitch about how great your product is.”

Other steps in the journey included user research and validation, using surveys and social listening platforms to understand how users actually perceived Copilot and its ability to save developers time. (GitHub later posted a blog sharing survey results.) The focus on community even involved bubbling up user-generated memes that poked fun at the occasional AI hallucination. In any case, Noland explains that the approach to early community work for Copilot avoided hard selling and focused on gathering feedback and assessing product-market fit. Conversations about customers’ willingness to pay, and for which features, informed business decisions such as product pricing tiers.

More Resources: Learn About How to Execute on Community and Promotion

Balancing Business Goals vs. Community Goals

Important Learnings on Working Against Revenue Goals

  • GitHub’s Sales Teams Used a Land-and-Expand Motion: Copilot was originally intended for use by individual developers, but could eventually spread across organizations that have enterprise-level requirements for security and compliance.
  • GitHub’s Sales Teams Focused on Highly Engaged Pilot Accounts: Understanding that GitHub’s sales teams had quotas of their own to make, Noland did what any good product marketer does: Act as a sales enablement partner, but advising sales to focus on highly-engaged pilot accounts and solicit feedback regularly to maintain relationships.
  • It Took a Village to Launch Copilot: Launching new products isn’t just work for product and engineering. Designers need to build websites, business executives need to set and meet realistic goals, and DevRel teams need to engage the community. Successful launches at companies of just about any size don’t just require delivering software–they often require soft skills.

To provide context, at the time of Copilot’s launch, the GitHub team already had thousands of employees and had to launch Copilot while managing its relationships within the larger Microsoft organization. At the time, Microsoft seemed focused on catering to enterprise customers with various Azure services, while GitHub continued to focus on relatively smaller engineering orgs (including teams at fairly established companies) and individual developers.

The ‘expand’ part of ‘land-and-expand’ came from advanced features inquired after by existing customers. People who are already customers that already have a relationship. And sales teams want to keep those accounts happy for renewal–so in those cases, you want to be able to say ‘yes’ as often as possible.”

The various powers-that-were had decided that Copilot would not have formal business licensing at GA. As a result, Noland’s team would primarily have to block and tackle with the internal GitHub sales team. Given that the earliest versions of Copilot were intended for use by individual devs or relatively small engineering orgs, it became clear that a top-down enterprise sales approach wouldn’t be a fit for a product that would primarily see use from, and get purchased by, its daily users. The sales team, which was accustomed to selling to enterprise customers, would have to take a “land and expand” approach of offering valuable services and add-ons that larger orgs expect, such as security, privacy protections, and data governance options.

“The ‘expand’ part came from those advanced features that would likely be inquired after by existing customers,” Noland recalls. “People who are already customers of ours that already have a relationship. And your sales teams want to keep those accounts happy for renewal–so in those cases, you want to be able to say ‘yes’ as often as possible.” To ensure all teams had what they needed to be successful, Noland embarked on a traditional campaign of sales enablement to inform GitHub’s sellers about the product’s features, how to talk about it, and how to handle objections, but also sought to partner with members of GitHub’s enterprise pilot program–which let sales teams nominate potential customers for pilot programs.

However, GitHub also recognized early on that there could be legal complexities involved in selling Copilot (the company has since launched a full Copilot trust center), so its legal department advised sales not to engage in extensive conversations on the topic. GitHub’s legal team was closely involved in addressing any concerns that came up in sales conversations to help the sales team understand potential challenges while continuing to maintain customer relationships. “And that's another thing that I would say is a ‘nice-to-have,” Noland confides. “I haven’t seen too many startups with an embedded legal person. At GitHub, not only for Copilot but across the product lines, there's an embedded legal person any time we need to change the way that something works or add new functionality we haven't accounted for–anything that changes data processing, especially as a company that people use as a vehicle for storage.” Microsoft has, since launch, also publicly pledged legal copyright support for Copilot customers as well.

Noland also recalls that while the product marketing team didn’t formally own any specific budget for the launch, many cross-functional teams were available to her for consulting, feedback, and old-fashioned horse trading. In effect, a surprisingly big part of the efforts behind Copilot’s launch was soft power and people skills–carefully managing relationships with people across formal reporting lines. “I was fortunate enough to have so many people at my disposal I could ask to prioritize or deprioritize specific items. So it was more like wielding informal authority. I would say, no matter what type of project you're working on, the earlier you can involve every single one of your stakeholders to let them know it's coming, the better.”

“They don't need to be involved in all of the check-ins at that point, but they do need to know that, for instance, in October, there’s a big project coming up. I was lucky enough to have close relationships with fantastic people in our design department (our website was built with input from the researcher team as well), along with our lead for business planning on pricing and packaging. I also built some relationships in billing engineering specifically because there were a couple of contingencies to consider. For example, we were adding a totally new product line that required a whole body of work that actually didn’t have anything to do with the [GitHub] product itself. I was also fortunate enough to work with GitHub’s DevRel team, including the amazing Martin Woodward, who was such a wonderful person to work with–willing to be involved a lot earlier whenever we were still operating with a lot of uncertainty. Sometimes, even in corporate environments, you find yourself having to figure out what you can reasonably do with what you have.”

More Resources: Learn About How to Hit Revenue Targets

Launching an AI Startup vs. a Non-AI Startup

In closing, Noland reflects on the differences between launching the more-traditional developer-first startups she’s worked with in the past, compared to an AI startup in today’s market–one in which developers may be understandably wary about AI products that overpromise and underdeliver:

  • Regulatory Considerations: Noland advised AI startups to be on top of emerging developments in AI regulation. Not only will the regulatory landscape potentially offer evolving rules–there’s also an opportunity to garner goodwill with customers by staying ahead of and ensuring full compliance with regulatory guidelines to provide peace of mind.
  • Setting Realistic Expectations and Clarifying Complexities: AI startups may face higher expectations due to the continued level of hype and high expectations. Aside from creating and shipping excellent products, AI startups can gain credibility by managing expectations around the complexity of modern AI by providing in-depth technical documentation and a clear comms strategy. It may behoove startups to be frank about not just AI’s capabilities, but also its limitations.
  • Security and Vulnerabilities: The current generation of GenAI suffers from well-documented vulnerabilities such as hallucinations, prompt injection attacks, and data privacy breaches, accidental or otherwise. Survey after survey after survey reveals that people don’t trust AI or companies using AI. AI startups must address security concerns and provide credible assurance of the safety of their products.
  • Exploring Niche Audiences: Some AI startups may cater to niche audiences interested in exploring unusual applications of generative AI. Understanding niche markets and identifying valuable use cases for them is essential to target customers in such spaces successfully.

However, as a GTM expert who has helped launch many successful startups, Noland ventures, “Broadly speaking, launching an AI startup versus a non-AI software startup–they’re about the same.” While AI startups may need the specialized knowledge of AI experts who comprehend the nuances of this rapidly-evolving space, there are no shortcuts to the foundational work of launching a startup, regardless of whether it’s going to sell an AI product:

  • Understanding Your Customer Persona: Regardless of what type of product your startup sells, you need to have a fundamental understanding of your target audience's pain points and use cases–which are effectively the language you’ll use to speak with them.
  • Marketing From First Principles: Both AI and non-AI startups rely on core marketing principles, such as effective messaging, building communities, and achieving product-market fit. Noland offers this advice to any technical startup of any kind: “Get your marketers in the room with the technical builders and start building your marketers’ understanding as early as possible. Otherwise, you’ll have to invest many more cycles in training them and educating them later.”
  • Building Trust: Establishing trust with your audience is vital for any startup. Startups can build goodwill with developer communities by being transparent about how their technology works and addressing potential concerns early.

Hear more of Alyss Noland’s story on the GitHub Copilot launch at her Speaker Series session.