Sign in Subscribe

How to write a go-to-market plan

How to write a go-to-market plan

You've built your market requirements document and your growth plan. Now you need to build your go-to-market plan. What elements go into a solid go-to-market plan? I am a big fan of the "write it down" methodology, so my marketing plans are usually long, detailed documents (as opposed to slide decks or other formats). In my marketing plan documents, I typically add the following:

  • Objectives and Key Results (OKRs)
  • Marketing dashboard and measurement
  • Launch calendar
  • Organic growth
  • Paid acquisition
  • Content plan
  • Community program
  • Events program
  • Comms plan and analyst outreach
  • Partner program and business development

Let's dive into each of these, as well as the quantitative measures for each element of the plan.

Objectives and Key Results

In your Market Requirements Document, your Product Marketing team has outlined several important aspects around which you will align your entire marketing organization. You can copy the summary into your go-to-market plan and reference the drill-down detail in the MRD:

From here, you want to lay out the specific objectives of your go-to-market plan. Some examples could include:

  • Be in the top 3 of vendors in my category
  • Win enterprise credibility
  • Launch the next version of our product in April

These top-level objectives are best when shared broadly across the organization, particularly with your product/engineering and sales teams.

Each objective would then have specific measurable key results that you can anchor around. These key results would differ from team to team, though the marketing and sales organizations should probably share some of them. Here's an example of two key results for the "Win enterprise credibility" example from above. The first one is one that is likely specific to the marketing team, while the second is one that would be shared with the sales team:

  1. Win enterprise credibility

    • Launch a webinar series aimed at technical decision makers in large companies

    • Win 20 new medium-to-large customers in H1

How you achieve the objectives and key results you've defined is the crux of the go-to-market plan. Thus, first get organizational alignment on your objectives, then define the key results that make sense for your team (taking note of those key results that are dependent on other teams), and finally flesh out your go-to-market plan to help you achieve your OKRs.

Marketing dashboards

A big part of your marketing plan needs to be how you will measure your performance. Always look for a way to measure results, not merely output. It's not enough to say you "wrote 10 blog posts this month." How did the blog posts perform? Did they drive leads, conversion, or expansion.

I like to use the ACES framework when designing marketing dashboards:

  • Awareness. This is the most blunt of all metrics and should cover many things:

    • Content: how many website visitors did you get in the last 30 days, where did they come from, and how long did they stay on your site?

    • Events: how many leads did you capture at your events, how many community conversations did you have at your events, what is the open rate on follow up emails, and what are the click through and conversion rates on those emails?

  • Conversion. How many people signed up after viewing information on your website? Ideally your dashboard will enable you to cut this data by lead source, content type, content author, event, etc.

  • Expansion. How many people expanded on their use of the product and by how much? What is the lifetime value of each customer cohort you're measuring under the "Awareness" category? What you're looking to understand here is the long-term effect of each marketing channel.

  • Schedule. I also try and lay out all my marketing activities in a calendar. If you see a spike in signups in the middle of the month and it's not easily explainable by an event, campaign, or viral content, then what else happened? What was your social media activity like? Did someone prominent post about you? Tracking these activities as they come in can be helpful when you try and look back and evaluate the efficacy of each marketing channel.

Launch calendar

A big part of your "Schedule" (see above) is understanding your product launch calendar. What features, services, and products do you expect to launch in the next 3-12 months. A product/engineering team that can't give you a solid outlook for the next quarter or a squinty-eyed vague outlook for 6+ months out needs to get in gear.

Marketing, especially in a product-led growth organization, is highly dependent on an internally visible and accountable launch calendar. Insist upon it.

Organic growth plan

Organic growth through search (SEO) has numerous advantages. Obviously, it costs you nothing, and that's always a win. But more than that, when someone is searching for a term, sees content you've produced as potentially answering their question, clicks through, reads your content, and then decides to sign up, you can correctly assume the customer is highly qualified for your product. You've successfully answered their question (or, at least, piqued their interest).

As part of your Market Requirements Document, your Product Marketing team did a full keyword analysis. This keyword analysis should take into account the customer archetypes or personas, their biggest pain points, and the things they most frequently search for to alleviate or address those pain points.

In your go-to-market plan, you need to identify the content topics that would successfully answer questions posed by the keywords you've determined are most important to your potential customer. Laying out these content topics, assigning owners and timelines, and managing timely delivery of the content will help you.

If your site doesn't have much domain authority yet, you'll need to obtain that authority through backlinks. The best backlinks are themselves organic: people love your content and share it on their own (high authority) blogs, social media accounts, or forums. Thus, a big part of your SEO plan is to identify the key influencers to whom you will share your content. Influencer marketing for developers is far different than it is for consumer goods. I'll cover some of my favorite tips and tricks in a future post. (listen to this podcast on Link Building)

From my experience, I know that approximately 30% of developers block ads. That means that a significant majority of developers do not. Paid acquisition is a good strategy once you have everything else in this document working. They are a good way to juice your results in the keywords you find most valuable, provided, of course, that the keywords have sufficient search volume. I'll write some of my thoughts related to paid acquisition in a future post, but here are some top-level observations:

  • Non-branded keywords will perform better than branded keywords. This means keywords that are generally about your product area (e.g., "cloud databases" or "data pipelines") will attract more clicks than keywords about your company, which no one really knows about or is searching for.
  • Great content (see below) is the key. Building great content that can inform and entertain developers will be the foundation on any paid acquisition program. Great content includes benchmarks or side-by-side comparisons, technical deep-dives, how-to-guides for complex topics, and so on. Build ad campaigns around your great content.
  • Retargeting is magic. If you've built phenomenal content, go all-in on retargeting. This enables you extend the impact of your paid acquisition.

Jeff Bezos famously said that "advertising is the price of a bad product." And I wholeheartedly disagree with him. Paid acquisition can be an immensely powerful add-on to a formidable marketing plan.

Content plan

Content is the spine of my marketing strategy. Other marketing approaches may take on a heavy event focus, a heavy paid acquisition focus, or perhaps even a heavy community focus. But for me, I place content front and center.

Let me explain why I put such an emphasis on content. Suppose you were to spend $200,000 on a booth, staff T&E, and giveaways at a major trade show. It's fairly easy to hit this budget at an event like Kubecon or AWS Re:Invent, for example. In every booth conversation, you will want to direct the attendee to a technical resource on your website or hand them a printed data sheet. As you scan badges or obtain business cards, you will want to follow up quickly after the event with resources and other materials. Having pre-built content makes the whole event-driven marketing approach flow. Thus, content, regardless of your appetite for content marketing, is the spine of your marketing plan. Everything emanates from great content.

Now, the first key to writing great content is to align it with core objectives of your business. Marketing is a heavily matrixed function, and input from sales (what do you need to sell the product?), product (what features and benefits should I be highlighting?), and customer success (what is the "aha" moment customers typically see in the product? What are the areas I should avoid discussing?) should drive your content plan. Your OKRs should mirror this input, and your content should align with those objectives.

The second key to writing great content is to reuse and repurpose content everywhere. If you put the effort into a strong blog post, record a video walking a customer through the salient points using your product, turn the blog post into a conference talk and submit it for CFPs at conferences, create a social media mini-campaign out of the main points made in the blog post, and so on. Don't let great effort go to waste. (listen to this podcast on repurposing content)

My content plan consists of the following:

  • Content bill-of-materials. We typically use a work item tracking tool or something like Airtable to manage our content list. Anyone can contribute content ideas and they go into our backlog. Content that is being actively written goes into our in-progress pile. We also track content that is backlogged and finished. Your content BOM should be constantly updated based on input from sales, product, and customer success.
  • Samples and sample code. Explain how to use the product. While this is great content for docs, I do like to elevate samples to the blog provided it's in the context of a salient use case.
  • Benchmarks and side-by-side comparisons. I'll cover benchmarks in detail in a future post, but I always abide by this simple mantra: benchmarking, not benchmarketing. Benchmarks for developer-focused products should always be honest and written with integrity. Describe the circumstances under which a competitor is superior (hint: use this to deposition them, for example: "Competitor A is ideal for low-load, low-intensity scenarios.") alongside the myriad ways in which your product is superior. Integrity is the single greatest currency of developer marketing and use benchmarks to establish your integrity as an organization.
  • Solution content. Solution content describes the categories of use cases and scenarios where someone would use your product. This should be a direct consequence of your positioning and messaging, and should ideally reflect the ways in which your current customers make use of your product. I also covered in my growth marketing post why solution content can be useful to gather signal for a digital marketing program.
  • Starter Kits. I always align Starter Kits around key solutions. Solutions help you articulate the key categories of customers for your product. Starter Kits provide technical assets that help customers go from "Hey, I think this product can be useful to me" to "Wow, I completed my first project and it really is useful!" There are many ways to create Starter Kits. Some people like to have GitHub repos with fully reusable sample applications that can be cloned by developers. Other people like to turn Starter Kits into tutorials and build end-to-end getting started instructions for how to use your product (my preference). Still other people like to use Starter Kits to wrap a bow around a compendium of content you've already created. No matter the path you've chosen for yours, make the decision to align them to your solutions. (pro tip: Starter Kits are fantastic assets for your sales team to use in engagements!)
  • Case studies. Social proof is critical. Showcase your best customers with case studies. Organize the case studies so that they reflect the solution content you're also creating. I like to write what I call "A-side" and "B-side" case studies (this is a reference to records, an ancient form of communication through music). A-side case studies are marketing content and very useful for your sales organization (especially case studies that are also recorded as video customer interviews). B-side case studies are technical interviews/Q&As with customers, and often include architecture diagrams, sample code, and best practices. If you're in the very early stages of your company, focus on B-side case studies. "Grow up" to A-side case studies over time.
  • Whitepapers and e-books. Not all businesses can benefit from e-books (a well-designed compendium of your best content). Typically, these are used as part of the sales process or as a call to action from a digital campaign. I am personally morally opposed to gating content by requiring a prospect to supply contact information before downloading, but you do you. I think developers abhor that behavior. Regardless, a campaign where someone can download an interesting resource fits my Help First mantra and can be an effective tactic.
  • Security, reliability, and other documentation. At some point, you will need to prove yourself. The exact moment will differ for all organizations. A platform or database company will need to establish its security and reliability bonafides early, while an SDK or similar project higher up the developer stack may not have to for some time. But be prepared to explain your security posture and your process for obtaining the highest level of reliability. If your industry requires certifications, write white papers that explain how you've achieved said certifications.
  • Documentation (information architecture + organization). I'll write a future post on developer documentation, but I will say this: developer documentation represents your single most effective growth vector. Developers will often skip past your beautiful website and click on "Docs" in the top nav. They'll peruse your documentation for several pages before deciding to stay or bounce. Your documentation must paint a picture for the developer of how your product will be part of their workflow and what value they will derive from its use.
  • Sales enablement. It is vital that you connect with your sales organization and get a good handle on the types of content they require. One of my beliefs is that every asset the sales team uses should also be available for customers to obtain on their own. However, the format may be different. For example, a first-meeting deck may cover a number of topics that you could cover on your website in the About Us, Why Us, and Products pages. In addition, there may be assets, such as white papers or case studies, that the sales team requires that could be hosted on your website. Some sales managers love to send PDF attachments, while others prefer to link to content online. Regardless, the content may be the same, but the format may differ.

    One other thing about sales enablement worth mentioning: it's important for marketing to facilitate periodic training sessions for sales teams. This training should cover product enhancements, as well as positioning and messaging, available assets, upcoming campaigns, and upcoming events where you will have a presence. I typically place this function in the Product Marketing team.

Community program

Any great product has a loyal, vocal set of users. Building mechanisms that enable users to talk to one another, share best practices, and provide feedback is critical to the success of any developer product. Here are some tips on building a great developer community:

  • Help first. Focus on helping developers solve problems instead of selling product. I cannot emphasize this enough. Help developers be better at their jobs. Selling your product comes later. Your greatest currency in developer marketing is your integrity. Build that integrity and credibility.
  • Build more than your own community. By all means, launch a Slack or Discord (see my thoughts below). This will be where your new and existing users (people who are already aware of you) will be able to get their questions answered. But in order to use community to drive awareness, you need to be present in other communities where developers already congregate. Identify those communities and participate actively.
  • Identify the key technical influencers. These are folks who write technical blogs about your product area, or are highly regarded open-source contributors. Get to know them, find out how you can help them.
  • Community participation comes in many flavors. Sometimes it's answering questions in online forums. Other times, it's contributing to an open-source project. Still other times, you may want to volunteer at a meetup or event. Think about all the ways you can help, and then jump in and do the work with a Help First mindset.
  • Be authentic and technically credible. Don't do unnatural things to your community. Your primary interactions with the community should be technical in nature, not marketing. For example, don't ask people to Tweet your product announcements. Simply share announcements in your forums and trust that your most active users will share on your behalf.

Every developer-focused company wants a community, but most devolve first into thinking about the software on which the community is based. Make a decision quickly and don't belabor it as the true magic of a community isn't the software, but rather the vibe. Here are my thoughts (based on hard-won experience) on types of online communities you can launch for your product:

  • Slack or Discord. Both of these chat-like tools are inherently popular these days for developer communities. They have a real-time feel and they are easy to "police" behavior. There are tools available for managing a Slack community, and for automating messages and other interaction that make the community seem more vibrant. The big drawback of the Slack/Discord option is that the content isn't indexed by Google. And, in the case of Slack, you have to pay (and depending on the size of your community, a sometimes substantial amount!) in order to keep an archive of questions.
  • Forums (Discourse is my favorite). Forums enable you to host conversations about your community and product online. They lack the real-time chat-like feel of Slack or Discord, but on the flip-side, the content can be indexed and searched by Google. Discourse is easy to customize and use.

Remember, with online communities, make sure you're not creating a graveyard:

  • Answer questions immediately. Do not let questions linger. A community that "seems dead" is dead.
  • Promote developer conversations. In short, don't answer TOO quickly! Enable your best users to answer questions before you jump in.

Finally, reward your best users. Send them swag, invite them to meet with your leadership team, etc. And, by the way, your best and most active community members are often fantastic Developer Relations hires! At every single company I've been at, our best Developer Advocates started out as highly active community members.

(see my post on earning a great developer community.)

Events program

Events are always controversial. They are expensive (both from a cash outlay point of view and a T&E point of view). They are difficult, if not impossible, to measure. And to many in an organization, they can seem like boondoggles.

At the same time, events are powerful. They are a super-concentrated gathering of your best potential users. A phenomenal opportunity to drive awareness with people who are more than likely required by their own management to report back on everything they saw at the event.

So, with that, I do recommend sponsoring events, earning speaking slots at events, and attending events as delegates. But I have a few internal guidelines as a Developer Marketing executive that I consider before approving decisions to attend an event:

  • Event sponsorships can be expensive. You typically receive some kind of event presence: logo on slides, public thank you from the event organizer, a booth or table, and so on. Evaluating the ROI of a sponsorship is certainly an important part of the equation. For example, if you spend $50,000 for a booth, will that booth generate enough leads that turn into business to cover the sponsorship + travel costs for your team? (in technical terms, will your CAC make the event worth it?) Your teams need to justify this expense. If you choose to go the booth route, staff the booth with a mix of Developer Advocates, engineers, and customer care personnel. Make sure you get buy-in and commitment from across the organization. Booths are great ways to expose people across your company directly to customers.
  • Speaking slots should be earned. Whenever you get a sponsored speaking slot, it's usually positioned at the ass-end of a conference: late Friday afternoon, when people have already left. Sponsored speaking slots are usually a waste of money if you're a big company (I used to "donate" them to up-and-coming and diverse speakers). They can be useful if you're a startup. But more powerful than a sponsored speaking slot is an earned speaking slot. Identify the conferences you are confident are full of your target customer, and submit as many CFPs (calls for papers) as you can. Organize a CFP party within your company with your engineers and customer care people, and build out a set of titles and abstracts (and speakers willing to deliver them). Submit them liberally throughout the year.
  • There's value in simply attending a conference. Send your loquacious, fun engineers and Developer Advocates, give them a modest budget to pick up dinner and bar tabs, and let them go network the heck out of the event.

Oh, and don't sleep on Meetups! Especially if you're a remote-first company, you can easily send your Developer Advocates and engineers to meetups. I want to write a separate post on Meetups as I think they're terribly under-appreciated in our industry, and something that I did a ton of early in my career and derived tremendous value from.

Comms plan

Comms is complicated. For most startups, simply getting the TechCrunch or Venture Beat "we raised money" post is the high water mark. If you're a big company, you have dedicated teams for Comms.

I want to focus on some advice for small companies:

  • Journalists are not the gatekeepers they used to be. Your Comms strategy needs to be part of your Community strategy. Focus your Community efforts on identifying technical influencers. For your Comms efforts on identifying industry influencers: podcasters, YouTubers, etc.
  • Podcasts and YouTube are very helpful. Most podcasters are always looking for interesting guest speakers. Do you have any luminaries on your team (perhaps your Founders?) who would be interesting guests? Your Comms approach should center around identifying who the most influential industry people are for your product, understanding the kinds of topics that interest them, and working within your team on pitches to join the influencer as a guest. (the tail-end of this podcast on link building has some great advice on how to approach podcasters)
  • Social media and Comms are interlinked. Combine the efforts or co-locate them organizationally. Working on driving awareness and reach through your social media accounts is critical. Don't be afraid to be fun (even, boring, corporate Microsoft has a TON of fun with their social media presence!)
  • Analysts (Gartner, etc.) are rarely worth it for startups. As soon as you raise money, you will be bombarded with opportunities to meet analysts (i.e., pay them money to speak with them) and submit for programs such as "Cool Vendor". The time sink is enormous. The analysis you'll receive is often too blunt to be use for a startup that is constantly evolving and finding product/market fit. You can get far more useful and actionable information by doing your own research and meeting with customers, and the impact of you, personally, meeting with customers is going to be far, far greater than you reading a report of someone who met with customers.

Partner program and business development

You'll invariably get chances to do "co-marketing" with other companies. This is going to be a tempting and difficult choice. For example, a company somewhat adjacent to yours may propose working on a joint case study or a blog post. Your organization, which is moving very quickly and constantly evolving its own marketing program, and this other organization, which is also moving very quickly and constantly evolving its own marketing program, will need to find time to work together.

Never once in my life have I seen this work as planned. If content is ever actually produced, it usually quickly becomes an afterthought. Startup businesses evolve too quickly to take on dependencies like this.

The one exception could be if you're a business that by necessity works closely with third-parties. For example, you could be a data pipeline company that integrates with other data sources by design.

But even in this exceptional case, why waste time working with other companies? Just write the content yourself and once it's been written, tag the other company in your social media posts, link to them in your blog posts, and so on. Maybe reach out to the other company ahead of posting and give them a heads up. All of these things will result in much faster execution. And speed is the name of the game at a startup.

As you grow, you'll want to put in place substantial business development effort. I'll cover this, and my experiences in BizDev, in a later post.

Summary

Building a go-to-market plan requires diligence and planning. Knowing your target customer well, as defined in the Market Requirements Document, will help you home in on the right set of tactics to include and exclude from your plan. Above all, remember this: all plans invariably fail. Building a great real-time dashboard will give you the intelligence you need to evaluate and adjust accordingly.