SaaS Revenue APIs – Increase Sale Per Customer

So what happens once a customer registers for your SaaS services?

The next step is to monetize your APIs. As the business owner, you should consider the following:
  • Registration or setup charges for the customer (This is also to deter casual customers who are only experimenting with the business model)
  • Usage charges (~$.02 per 1000 API calls)
  • API category charges (~$.05 per 1000 API calls for bulk APIs, advanced APIs etc.)
  • Consulting or support charges (per hour or per incident is the common model)
Looking at these monetization options, it is evident that the largest opportunity to increase revenue per customer is from usage of your APIs. Incidentally, this is also the model followed by many large platforms or aggregators.

The following is a use case from the online travel industry, of how API consumption and revenue generation occurs. With the right APIs, it is easy to allow more customers to sign up, and offer them differentiated data per API, thus increasing API consumption.

Travel industry API monetization use case

An online ticketing website such as wants to pull data about flights to satisfy a user query. This data is provided by Global Distribution System (GDS) such as Sabre, Amadeus and Travelport, who aggregate the data from different airlines, platforms etc. The user query must return data to allow him to view options, select an option, complete a booking, make a payment and get details of the booking on email, SMS and the site. 
The diagram below shows the high-level communication, and the APIs in red indicate the monetization possibilities.

For API usage, key fields to retrieve data from GDS:
•    Location of passenger
•    Source and destination of travel
•    Date of travel
•    Number of passengers
Key data points to retrieve:
•    Fields input by user (source, destination, date)
•    Airport codes
•    Airline codes
•    Combination of flights that offer the travel option
•    Price per combination
•    Data validity

 Unless the API or set of API support these data fields, the end to end transaction may fail, leading to a lost opportunity for the GDS to monetize the use case. And similar to this ticket booking use case, monetization opportunities also exist for many online platforms.

SaaS Customer Acquisition and On-boarding API

Once you have a deal for a demo, trial or term subscription, you need to make sure that users are on-boarded very quickly. This has three benefits:
  1. It can be a “go-live” indicator to mark start of subscription term
  2. License usage can be tied directly to the number of users logging in
  3. If users are on-boarded in phases, early users can indicate access or usability issues. This feedback can, in turn, simplify on-boarding of users in latter phases.
Here are the key APIs (application programming interface) that your SaaS application must develop and expose for close integration with client’s existing applications.
[Note: Most, if not all, of these API will need to support CRUD operations]

APIs common to most SaaS or Cloud applications

In this case, the SaaS application will need to expose the following User related API or endpoints
  • User import API
  • Bulk user import API
  • User identity API
  • User profile API
  • User security API
 For business processes, the related set of APIs include:
  • Process Life-cycle
  • Process Access Control
  • Process Data Transfer
  • Process Assignment
And for Reporting and Analytics, the APIs include:
  • Standard views of data
  • Data import into Analytics tools
  • Data export to common reporting tools

The first released version (or V1) of any SaaS or Cloud based application, if designed correctly, will definitely include most of these APIs.
Are these API on your SaaS roadmap?

No Man Is an Island, neither is a SaaS Application

Almost five hundred years ago, John Donne said this quote about man’s nature. Well, in today’s hyper-connected world, the same is true of SaaS applications as well. This radically changes the nature of the application, the demands on the talent and even the organization structure.

However, the key SaaS strategic objectives have not changed, which include:
1.    Acquire paying customers
2.    Retain the customers
3.    Increase the sale per customer
4.    Reduce costs and optimize operations
The first two are usually shown as part of the customer acquisition funnel, as in the image below.

SaaS Application Customer Funnel

But how does this play out for SaaS applications? It actually impacts the SaaS strategy in multiple ways. Here is a look at how the integrations or API strategy can impact all 4 objectives.

As you can see, there is tremendous value in thinking through the entire API strategy and how it impacts your business strategy. To think of a SaaS application as just a set of business rules and user interfaces for a few users is a very puerile assessment of the true value of the product. And a large part of that value is captured via the strategic addition of APIs.
In future blog posts, I will share additional details of how the API strategy works for any SaaS application for any vertical.

Three Fundamentals of a Winning B2B SaaS Offering

For a new SaaS product, it is important to have a robust MVP (minimum viable product). To create the MVP, you need to make sure that there is good coverage of a few areas, and reasonable coverage of fundamental user or buyer needs. The product team has to make several critical decisions to prioritize features in the MVP.

However, all great SaaS products cover the following three areas very well.
Three fundamentals of a winning SaaS offering

The business features to be monetized

A client will buy your product for their employees or users. To buy the product, a minimum set of business features are a must. These are the features that either offer parity with existing products or differentiate your offering from other products. Occasionally, certain CX or integrations capabilities are also described as differentiating business features. Salesforce Lightning Platform is one such example.
 Clients use this as the first basis of comparison (in different packages or payment models) with other products when buying a subscription.

 A robust cloud platform 

The platform is the key to supporting business, regulatory and user needs. A good cloud platform is infrastructure agnostic, and can support security and compliance needs, data movements and user life cycle at scale. It offers easy integration with existing IT infrastructure and simplifies the life of the application administrator. Architects and product owners must work with business product managers to ensure that the cloud platform can be built quickly and in increments.

Vertical or department specific features or rules

These are the domain specific business features that impact the usage of the SaaS offering in a vertical. Offering such features out of the box, is a distinct advantage compared to products that require significant configuration.
For example, a business may require configuration to prevent store employees from logging in outside working hours. If your application has a configuration screen to enable this, and easily set working hours, then that is a big plus for your user experience.

If your SaaS offering covers these 3 areas, then you can be confident that your clients are getting value from the MVP as it is enhanced.

SaaS Product Management – 5 Key Changes

(This post is intended for senior audiences)

There is a well known diagram of a software stack that describes the differences between SaaS, PaaS, IaaS and on-premise deployments. Among other places, you can see it on Microsoft's Azure Learning site and on BMC's blog site. I have modified it a bit to show the role of business product managers in SaaS applications.

Looking at the diagram below from left to right, you can see how business cost and value for the customer is shifted from owning to renting, or Cap-ex to Op-ex. Additionally, in SaaS, the only experience layer the client's users interact with is the application layer. And given the tiny footprint of the rented SaaS application, clients can no longer access the remaining layers.

However, every client still has business requirements that must be addressed, including Security, Standards Compliance, Availability and Business Capability. So, for product managers and directors looking to deliver business value from features and capabilities, here are 5 changes to keep in mind:

  • Customer Journey and User Experience(UX) is paramount

 The user experience of your SaaS application is bench-marked against every other web property. It is no longer possible to have navigation that is broken, or clicks that go nowhere. For a consistent user experience, use UX templates. Customer journeys must be created and designed for the smoothest user experience assuming that every touch point is accessible in real time.
  • Real time interactions are key

Because user engagement must be similar to the web or mobile app experience, it is important to have real-time feedback for every action. A wizard or widget must actively engage a user, let him complete his task and show feedback. At the same time,features related to real time user to user interaction, such as a chat widget or an IM become important even for SaaS applications. These are in turn managed either by the application support team, by the service provider, or by a 3rd party vendor. Product managers must consider how to handle and prioritize such features.
  • User privacy and security require new features or extra efforts

With SaaS, you are essentially handing over all data and meta-data about your company and employees, vendors and users to the service provider. Consequently, system architects managing the complete stack will figure out a solution to meet business and compliance requirements. This depends on the application's security posture, and time and investment planned for compliance and risk management. This activity either leads to backlog requests for adding new features related to privacy and security to your bucket, or it leads to investing time and resources to make sure that your features are compliant with the final architecture.
  • Internal teams are critical to deliver high application C-SAT

As a PM, you are pretty much looking at the top layer of the cloud stack. However, internal teams such as delivery, support, training, pre-sales, marketing will also have their own application stacks, without or without access to a live customer deployment. If as a PM you do not include features to make their work life easier (e.g. delegate access to customer environment) it will impact their capabilities on the application, which will hit your C-SAT objectives.
  • Agile development is commonplace, so are Product Owners

So you talked to dozens of key clients, identified all top features and prioritized the business requirements. This is no longer the end of the product specifications handover to engineering. 
You must breakdown the requirements into technical specifications and continuously track their delivery into the cloud application. With a CI/CD pipeline, the Product Owner takes care of this aspect of inward product management. However, the product manager still owns the UX and customer feedback. Net result, it is common place to find both roles in a cloud organization, with the PO reporting to a PM or a Director.

Strategic Business Unit - On-premise or Traditional vs. Cloud Based

Here are two organizational charts that indicate how product business units have evolved in line with business strategy. [These organizational charts are based on conversations with clients and people in the industry, but do not represent any actual business unit]

The cloud business unit is mainly about the product

The traditional business unit was about the complete Marketing Mix, including the 4 Ps or sometimes the 7Ps.

This change has also impacted the way other departments now engage with the new SBU structure. Some points to note:

1. Finance, HR, Ops are usually centralized functions in a cloud SBU
2. Service delivery, configuration, customization, support, integration and other monetization possibilities have changed dramatically in the cloud. It is no longer possible to have year long delays in installation and configuration contracts, which did occur in on-premise installations. These teams now get fixed contracts and upgrades occur automatically.

3. Subscription pricing is very different from pricing for on-premise or app type products. Unless you are very careful in your pricing models, it is easy to occur losses. In fact, pricing is also getting centralized and moved under finance or corporate strategy teams.
4. Marketing is another function impacted significantly, with SEO/SEM gaining a big share of marketing spend.

In my next post, we will see how these, and other changes, have impacted the role of Product Manager and the Director, PM.

Happy New Year 2019

Happy New Year to everyone.
Last year saw a lot of changes in the Indian product space. If you have been following the news sites, you will know about many of them.

Some big highlights from the e-commerce space
  • The government has finally tightened norms on various practices followed by e-commerce firms.
  • Multi-billion dollar valued Ola has actually invested in another mobility startup Vogo. This is surprising considering that Ola is actually large enough and capable enough to launch their own business unit in this space.
  • And the online delivery space has seen a lot of action from investors, which included Swiggy's $1 billion funding.
Accordingly, hiring in the technology industry has also picked up, with a lot of movement at both senior and junior levels. Bangalore remains a perennial favorite, but Pune, Hyderabad and Gurgaon are not far behind when it comes to people's preferences.

In addition, the B2B software space has finally matured, with a lot of new firms focusing only on the cloud based services, for all departments in an enterprise, from finance to sales to marketing to HR and customer service. It is not difficult to find many new ventures or existing firms that have done well in this space. And I cannot recall many firms that are still doing packaged on-premise software for clients.

The consumer internet space has also exploded, there are a lot of exciting new ventures. These startups are exploring business models, technologies (IoT, Blockchain, Gaming, Reality TV) delivery mechanisms (app only) without losing the focus from a scalable revenue model. India has become an exciting destination for new ventures and finally there is some focus on innovation as well, rather than the traditional IT outsourcing (which has also matured significantly).

Here's hoping for a fantastic 2019!!

Engaging the Cloud Organization for Successful B2B Application Delivery

[In this post, I identify various cloud stakeholders vital for successful application deployments]

A product manager/owner is typically responsible for the functional specifications developed by the engineering teams. However, for cloud deployments, one should also consider the non-functional requirements (scale, security, data confidentiality & isolation etc.) that can impact the use cases offered, as well as the business, financial and legal requirements of offering the product and services in different environments globally.

For an organization running its own cloud operations, there will be someone covering the following functions:
  • Cloud architecture (the people who define what containers, servers and API contracts are available for any application)
  • Cloud ops (the team that runs the cloud, including storage, network and compute)
  • Cloud security (the team that defines the standardized security offered within the cloud)
  • Cloud application support (the team that interacts with customers and users who face problems)
  • Cloud delivery (the team that configures multiple applications within the cloud for a specific enterprise customer)
  • App customization and development (the team that creates plug-ins, extensions and enhancements specific to a customer)
  • App integration (the team that makes sure data flow is managed as per requirements and for compliance needs, between various applications)

Sometimes the last 3 capabilities may be covered by service delivery teams via paid engagements. And in smaller firms, these teams can be outsourced, distributed or merged with other cloud teams.

For the success of your application, it is important to make sure that these customer-facing and operational teams are successful in their tasks. So apart from regular engineering interactions, you may also have to allocate time and resources to engage these stakeholders.

Always keep the following points in mind:
  1. These cloud teams are supporting your application, and there is a symbiotic relationship between development and cloud teams. Do not underestimate their significance.
  2. Application architecture is very different from cloud-based deployment architecture. Listen to your cloud architects and mediate between architect teams as required. If the cloud supports multiple products, your cloud architects may rule.
  3. If you have a team of product owners reporting to you, keep at least one PO focused on cloud platform requirements. From time to time, these requirements can impact your backlog, leading to delays in delivery.
  4. Keep demoing your application to all these stakeholders. Sometimes it can be via hands-on access in a sandbox, but you can also hold a brown bag session to explain new features or enhancements.
  5. Whenever possible, keep sharing customer feedback with the cloud teams. With their focus on ops, up-time, performance etc. they sometimes miss the point of why the cloud exists in the first place.