When it comes to APIs, monetization is top of mind for business and technology leaders looking to create new revenue streams, and market trends have driven a growing number of monetization-curious organizations to implement API monetization.
As CIOs and IT teams dip their toes into new waters, it’s critical to ensure these monetization efforts deliver impactful results and don’t end up as another example of technology for technology’s sake.
To help keep things clear, MuleSoft has developed a new model to cover the fundamental steps for developing an API monetization strategy. We’ll discuss key aspects of API monetization and the model as we’re currently developing a comprehensive API monetization strategy with the CIO guide to API monetization.
What is API monetization?
API monetization is the process of generating revenue through API channels. And successful API monetization includes three key points:
- Offering API access in exchange for revenue
- Direct monetization: Either a charge is applied to a transaction executed via an API, or a consumer pays a supplier for access to or invocates an API
- Indirect monetization: A consumer pays a supplier for an offering where APIs are bundled as part of the product
- Defining a usage plan that includes pricing models and SLAs
- Exposing data, services, and/or capabilities for customers to interact and consume
Introducing the MuleSoft API Monetization Readiness Model
After working with customers around the globe on paving paths to new revenue, the MuleSoft team has structured all our learnings into a platform-agnostic readiness model. Enterprises of all types can use this model to get a sense of where they stand on the road to a robust marketplace filled with digital products and give your business, and IT teams a common frame of reference to execute what will be required for your monetization initiative.
The model comprises five swim lanes: business alignment, partnerships, security, channel management, and service management and five maturity states: opportunistic, ready to explore, ready to engage, ready to launch, and ready to scale.
Progress within each of the five swim lanes will help your organization advance from opportunistic excitement to a deliberate and grounded state that can collect impactful revenue via a scaled offering. Each bold point highlights the most critical point of that particular step.
The foundational layer in the readiness model is business alignment. Business and technology teams must be engaged with each other in a partnership mindset. Without this alignment, there is a high likelihood of deeper problems. While we find that many organizations want to start the conversation with prototyping a developer portal, we’ve found that the typical reasons for prototyping (i.e. risk avoidance) don’t fully apply here.
Just like digital transformation, when monetization initiatives aren’t framed in business outcomes and objectives, IT teams are too divorced from the commander’s intent to make something that aligns with the realities of the business context. For an API monetization initiative to be successful, your delivery team needs grounding from business leaders in product and marketing.
The most considerable risk to be mitigated in a monetization initiative lies in the zone of product fit and not identifying how potential buyers will frame digital products in future jobs.
In working with our global customer base, we often hear IT teams say they need to create a concrete example of a developer portal before engaging business teams to discuss digital product monetization. However, this decision carries a bigger risk in the business lane.
While it is true that enterprise product and marketing teams might not immediately grasp the ins and outs of a monetization initiative. It is also true that IT teams don’t know what business risks by delivering a new offering without pausing to consider how that offering needs to be framed in the context of the business relationship.
A critical step in developing and launching any externalized API offering, whether monetized or not, is to consider how you wish to package that offering. This offering might look like the following:
- A tiered offering that uses rate limits
- One with smaller datasets
- Limited support
When organizations intentionally require teams to consider packaging models in the development of the offering, the enterprise has the option to market that offering to its partners and customers. Conversely, when you leave packaging considerations as a phase 2 concept or choose to silo technology development from business development, the organization forgoes the option to design the package as part of the product. This is because you’ve already limited your business team based on how the capability was developed.
This small nuance can make all the difference in the world for launching a profitable digital product. Without any collaboration between the business and technology teams, there is no conversation on how to preserve flexibility in future business decisions. This lack of flexibility results in users being unwilling to pay for something they’ve grown accustomed to getting for free.
Rather than focusing on the more manageable risk of launching a developer portal with already proven technology, IT teams need to lean into their discomfort and focus on the more significant risk of not aligning to business ROI by releasing an offering to the world without considering how you’ll control the engagement and make it to your enterprise’s advantage. This distinction separates the concepts of “free” and “freemium”.
When your first offering is “free” without constraint, your future users are likely to balk when you try to modify the terms of engagement. Conversely, when your first offering is freemium, you’ve set your business teams up for charting the path to premium value and price points.
Once your business and tech teams are at the same table, the next topic to engage on is partnerships. Establishing partnerships is a key practice of the digitally native enterprises and is used to find partners on the way to market rather than to start looking for them after you’ve launched.
Don’t build a product and hunt for customers. Instead, create the product your existing customers and partners are already asking for.
Co-creation with partners helps you avoid product fit issues and visibility into how customers receive value. This visibility is key to solving the cold start problem, where you don’t have enough data to develop a pricing model via value testing.
Once you’ve executed a value test with a co-creator, your product and marketing teams will have enough data to frame a pricing model that works for you and your target market.
The next swim lane in the model is centered around security and compliance. For teams still learning the ropes of digital product development, it is essential to sequence your initial product offerings with lower security risks. This is to avoid having your teams blocked at the last minute by infosec experts who likely don’t have the time to help plan the controls needed for big offerings with more risk involved.
While it is true that regulatory compliance is often an invisible determinant of success and complication for monetization, it’s important not to over-rotate and look to legal to “approve or deny” product concepts. Instead of having legal gatekeep your work with pass/fail toll gates, have them shape your offering so that it’s aligned with the laws and regulations of your markets.
One step up from security and compliance is channel management. Channels of distribution are the linchpin of any scaled offering, and a product without a channel is indeed an unscalable thing of little value.
Channel development activities can be complex, but MuleSoft and our product partner Revenium have taken a lot of the hard work off your hands. Our investments in the automation of the order-to-cash processes have compressed the time required to package and merchandise digital bundles from months to minutes.
To see this type of commerce automation in action, jump on over to the award-winning launch of our customer IQVIA, who made a big splash in the BIO IT world with their new API marketplace that is initially seeded with a set of hyperautomation offerings for healthcare and life sciences companies.
While channel management is designed to help knock down barriers to sale, the service management swim lane is targeted to eliminate potential obstacles to scale. Given that APIs are products sold in a service context, as you scale you’ll need service teams supporting the channel of distribution to have a growing book of digital business.
Gauge your readiness today to get started on the path to revenue
Adopting an API monetization strategy will allow your organization to drive revenue. Like all new business ventures, a carefully developed strategy is needed to ensure that it is developed in a scalable and sustainable way.
While you might be thinking that you know all there is to learn about API monetization – this is just the tip of the iceberg. To get the complete picture, dive into MuleSoft’s CIO guide to API monetization to help identify which business type your organization is classified in and which API monetization approach makes the most sense for your needs.
