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 previous post, we outlined the first two of six key steps 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 remaining topics in security, legal, and compliance and ensure 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 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 instead of 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 regarding security, building and soft-launching with an existing partner will also save you considerable time in the legal arena. 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 upon, 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.
Most master contracts will include terms & conditions defining each party’s compliance obligations. These can also be incredibly time-consuming and painful to negotiate. While your new offering may require tweaks to the compliance terms in your master agreement, in the worst case, these will require modifications to a framework already agreed upon. In the best case, you may be able to leverage your existing contracts precisely as is.
Sales, Marketing, Customer Success & Support
Let’s take them each in turn:
Sales & Customer Success: While it makes sense to inform sales/CS of your work 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 At this stage,the key in marketing planning 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 an investment of time until you return with a happy first customer. That customer will be willing to serve as a testimonial and share their benefits of 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 for a new product launch can be a harrowing affair. It requires writing call scripts, FAQs, escalation matrices, time zone coverage documents, document translation, and 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 support responsibility 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 essential to make customer feedback as easy as possible and 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:
to capture💡 Ensure you assign someone on your team to capture all customer questions and document responses. This will form the basis of your FAQs and customer service call scripts, saving you considerable time.
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.
