Lisa Oshima is a consultant specializing in digital strategy, business development, and developer marketing. She founded the Socialize Mobilize consultancy in 2003 and has been helping companies of all sizes transform digitally ever since. We spoke to Lisa about how APIs fit into the overall context of the digital economy.
In the API community, we talk a lot about “managing APIs as products.” You’ve been helping companies succeed in the digital economy for some time. In addition to launching API products, what are some items organizations need to consider?
Lisa Oshima: Everyone in your organization should be on the same page about the purpose of launching APIs and what constitutes success before you go to market. Companies choose to launch APIs for a variety of reasons. They may be trying to increase the distribution and reach of an existing product line, service, or brand. They might be trying to satisfy an ongoing customer need or differentiate from the competition. They could even be trying to generate a new source of revenue.
Whatever the reasons, team members, regardless of function, should be aligned towards achieving the same goals. Likewise, executive leadership should be realistic about the investment (both time and money) required for the initiative to succeed and prepared for what could go wrong if, for example, developers use APIs in ways the organization never intended or wanted.
You mentioned teams. Have you seen a recipe for teams that work effectively in delivering API products?
LO: Part of mitigating risks includes hiring a team with the right mix of business and technical skills. Attempting to hire one or two people that can “do it all” is a mistake. Unicorns don’t exist, and that philosophy doesn’t scale. Instead, seek out a combination of specialized business and technical experts who will work well together to achieve shared goals, and don’t be afraid to bring in experienced outside help to get you started. Business team members don’t need to code, but they should be technically savvy enough to understand the product and have intelligent conversations with their technical counterparts.
Business teams should focus on establishing product-market fit prior to launch. They also need to mitigate business risk by working with technical team members to protect the organization’s best interests. This includes establishing Terms of Service (ToS) that anticipate potential nefarious or unwanted uses of your APIs and put mechanisms in place to prevent such usage. It is crucial to build a viable business plan that scales, and revise it when necessary. Business team members should evangelize the platform online and at industry events alongside their technical colleagues, and they should be involved in the sourcing, negotiating, and signing of strategic partnership deals.
Technical teams should focus on investing in platform innovation and scalability. They need to put themselves in the shoes of their developer customers by developing strong API documentation and answering technical questions from the community. Keeping a rhythm of bug fixing and product quality will serve the developer community just as much as networking with them through industry events and social media.
One of the fundamental areas you’ve helped companies with is product-market fit. What are some of the trickiest parts about determining product-market fit in the digital world, when the API is often the primary product?
LO: One of the biggest mistakes a company can make with their API strategy is failing to validate product-market fit up-front. All too often, I see companies launch APIs thinking of their own organization’s immediate needs/wants, without getting initial confirmation that what they’re offering matches the needs of target developers and end users.
It’s important to talk to target developers (and ideally their end users) up-front to validate product-market fit before finalizing your API strategy. Likewise, an organization can have a great API product that developers want to use, but if it’s not affordable or the Terms of Service are too restrictive, the APIs won’t get traction.
When validating product-market fit, make sure your target developers actually NEED the product, can AFFORD it, and don’t have better ALTERNATIVES. Also, carefully consider whether your goals for the API Product can be reached, given pre-launch feedback. For example, if your goal is to directly make money on API calls but your APIs are too expensive to manage and there isn’t enough margin between your costs and what your developers are willing to pay, you’d better reconsider your plan.
Monetization is always a hot topic in the API community. Given the term, many people jump to the conclusion that they should meter their APIs and charge per call. What is the reality of API monetization in your experience?
LO: I see this a lot! However, doing this often has the opposite of the intended effect. Instead of making money off of APIs, an organization may stifle the growth of their developer ecosystem by unintentionally scaring developers away from experimenting with the APIs, fearing cost.
App developers don’t want to add cost to their product without knowing how they’ll recoup it. While it’s possible for a developer to model anticipated new users/subscribers, increased time in app, ad revenue, premium upgrades, and ARPU, at the end of the day, that model is a guess.
If a developer is being charged per call, they’re likely going to worry about the “what ifs” and whether running an experiment is worth the cost before they even get started with your APIs. What if this new feature is used more than we expect, and we end up owing more for the API calls than we budgeted? What happens if implementing this new feature discourages users from spending time in other areas of our app where we already make money?
While every company and API offering is unique, for most companies, launching APIs with the primary goal of making money off of calls is a mistake. Charging up front per call hinders adoption and the ability to grow a thriving–and ultimately profitable–ecosystem. There are a ton of ways to profit off of an API strategy once you have a thriving developer ecosystem. Sure, you can meter and charge per call, but that may not be the best way to maximize revenue.
So what is a better approach?
LO: Think more strategically about how an API strategy can contribute to your company growth… Make it a measurable extension of the sales and marketing organization, and use it to enhance your brand, increase sales of your core product, extend your product offering, create an ecosystem of profitable apps and/or professional services, generate monetizable data, score partnerships, etc.
If, after establishing product-market fit (including what developers are willing to pay) and evaluating your monetization options, you decide to meter API(s) and charge per call, consider a freemium model. Make your charging threshold high enough to get developers over the hurdle of their “what ifs.” Instead of charging per call from the get go or giving X number of free calls, consider offering Y months of free use of your API(s) to encourage developer experimentation. If you need to, you can always cap the freebies by adding a limit of no more than Z calls per month, but be generous.
At the end of the day, the goal should be to get developers to use your APIs as much as possible, increasing their dependence (and therefore their end users’ dependence) on your product. That will cost you money up front, but user acquisition is rarely free. If you’re not sure how to weigh your options or structure the program, considering hiring an experienced consultant to help.
Opening up an API to outside consumption can bring some tremendous benefits, but we’ve also seen examples of companies like ESPN and 23andMe rescinding their APIs for different reasons. What do you see as the big considerations for whether or not to open an API?
LO: This is a great question! Over the years, we’ve seen a lot of this… The most memorable example I recall was Twitter, who years ago unceremoniously pulled the rug out from its developer community by announcing major API usage restrictions and cutting off access to Twitter’s firehose. That was rough.
Opening up APIs can present huge opportunities for an organization, but as the Twitter example shows, it may also present business risks and unanticipated costs. It’s important to thoroughly weigh the risks vs. rewards vs. ongoing costs up front in the planning process BEFORE launching an API strategy. Business and technical teams should both be involved in this process. It’s also helpful to bring in outside consulting help from someone with experience launching/ running APIs and Developer Programs to highlight issues you may not have considered.
There are a lot more angles to evaluate than I can list here, but some of the biggest considerations are:
Up-front and ongoing costs
Can you afford to maintain your APIs on an ongoing basis, including staffing a big enough team to support it? Can you recoup the investment in your API strategy? If so, how, and how long will that take?
Up-front risk mitigation
How might developers use your APIs in ways you never intended/wanted? Can you prevent this from happening? How? What kind of apps (if any) should be prohibited from using your APIs? For example, you may want to restrict apps that involve alcohol, tobacco, drugs, adult content, gambling, illegal activity, apps that are directly competitive with your other products. How can you protect your own product roadmap? Which capabilities will you expose through APIs? Should you maintain some private APIs for your own internal and/or preferred partner use? If so, why and how?
Planning for the worst as you hope for the best
What happens if you need to pull the plug on all or part of your API strategy? What might the negative repercussions be to you or your partners? Ideally, how would you handle an end of life (EoL) scenario on one or more of your APIs with your developer community? How might an EoL scenario impact PR/Marketing for the organization as a whole? Do these risks outweigh the possible rewards?
Connecting with developers and building developer communities is a big focus for many companies starting out on their API programs. But, keeping a developer community engaged can also be a challenge. Are you seeing any emerging techniques to help in this area?
LO: Understanding and adapting to your customers’ needs is key. It’s not enough to establish product-market fit once and move on. If you want to grow a thriving developer ecosystem, you need to manage APIs as products. This includes regularly evangelizing your product and its improvements, talking to and surveying developers to re-establish product-market fit, and investing in ongoing product improvement. The more you make your product invaluable to your target customers, the faster you’ll grow.
Growth hacking in developer relations isn’t unlike app and web growth hacking and user acquisition. It involves experimenting (which isn’t always free), evaluating the results of your experiments, learning and adapting your growth engine, and reinvesting in product improvement. Every member of your Developer Evangelism team should have a growth mindset and embrace understanding customer needs and perceptions, evaluating and improving product-market fit, and promoting usage and adoption.
Thanks very much for your time today! How can our readers stay up to speed on your insights and activities?
LO: I’m currently consulting for alwaysAI, whose developer platform makes it easy to build and deploy deep learning computer vision applications on IoT devices at the edge. You can reach me at lisa(dot)oshima(at)alwaysai(dot)co, or feel free to connect with me on LinkedIn, Twitter, or Facebook.
To apply lessons like these on managing APIs as products and cultivating a thriving API ecosystem, check out the “API-as-a-Product Workshop,” one of MuleSoft’s API Program Workshops.
