How can you successfully bring an API to market? And what’s your to-do list once it’s launched?
My name is Nick Knuppe, Product Marketing Lead at Mollie, and I’ll be talking about a topic that’s very dear to me: go-to-market. More specifically, how to launch an API into a market (or several markets) and keep it there.
You might be wondering what I mean by that – “keeping it there” is all about driving initial market adoption and usage of an API. Adoption really means the successful competition and integration of an API by the customer, and usage means repeat API calls between systems.
Here’s the agenda for today:
- What is go-to-market?
- What does a go-to-market structure look like?
- Building a bullet-proof GTM framework
- When stakeholders are added to the equation
- Four steps to great GTM implementation
- The role of sales and marketing
- What questions should a GTM plan answer?
- How do you get a killer value proposition?
- How do you measure success?
- Closing the feedback loop
What is go-to-market?
This is an extremely hot topic verbalized across multiple departments, and it can take many shapes and forms depending on whether you’re a start-up, scale-up, or enterprise tech company. So, today, I’ll be talking about go-to-market in both a generalist context and a hypergrowth B2B context, including a little bit about how we do GTM at Mollie.
How do we define GTM?
According to the internet, “go-to-market or go-to-market strategy is the plan of an organization, utilizing their outside resources to deliver their unique value proposition to customers and achieve competitive advantage. The end goal is to enhance the overall customer experience by offering a superior product and/or more competitive pricing.”
I do think this definition is extremely irrelevant and out of touch with what GTM really is, so I created my version:
“Go-to-market is the overarching framework that details the key stakeholders, milestones, metrics, and deliverables a company cohesively follows to test and validate the market opportunity, readiness, and positioning of a product or service targeted at a predetermined customer segment.”
How do you structure go-to-market for an API?
So, now that we’ve explored the definition of GTM, at least in my opinion, how do you structure GTM in your world?
As we know, it can change in duration, structure, B2B, B2D, B2C… And I think understanding the difference between the different types of GTM that apply to your product or feature launches enables you to progress building out your GTM framework and educating stakeholders on how GTM is done (as well as the time required to execute it well).
At Mollie, we have three different tiers, namely to help manage expectations on when we require stakeholders’ input, and how much bandwidth the team has to deliver against the relevant timelines associated with the different product launches.
I would suggest you use high-level parameters to help determine the tiers of GTM that you have; what I find quite helpful is to use the following parameters:
- Audience cohort (who we’re targeting),
- Channels we’re reaching the audience on (are they owned, earned, or paid?)
- Stakeholders that we need to keep informed and consulted
- Outcomes (what can we expect? This includes metrics and measurements)
- Duration (how long the GTM will take from kickoff all the way to retrospective)
Building a bullet-proof GTM framework
So, what does a GTM framework look like? I’ve used an example of a Tier 2 GTM framework to help illustrate how it works at Mollie and how we use it to steer our GTM efforts forward.
The little black boxes are just sanity checks to make sure that everything is going smoothly and moving in the right direction. I haven’t added any timings to this image as it can vary depending on the type of product you’re launching – or, in this case, an API. These would be typical milestones that I would include.
If you start at the beginning and ideation phase, this is really all about determining the feasibility of an API. So, why do customers need it? What is the market demand or, at least, perceived demand? And how would we go about launching this?
As you move forward through the scope of your technical specifications or development timelines, you might be thinking that that’s not part of the GTM. But, this is an overarching framework that I’m sharing, and what you’ll need to focus on is the key points of validation and feedback when launching an API.
A key thing here is also understanding where you’re launching your API to, as your API is plugging into an external environment? What does that environment look like? You know, how is data being surfaced and visualized? This is something that’s not always considered.
What about when stakeholders come into play?
In my opinion, one of the most important things about GTM is stakeholder expectation management. It comes down to identifying who your key stakeholders are, which can be quite extensive.
After all, throughout any GTM, you’re really touching on marketing, sales, customer support, and customer success. You’re working with product engineering or revising the timelines. And what you want to do is understand the key learnings and hypotheses going into a beta test, and what you need to get coming out of that.
From the beta, I’d say one of the key areas is also understanding the approvals and green lights from legal and compliance. That’s an extremely important checkpoint, at least within fintech.
Because the last thing you want is to be going live or preparing for a launch meeting and they haven’t been included. The outcome isn’t pretty – trust me, I’ve been there before! You want to make sure that your legal and compliance or security and risk stakeholders are included early on.
A step-by-step approach to GTM implementation
I’ve given you a lot of food for thought, I’m sure, so let’s break it all down into an easier-to-understand approach.
When you look at GTM, there are four core phases:
In the discovery phase, I’ve identified all my stakeholders. Is the problem statement and solution clearly explained? Does everyone understand why we’re doing this? And what impact is it going to have? Have we clearly defined and sized the opportunities so that stakeholders know why we’re launching the products?
Which is the audience? What type of market share do we want to go after? What level of revenue attribution will this API deliver?
The second phase is validation. Beta tests aren’t always a requirement, but they add a huge amount of value when stress testing the product and future-proofing your launch material. Beta testing helps you learn if your customers resonate with the value proposition and if they understand the technical documentation.
How far do we go to help them understand how to design and visualize the user interface on their end to ensure that the information is being surfaced in the most optimal way?
The preparation phase means taking all the learnings from your beta testing and implementing them prior to your soft or hard launch stage so that your GTM material is airtight and your team is tracking the right metrics.
And, finally, launch and iteration. Your soft launch phase can be either single-market focus or multi-market, and we typically launch in one market to test the adoption. If everything is greenlighted there, we then roll it out across additional markets in a sequential manner.
The iteration part is focused on leveraging both the internal and external insights from your previous data points to help you make more informed decisions as your product adoption and usage start to grow.
The role of sales and marketing
Something that’s super important and we sometimes neglect or ignore is understanding the role of sales and marketing.
They play a crucial role in not only launching your API, but also driving initial market adoption and, more importantly, feedback and insights with supporting qualitative and quantitative data.
And these are where the feedback loops come into play – not just how critical they are in understanding how to establish product-market fit, but also ensuring that the insights your retrieve and distill are circulated with all your key stakeholders.
What questions should a GTM plan answer?
If you think about the types of questions that a GTM can and should answer, you need to be a little bit empathetic to your sales and marketing teams and understand what they do and how you can help guide them.
In regards to product marketing, what I’d typically ask myself is:
- How have we quantified the demand for a new product feature or market?
- Who are we targeting?
- What is our message or USP?
- Have we defined the right personas and decision-makers?
- Who are the key stakeholders in our GTM?
- Which customers are we co-launching with from our beta?
- What supporting product material do we need to create to have an impactful launch?
When it comes to the questions that our sales team would ask, I’d say the following:
- What material do we have to sell our product? How has it been localized?
- How have we defined the eligibility of our targeted customers?
- How have we forecasted the acquisition plan?
- What does customer onboarding look like? And how long does it take?
- What is our pricing strategy? How does it compare to our competitors’?
In regards to the marketing team, here are just some of the questions that need answering when it comes to GTM:
- When does marketing need to get involved?
- What are our marketing deliverables?
- What kind of content do we want to market our product with locally?
- What are our audience demographics and geographics?
- What supporting marketing do we need?
Once you’re able to answer all these questions, you have a clearer picture of who does what, when, how, and where.
Writing a killer value proposition
“Value proposition” is one of those terms like “paradigm shift” and “synergy” that started as a good idea but then were so overused that a lot of people don’t really understand them – and their importance.
A good place to start is how not to write a value proposition. In my experience, don’t create a value proposition based on internal biases or anecdotal feedback, as this is not representative of your customers’ needs or attractive to your customers’ intent.
So, try avoiding making baseless claims – and avoid making no use of data to back up your messaging.
I’d focus on three things:
- What makes customers’ lives easier?
- What are their pain points?
- What do they hate about their jobs?
Once you understand these, you need to align the pains and gains to the product features. In essence, you want to marry your offerings to the needs of the customers.
How to measure success?
This is all about measurements and metrics, and there are many of them to consider when launching an API.
I tend to start very broadly. For example, I categorize the different metrics that I anticipate measuring and treat this as an initial shopping list for myself and my data analyst. Usually, for an API, we focus on product performance (and what that really means is the “bottom of the funnel”).
The terms I like to use are vanity, sanity, and reality, which you may have heard before. And why I like using them is that, when launching an API, you want to focus on the reality, and maybe a little on sanity too, so that we know the kind of adoption we’re getting. What’s driving adoption and what’s inhibiting it?
And this means understanding what a customer is seeing, why they’re dropping off, what’s extending their time to integration, etc.
Some of the metrics we use for this include revenue attribution per API call, which is quite technical and hard to determine, and the sales team’s close rate.
Closing the feedback loop
So, you’ve launched an API and you have early adopter signals that are looking promising – but when do you close the feedback loop? And who do you close it with? This is a lot easier said than done.
You have feedback loops throughout your GTM lifecycle (you can have feedback after beta, after the soft launch, after release, etc.), as this is an ongoing process. So, you must determine what you do next once you have this feedback, which includes how you’re optimizing your product, and how you’re iterating in different markets.
In short, launching an API into a market means defining the problems and the opportunities, building your stakeholder matrix, validating your message and material, and planning for a sequential phase rollout.
Finally, a bit about me.
My career in technology
I’ve worked across various consumer tech companies where I’ve been fortunate enough to be part of and lead incredible agile growth, brand, and product marketing disciplines. I have a decade of experience in both SSA and EU regions, and I’ve built and scaled Tencent Africa’s full-service marketing team.
I oversaw a portfolio of mobile products: fintech, music streaming, social communications, and video streaming. I’ve also planned, managed, and led over 60 GTM plans for SaaS, eCommerce platforms, and more.
Outside the office, as much as I like to eat, I love exercising, and believe that both are an important part of how we remain sane whilst working in hypergrowth environments – and some sleep is probably important from time to time too.
Now, a bit about Mollie. We’re a European online payment service provider that reduces the complexity of payments for over 120,000 customers across Europe. We’ve recently raised $800 million in Series C funding, which will help diversify our product offering, accelerate our Pan-European expansion, and solidify our positioning as the most-loved payment service provider in Europe.
Join our developer marketing community on Slack to stay up to date with the latest on marketing, and to chat with other marketers.