Apr 18, 2023 5 min read

6 Steps To Launch Your API Product MVP (Part 2)

Part 2 of our series re: areas of focus to get your API product to market quickly and navigate around internal barriers that typically delay the process.

In our last post, we outlined the first two of six key factors to address to get to market as quickly as possible with your new API-based product offering. As a brief review, the last article covered the key tasks in Product Management (Pricing & Packaging) as well as Commercial Enablement & Readiness.

Today we will tackle the remainder of topics in the areas of security, legal and compliance, as well as ensuring your sales/CS, marketing, and support teams are ready to support your MVP launch.

Security, Legal, Compliance (SLC)

❗

Of all of the areas we will cover in this two-part article, these are without a doubt the items with the greatest potential to kill your project before it gets off the ground.

Navigating these areas successfully relies heavily on following a key suggestion from the first article, which is to first build the API MVP collaboratively with your first customer. Let’s break down each area to see how this strategy helps navigate potential obstacles in SLC.

Security - first, let us acknowledge that an improperly secured API can be extremely damaging to a company’s brand & reputation, so we are in no way advising you to short-circuit the process of properly designing and securing an API. However, by doing a soft launch of your API with a single partner, you can perform the API security process in parallel with user testing as opposed to considering it as a gate to launch. During the development & testing phases, limit API credentials tightly to your single partner and whitelist the partner’s IP addresses allowed to access the API if the situation allows it (which it almost always does).

💡

Be sure to get your security team onboard early with your plans. In almost no cases is it beneficial to surprise your security team with an approval request at the last minute.

Our most successful clients partner with their security team from the earliest planning stages so that security input can be incorporated at the outset as opposed to requiring time-consuming changes post-development. Lastly, ensure that the security team understands the scope of the API’s exposure during the design & build phases as this typically eases the security review considerably during the early stages.

Legal & Compliance - similar to the discussion re: security, building and soft-launching with an existing partner will save you considerable time in the legal arena as well. Although this is not a silver bullet that will avoid all additional required legal work, working with an existing partner means that there is a master contract on which the new work can be based, which will save you weeks or months.

Using this strategy, the thorniest areas like indemnification and limitations of liability will already be agreed, and you can work on a simple statement of work basis rather than requiring an entirely new agreement to get your project off the ground.

Similarly, most master contracts will include terms & conditions defining each party’s compliance obligations. These can also be incredibly time-consuming and painful to negotiate. And while your new offering may require tweaks to the compliance terms in your master agreement, worst case, these will require modifications to a framework already agreed, and best case, you may be able to leverage your existing contracts exactly as is.

Sales, Marketing, Customer Success & Support

We’re admittedly bundling several of the 'six steps' into one with this advice, but as it turns out, they all require very similar strategies in the initial stage of your product launch. Essentially, the advice in each of these areas is to take the burden from the organizational towers responsible for these areas into the project team in the early days, and look externally for help at a later stage.

Let’s take them each in turn:

Sales & Customer Success: While it absolutely makes sense to inform sales/CS of the work you’re doing with one of their accounts, you should not pass any burden of managing the project or customer interaction to these teams. Doing so in most enterprises will quickly devolve into discussions about the lack of time to allocate from outside groups and lead to protracted negotiations about how long you have to wait before these groups can support your project.

Marketing: The key in marketing planning at this stage is to make the team aware of the project, but not to ask anything from them. You will make your marketer’s day by telling them that you won’t need investment of time until you return with a happy first customer. That customer will be willing to serve as a testimonial and share the benefits they’ve received from partnering with you on the launch. You can’t make it any easier than this for your teammates in marketing. (it is helpful to get a soft commit from your marketing peers at this point to prioritize marketing for you once you have a customer onboard if you can, but if not, leave this pursuit for another day)

Support: For some enterprises, planning for customer support of a new product launch can be an incredibly painful affair. It requires writing call scripts, FAQs, escalation matrices, time zone coverage documents, document translation, and much much more. And while all of this makes sense in the long term, it can be an absolute project killer in the pre-launch phase. All of that work costs money, and makes the business case for the initial launch that much harder to get approved.

For this reason, we advise all of our clients to assign the responsibility of support during the initial phase to the API project team. After all, the last thing you want at this phase is feedback on your product to be filtered through anyone else before reaching you.

It is important to make customer feedback as easy as possible at this stage and to open up whatever means of communication your partner prefers (Teams, Slack, Email, etc).

Lastly, to give yourself a shortcut on the process to formally hand off product support in the future (i.e. at public launch) to its rightful owner:

💡

Ensure that you assign someone on your team the responsibility of capturing all customer questions and documenting responses. This will form the basis of your FAQs and customer service call scripts which will save you considerable time down the road.

Platform & Technology Readiness

Although the focus of this 2-part series is on addressing the business requirements of an API product launch as efficiently as possible, we would be remiss if we did not briefly mention technology readiness. As this is a lengthy topic all on its own, we have created a dedicated post to cover these considerations in our API Monetization Buyer’s Guide.

If you have questions from the content we’ve covered above or about an area we did not include in these guides, please feel free to connect with me on LinkedIn and I’d be happy to help.