GTM strategy for API as a product
Application Programmer Interfaces (API) have become ubiquitous. API’s provide programmatic access to functionality on the user interface. 3rd party developers have leveraged these API’s and built very powerful applications. Examples of API’s could be a company like Stripe building API’s for payment processing, Twilio building API’s to send SMS to a phone. An example of API usage would be Lyft using Twilio’s API to notify the customer that the ride is arriving. These API’s hide a significant amount of complexity behind a simple interface but for a SAAS application needing payment module, they just need to integrate with a Stripes API instead of figuring out the nitty-gritty of payment gateways. Similarly, for a company needing to notify a user via SMS, they can just use Twilio API and not code for different mobile networks.
This post is not about building API’s or programming to API’s -- but rather how to bring these API’s to market and gain adoption. As a product owner, you have identified a pain point and have engineers building a solution to it. While engineers are busy building the API’s, you need to think about taking this product to the market. Depending upon the product, the launch strategy is aimed at multiple goals addressing a pain point. Example pain points could be getting adoption, increasing revenue, reducing costs in a certain time window. The launch strategy can be thought of as a phased approach with the aim to get the product adoption.
API Launch Phases
- Plan
- Execute
- Measure
- Iterate
1. Plan
This phase focusses on planning the launch. It all starts with identifying the user. As part of the user identification process, the product owner works with internal stakeholders like Marketing, Sales, Customer Success, Engineering, etc. The success of a feature launch depends on how a cross-functional team aligns, plans, collaborates and owns it. Planning is just a beginning which can help smooth execution of the launch.
Here are the common high-level plan steps
Answer WH questions
This phase identifies steps for the API rollout
a) Who?
Identify users/partners: The First step to begin planning is identifying users.
This is the key step for a successful launch.
- Know who your users are? For example, B2B APIs users might be enterprise partners, developers building applications at those partners. For B2C, users might be end consumers, app developers.
- Understand their needs. Solve their pain points. Answer questions like what do they need to integrate the feature seamlessly ensuring a good experience. Make them successful and they will work for your success
b) What?
Define the launch Objectives/goals. This is critical to gain alignment across cross-functional teams to stay focussed towards the goals. It also helps in setting up metrics, knowing what to measure and hence confirming the success of the goals set.
c) When?
- Timelines: When are you targeting to launch? What are the sub-phases of the launch? When are the deliverables and milestones expected to complete across all the teams contributing to the launch?
d) Why?
Purpose of this feature/change/launch
e) How?
- Plan and gain cross-functional alignment on launch steps from a user’s perspective.These steps focus on how external users would see this feature rolling out. Following answers should be answered in this phase-
Q: Will UI launch first or API?
Q: Will it break existing user’s flow?
Q: How does it impact existing users?
Q: Is it targeting a certain set of users?
Q: Do we roll this out to set of users who would test/validate the rollout plan for a feature?
- Layout plan of action for all the collaborating cross-functional teams and ensure Program Manager/Project manager understands the action items, ETA’s, owners and dependencies. Create trackers as required.
- Call out risks and mitigations
- Gain alignment by collaborating with Engineering, Security, Legal, Business, Marketing, Sales and Customer Success teams. You will have to interact with the above teams to ensure you are addressing security/legal requirements, align with Biz Dev, Sales, Marketing and have a bandwidth from these teams during the launch. Each team might have a more detailed sub-plan for the launch. Few examples are as follows -
---- Communication plan for different category of API users. The content should focus on integration, education, marketing, training, and use cases using various platforms like documentation, training videos, emails, website banners, Marketing Ads, press events, etc
---- Plan to roll out updated legal terms and conditions to existing partners/users.
At the end of the planning, all the internal teams should agree with the launch tracker as below-
Define Success Criteria/Measures
It is essential to define what success means to both the stakeholders and the end-users of the new deliverable. If those involved in this launch cannot clearly communicate their expectations from the launch, then we should ask why are we launching. In order to gain alignment and common understanding to work on this launch as a team, success should be viewed from different perspectives.
This step involves laying out metrics to track product adoption, end-user satisfaction and includes defining the measure and building/acquiring tools to aid in measuring. Measures can be defined as Sales Targets, Time required to respond to a customer issue or a performance SLA for an API. Criteria should be measurable unequivocally. You may have a quality control setup to ensure that the quality measured meets the expectation. Logs, performance dashboards, usage dashboards, and monitoring tools should be set up. This may also involve setting up alerts on the measure that appears to be unexpected.
2. Execute
Once the plan is ready, and all the cross-functional internal teams are aligned on the plan, we have action items, timelines, and owners for each of these. Now comes the role of project manager/program manager who has to ensure that the above action items are on track with given timelines and hold the owners accountable for the planned action items.
There may be few action items that may go undiscovered in the planning phase in large projects. These action items should be added as they are discovered to the plan. Any material change to the timeline should be communicated immediately to impacted parties.
Apart from the steps discussed in the planning phase, it is important to communicate your progress if you are a contributor to this launch. Having milestones in the plan and updating your team with completed tasks, any blockers/achieved milestones, delays in achieving milestones, etc is essential to keep the project on track. Usually, it's a good idea to keep the project manager in sync with your progress via weekly/daily syncs. The project manager can communicate the overall status to the cross-functional to bring attention to quick wins, blockers, newly identified risks, etc.
3. Measure
This phase focuses on monitoring the launch. This involves measuring the success criteria and evaluating if the launch is having the desired effect. A key to ensuring execution is staying on top of results, it is important to evaluate what's working and continue the execution as per the plan and/or enhance them to boost performance. With failing results, determine what doesn't work and make immediate adjustments to prevent further deterioration.
Results can be driven either by the measures set in the plan/build phase and/or by getting user feedback. The measured results feed into iterate to course correct as needed. I personally feel this step should be cohort analysis of all the measures set at the time of planning by different teams. The marketing team may have different measures set up vs and Engineering team. Monitoring/analyzing the measures but reporting what really matters is the key. A product owner with the team should plan to measure all possible metrics, however reporting on all of them could be a bit noisy. So, it is important to report on metrics that matter to the success criteria/goals set.
4. Iterate
Launching a product is not the end. It is just a beginning to maintaining and improving a product that is used by users. This phase involves adding new features, deprecating, migrating and/or accommodating customer/user’s feedback to ensure it does one or more of the following-
- Reduce their pain points
- Improve their lives
- Address their concerns
- Improve adaption
- Increase the revenue
- Is up to the mark of competitive market analysis
One of the ways, the scope of an iteration comes from the above step(Measure) which can be either looking at your support queue and/or error metrics. An iteration can be as simple as updating the documentation to as complex as improving the performance of the service and/or adding a new feature and/or migrating users to new API.
The one factor that separates the success stories from the failures is the speed of their iteration cycles. Organizations that succeed have found to build an excellent system in collecting data(measuring) and making an informed decision by acting on it with speed. This will also keep you ahead of whatever your competitors do.
Special thanks to Averie Wong and Justin Kominar for reviewing the draft.
Helping Enterprises Scale API Programs with Observability, Security & Governance
9 个月It's been a few years since this was posted, but I think it's especially relevant today. From the business side, we've seen an evolution in the teams responsible for driving API's as Product initiatives. For evaluation, planning, and implementation, you may see teams spanning Product, Engineering, and DevOps. For product delivery, we're seeing more GTM functions being built around APIs - API product managers, API account executives, API platform engineers, API customer success, etc. And dont forget about monetization! https://medium.com/@scottehrlich/building-a-commercial-strategy-around-api-products-9cd160102399
Product Manager, Tech | Platform Product
1 年such a great article!
Executive
5 年I like the idea of organizing, coupling and decoupling. Knowledgeable.?
Detailed strategy!! Questions based approach to get all insights.