Pursuing Business Growth with APIs

An Interview with Bala Kasiviswanathan, Director, PM, Google Cloud API Platform

This is Part 5 in a blog series on Customer Relationship Marketing.

Part 1: Who is the Customer in Business Marketing?

Part 2: Key Customer Relationships for Tech Offerings

Part 3: Orchestrating Three Pathways into Business Customers

Part 4: The Hidden Purpose of Customer Relationships

In this interview, Bala and I discuss the unique go-to-market challenges of API-based products and business and riff on how the framework of Orchestrating Three Pathways Into Business Customers applies to such businesses. 

Anurag: When you and I worked together at Apigee and then at Google Cloud, I saw your superpower first hand: your ability to think in systems and in first principles. I saw you apply this as we worked through bringing products to market. How do you think this skill affects the partnership between product management and marketing? 

Bala:  Ultimately, I think both marketing and product management are in service of our customers and the market. But the collaboration process is not a serial one.

Maybe that's the biggest difference between the framework we used ten years ago and now. Today, it’s a lot more iterative because the customers’ attitudes and the users’ attitudes are fluid, and also the mechanisms to reach them are no longer static. 

So this gives us a new framework to partner. As an example, suppose we have a product hypothesis around something far-reaching, the product team can go to marketing and say, “Okay, how do we make this consumable by the audience and get some reactions? Is there a low-cost way of doing this to get a sense of the market before we even build the product or spend much on it?” Marketing can give me some guidance on how to conceptualize this idea, get it out of the door, and then get some feedback. Maybe we blog about it or test it in a webinar with customers.

And then at the next stage, we can say, “Looks like there's something here. What's the next step for crystallizing this a bit more?” Maybe we build a little. At Apigee, we called them solution accelerators, where we built some add-on capabilities to the product, solving a certain problem for an industry. And together with marketing, we would get quick reactions from customers. And when we heard from them that our solution solved a particular problem, we could move faster to the next stage of this accelerator model.    

Ultimately when we had enough critical mass to the concept, we got to the question: “how do we productize it fully?” By then, we needed the product to be very easy for the customer to understand and for the user to use. This third stage also involves great marketing: how do you then articulate the customer value proposition in a targeted fashion. And one level up, you can play back the customer success stories, and we even iterated on that. 

Today, you have to think of this iterative framework of three or four stages. In the past, product teams may have assumed, “Let me build and then hand it over to marketing, and their job is to go create demand.” I think that model is obsolete.

If you don't have a great partnership upfront between marketing and product, you lose a lot of the ability to collect signals quickly, and then amplify these signals.

That's how the partnership needs to work. 

Anurag: You are talking about exploring product market fit in stages from testing concepts at one end and closing the feedback loop with customer success stories at the other end. You have seen the full spectrum. So what's the difference today between building SaaS products for a business versus building tech products for IT or developers?

Bala: The classic example of a business app for a business user is a business management software like Salesforce. Each solves a business problem. There may be several options in the market. Business buyers evaluate them and make a decision. Where the business users and their problems are well defined, and the services fairly mature, buyers don't want to reinvent. They want to just buy and use. 

What’s changed on the tech side are the skills of the people who are building, using, and governing new software.

Today, a technical user who is extremely savvy has many options available to them, and they have no barrier to try anything new.

Here’s an example. Let’s say you're a product designer. You can go and try 15 different software tools today without any approval because the barrier to entry is extremely low. The demands on the designers are getting more complex than what they used to be a decade ago because they need to speak the same language as developers and work closely with them.

In this context, the IT folks have less of a role to play until the designer decides to purchase something. IT may need to offer a governance model such as, “Looks like we have three options here, and we can check them out to make sure there are no data leaks or privacy issues, then we’ll have the design team to make the decision.” In the past, there would have been only a pre-approved software catalogue of things that could be used. 

Another element is the proliferation of open-source technologies, which have no governance model, but folks are producing a lot more interesting stuff faster, and building better products.

So the role of IT is that of a facilitator making sure that they are empowering their technical users to make the right decision, and at the same time, making sure that they are protecting enterprise exposure through some governance model. This may be more about privacy and security, not just about cost structure. Or it could be about using an open-source project, and using the right type of open-source license. Or similarly, if you're collecting user information, you have to create the right safeguards for using and protecting that information.

Anurag: Where do APIs fit into this model? Are they a business-oriented technology or are they a developer-IT-oriented technology? 

Bala: It depends on the outcomes you're driving. If you are driving a technical outcome where you want to make it easy for applications to talk to each other and have some standardization between them, then you can check out the API mandate by Jeff Bezos.

The Bezos API mandate said that every software service inside Amazon needs to have an interface that every other tech team can and must use and thou shalt honor that contract and maintain that interface.

In such a case, APIs are all about reducing the friction and making sure that each team is autonomous and there's no barrier to using each other's services. 

So from a technical and architectural point of view, this makes it easy for an enterprise to interact with any team because you don't need to know anything more than the interface and the contract that comes along with it. It becomes a standard operating procedure when you want to build something. I think that's like the first-derivative benefit. 

The second-derivative benefit is how do you now extend the API boundary beyond the internal teams to the outside world. You have heard this many times that there is an edge—the edge of a network or edge of a business unit or edge of a company. Over the last ten years, this edge has gone farther and farther out. 

Now, if you make APIs a business construct, then these APIs can be pretty powerful. This means that APIs can be used by any of your partners, and even by your customers. And APIs can be a means of doing business with somebody. As you've written in your post, Stripe or Twilio wouldn't be a business 15 years ago, but today businesses are built on an API-based interaction and a business model. 

APIs can also be a fantastic way for your company to enable innovation.

Because there will always be a use case that is not a priority for your company to build, but you don't want to block your customer from building that capability. And APIs are a good way for either a partner or customer to extend your product and do something interesting. And then you can take it one step further and also see what innovation happens outside your virtual walls and if that allows you to iterate and compete better over a period of time.

At Google Cloud, we have seen this play out in various industries like banking, healthcare, and manufacturing. 

Anurag: You covered a lot of ground from possible use of APIs within the company for interoperability between teams, as well as at the edge of the company for exposing the capabilities, to potentially opening APIs up for innovation by the network. What are the most common mistakes product and marketing people make in building and marketing APIs? If somebody wants to start an equivalent of a Stripe or Twilio today as a product leader with a very clear idea of how to commercialize it, what are the watch-outs? 

Bala: So if we both were at a company that is building a business around APIs, first and foremost, I would ensure that the product is built with the APIs. This is the first principle and needs to be taken care of all the time. Second, I would partner with you to a) market the business value to the companies or the business decision makers in the companies, and b) communicate how easy it is for the developers to consume services through the APIs. 

The technical communication needs to be the most authentic so that it is frictionless and clear for the developer on how to try the API, get a result, and validate it. And that is the number-one request I would have for marketing because that's the most common mistake.

An API-driven business is all about the developers understanding the value proposition in a hands-on fashion with the least amount of effort.

And if you make that happen, they become the best champions for propagating that message to business people. 

Anurag: So using the customer quartet framework, we see that we have a technical user who's a developer, and therefore that's the primary product experience we need to nail early on and make sure that's in place. Yet if the API itself has a business value proposition to a business buyer, does it come later? How do you thread that needle? You could have a fantastic developer-friendly API and yet not have a business value proposition for the buyer. So how do you look at the other side of the coin? 

Bala: I think the business problem is easy, but it’s the next step to solve.

In the Stripe example, the business problem is that if somebody's buying a product online, how do they complete the payment transaction with ease. You, the owner of the e-commerce site, have done the job of advertising this product online, you have brought the user to your website, who has browsed the catalogue, added to their cart; but your problem is your checkout experience is hard for them. So how do you build the simplest and the most elegant payment experience you can present? That is the business value proposition of Stripe. So if the API is great, and your developer loves it, she can help you solve this business problem of payment experience.

Anurag: How do you see the go-to-market channels splitting based on user/developer-focused efforts versus business/buyers-focused efforts for API product companies? 

Bala: I think the examples you quoted of Twilio or Stripe are very relevant. A business owner wants to keep their customers happy, whether by making sure that “I'll keep you informed on where your package is,” or “where your food order is.” That's the way the business is going to delight its customers—and do that at scale consistently, and at lowest cost. By lowest cost, I mean not only the business cost, but also the cost of writing, maintaining, and updating the underlying code. Then, I can connect the dots between tech API and business use to say what we deliver as a company, and how we do it. 

So if we have any company that has a service, and we have APIs for that service, with the developer and the business owners in sync, then we have a framework to delight your customers.

A framework like Google API Management provides your developers a way to implement the services at the lowest cost in terms of engineering, maintenance, or updates to deliver that experience for your customer. That's the bridge we provide between tech and business. 

Anurag: How do commercial teams for APIs—sales, marketing, and product channels—bridge that gap? Do you run different playbooks for developers and business people? How do you orchestrate them? Which comes first? Do they ever come together?

Bala: There are two very different paths, as you have written. First product-led, second account-led. For a technical user of APIs, in this case a developer, the product-led growth is going to purely come from making sure that the product is easy to use and users are able to self-serve. There should not be any barrier of discovery, ability to use, and ability to validate that this API product is capable of solving the problem.

The API product focus would be self-service, which means the documentation is excellent and self sufficient. Developers should be able to discover the product on a simple search, try the service without, say, needing a credit card or having to share other unnecessary information.

And if it's an open-source project, there is an easy way for engaging with the developer community so that credibility can be built over a period of time. So all of that along with a lot of non-marketing but educational content, whether it's the form of technical documentation, how-to videos, or code labs. This is the way to go in terms of making sure that the product-led piece is taken care of for a technical user or developer. 

On the business side, you have to be able to build business thought leadership. And the reason for that is it's easy for the technical product to move from the developer to the IT side by asking such questions as “how do we govern and implement this API?” without getting to the business side, which is “what’s the business impact and ROI?” So, to be successful, you have to start with the business thought leadership around what is it that you can do with this API technology.

Anurag: Say more about business thought leadership of APIs. 

Bala: You need to bridge the technical user to the business buyer so the API is no longer relegated as a technology artifact.

A good API is as much a business interface as an application programming interface.

This is especially true from a business-to-business perspective. Therefore, you need to convince a business owner that this is an interface to your business. 

Anurag: That’s good, because this can be a front door to your shop, to your purchasing portal, to your partner portal, to your distribution portal. In fact, an API could be a gateway to whatever business process you're trying to improve. 

Bala: Actually, there are a whole set of new businesses that take this one step further. An entire business process is an API. For example, background checks. 

Anurag: That’s right. Checkr, which is an Accel-backed company. 

Bala: Exactly. The entire process of a background check with an API. It’s not a new problem statement, but there are a lot of improvements in how the problem has been solved via an API. 

We have customers such as Pitney Bowes, who have exposed their entire commerce infrastructure capabilities—from delivery, logistics, and returns to cross-border fulfillments—through APIs. These are maintained by developers so that hundreds of their business customers like retailers can embed these into their work processes. They have built new revenue streams from these capabilities. 

Anurag: For such business-oriented API product companies, do you have a point of view on whether to start by building a developer network or by selling to business buyers?

Bala: That’s a hard question.

I think you need a beachhead industry to gain credibility. Without an industry where you can prove business value—that you have gone from thought leadership to impact—it is hard to gain credibility. 

On the developer side, it depends on whether their ecosystems are limited to industries or are more flat network evangelists. I differentiate between the two because if it is the latter, all boils down to the reputation, the charter, and the feedback amongst the community of developers. 

So when somebody says, “I want a payment API” or “I want a background check API” or “I want a explore classification API,” if you’re surfacing in the top five, hopefully it's a reason you’re surfacing in the top five, and the thought process would be, “Hey, let's go make sure we our SEO is great, we have some paid search ads, and blah blah blah,” yes, of course, they will help. 

But if you’re going after the technical community, they're not going to be satisfied with a developer showing up in the first five results. They may go to their communities and ask, “What has somebody else used? Why? What is the technical benefit?” These candid conversations that are methodical and opinionated with facts to support them go a long way in building the trust within a community. These are hard to overcome with just SEO or marketing. 

On the industry side, you're doing a Venn diagram of the industry and the technical community. Depending on how that community exists in that industry, you shall need to be nuanced in gaining credibility or visibility with developers and winning them over. 

Anurag: Any examples of these patterns from Google Cloud customers?

Bala: One is of course search. A lot of the search results on technical topics automatically bubble up the top technical users because of validation by other developers. And then there are third-party community sites, such as Stack Overflow, where people engage deeply with the community. We’ve seen this in the Apigee developer community where people discuss topics openly without controlling the messages, where technical prowess is respected. 

We have also seen our customers build powerful communities. For example, we have companies in every vertical, whether they're doing technology, e-commerce, or healthcare. They are building their own communities of either a partner ecosystem or developer ecosystem that springs around that industry. And they are going to be influential in helping some technology succeed or give feedback to give credibility to that. So that also becomes interesting.

Anurag: The third pathway to growth is channels or marketplace. Are there any API products that have been successful primarily through channel growth? Or is it always developer first or business first, and channel comes later? 

Bala: This goes back to extensibility. If you want to drive growth via an ecosystem or channel, you can think of it in two ways. Either a channel is distributing your product, or a channel is engaging to add value on top of the product. And that value can be in the form of services to help customers implement the last mile or a unique product built on top. In fact, there are many examples where channels partners build plugins or extensions on top. 

You can go back to the classic channel-driven success of Windows operating system, where applications were built through channel partners or ISV using APIs. More recently, we have app stores that are better manifestations of the same method. Because APIs have been defined for an operating system and the hardware, developers can quickly build amazing things today. 

Ecosystems can be at many levels. For example, if you're in a computer aided design software, you have a lot of plug-ins or modules for specific industries or problems that have been built by partners on top. Even the browsers have a lot of plugins by others. I recently got one of those Fitbit trackers that has an app ecosystem around the hardware device which has a clear set of APIs. If you look at a home security system or our phone systems, they are all fundamentally ecosystem plays. So I think the pattern is clear that you can drive growth and monetary value both to yourself and the ecosystem partners. 

Ultimately, a channel investment is important because you are not able to solve all the customer problems. In this case, an ecosystem or a channel play is needed to keep the customers satisfied. That’s another way to think about it. Tradier is an good example.

Anurag: So to summarize what you are saying. The developers come first. Because they are the primary users and they need to believe in the value proposition of the API and technical value. Then comes the business impact with thought leadership. And to your point, there should be some niche or or some industry corner where that business value has to be proven out. And hopefully with those two motions, you can expand into building an ecosystem. This can be built around either for a use case or domain area like home security, or healthcare data, which has enough need for extensibility that cannot be fulfilled by the API vendor itself. That's the pattern of growth. 

Bala: Yes.

Anurag: The world of data and AI is growing rapidly, as is the world of APIs. How do these two worlds intersect? 

Bala: An API is a means to the end in the sense that it is giving you access to data. But it also gives you access to metadata, who's accessing the data, how, and when. So if you have a strategy to apply machine learning or intelligence, not having an API-first or API-driven approach would be a false start because you would not get too far in building the business outcomes needed. 

So let's say an insurance company has 100 years’ worth of data. You may start with some of the historical patterns and be extremely smart in making decisions from well trained models because you have the data. Unfortunately, an event like a pandemic changes our behaviors—in how we live in our homes, how we drive around. Now if you didn't have an API-driven customer experience or interaction or some way to capture the ongoing changes and update that data, you're now out of sync on the decisions you need to make in this new world. So, this is where the API and the data go hand in hand. Even if you have applied a lot of machine learning to that data at a given point, it may become irrelevant or obsolete as the world changes. What an API strategy gives you is the ability to be iterative and nimble with data by having a continuous learning model, which can be more impactful to the business.

Anurag: Does bringing together AI capability to API-driven approaches or apps change that go-to-market in any way in your mind?

Bala: When we started 10 years ago, we needed to educate businesses on why APIs are important for business transformation. We had to convince customers on how to move faster with APIs. We are still figuring out what AI means to business. So, as every organization thinks about what to do with AI and data, we need to make sure they are educated on API-driven approaches, else they will not be to do AI in the long run. 

Anurag: Because you would not be able to interoperate between data?

Bala: You would not be able to interoperate, you would not be able to iterate fast enough, and you won't be able to also act on it fast enough.

One of the advantages of APIs is to be able to take an action, X. And this could be for your health interaction, for your financial services, or it could be for any use case. We can say “based on this behavior we notice, we suggest you take this action.”

And the action can be very easily taken because there's an API for you to enact that action. 

Anurag: API as the enabler of action.

Bala: Enabler of and for action. Or the fact that you choose not to take that action is also a signal from which our system can learn. What not to do over a period of time is equally as important as you taking that action. So APIs are the means to the continuous learning process that you go through. 

Anurag: So what I call a business platform is a combination of APIs and the data interactions that are happening increasingly through predictive models, all in service of a business process or a business goal. In some cases, even a business process itself can be abstracted at an API level. 

Therefore, a business platform is a notion that is neither a full app nor pure infrastructure. It is this emerging interface where APIs, data services, and business process interactions all glued together. On one side of the membrane are the business outcomes, business results, potentially new business apps, business workflows, business actions, and on the other side of the membrane is the world of data, APIs, service-level agreements, traffic monitoring, and security protocols, and so forth. Is that a good separation and the definition of a business platform?

Bala: Absolutely. And your questions about AI made me think about that layer: how APIs are not only about exposing business thinking, but also how businesses can consume. So a simple example are Google services where we have finished AI services in form of APIs, such as Google Vision API or Google Translate API. So the business membrane, as you said, can also be the consumption of some of those AI services as APIs. For instance, an app can now understand a dozen different languages very quickly just through Translate API, just as an app can recognize an object through Vision API. 

So that becomes interesting because new ideas don't have to be just about your own APIs. You can now consume other AI services. So it is a virtuous cycle where you're thinking about your APIs, your data, and what intelligence you can build around that, and expose that in turn as APIs. 

Anurag: And mix and match it. Like a Lego kit for various new use cases. This is fascinating. I want to turn to a couple of personal questions. What do you see as the biggest difference in product management as a profession today versus when you started?

Bala: First, the ability for us to communicate, collaborate, and iterate with customers has changed dramatically. Because 20 years ago, the software was shipped on premises. Releases used to take a lot of time. You had a package to ship. In my Microsoft days, our big operating system releases were two- to four-year cycles. That has changed dramatically. And the collaboration in how we talk to our customers and partner with our customers has fundamentally changed. You get almost real-time interaction and engagement with customers and get feedback. That's one big shift. 

The second shift is in the overall cost of prototyping—I'm using the word prototyping loosely here—it's dramatically lower because of all the advances in cloud computing and open source and also the experimentation frameworks that we have today. So I think this is a fantastic time to be a product manager because you can iterate, try a lot of ideas, and communicate very easily and at scale with your users. And that's golden. If you can get those combinations right for the outcomes you're trying to drive and help a customer, an alpha user, then I think you're on to a winning product. 

Anurag: Yes, those changes have been pretty foundational. For someone starting out as a product manager today, what advice would you give them? 

Bala: First and foremost, I would say make sure that you use the technology yourself or spend enough time to know enough the technology so that you're coming from a place of both curiosity as well as knowledge. 

Anurag: Do you need to be a coder today to be a product manager? There's this conventional view that if you can't code you shouldn't be a product manager. Do you believe that? 

Bala: I think the imperative is to be technical. Whether you want to code or not depends on how much you want to be hands on. If it's a developer-oriented product, if you need to be hands-on, and you want to be hands-on, you should be a developer, but the minimum bar is that you have to understand the technology as well as how you communicate with engineers and everybody to have very good logical and framework conversations with the user in technical terms. 

And if you can't do that, it's going to be extremely hard to be successful. There's also a misconception that if you are going to be a developer, you have to be a computer science graduate. I don’t know if that’s true. But if you're technical, and if you're a self-taught developer, and you understand systems and how they interact, you can go a long way in succeeding. 

The second thing I would say is that there are very many tools today to be in the shoes of the user. Passively, actively, in a partnership.

For a new product manager, I would say definitely spend time in the shoes of the user, whether it’s a technical or non-technical user.

Because if you don't understand what they go through, it's going to be really hard to solve the problem to benefit them. And this was very hard earlier, but now I think it's very easy. And it also will remove the biases that we typically have of how we think about the world, how we think about the problem, how we think about the solution and probably build a lot more inclusive product and opens our eyes to the problems the customer or the user faces. 

I always tell my product managers that while we absolutely want to know how users use our product, please pay attention to what are the other things they're using daily, because it is in that context that they use our product. So the more we can make their life easier in that context, the more value we can drive for them. 

And the third important thing is being open to looking at the data and iterating. So one of the best things that has happened now is that you can get a lot of signals from many places. 

Anurag: You can instrument your products in such interesting ways. 

Bala: Yes. You can do in-product instrumentation and get a lot of signals. You can partner with your marketing team. You're obviously looking at business metrics. So if you are data driven and pay a lot of attention, learn, and iterate, then I think you’ll effectively master the craft of product management. Those are the three things I would say are going to be key if you're starting as a new product manager. 

Anurag: That's the perfect place to close. Thank you so much, Bala.

References

• Google Cloud: A Year of API Driven Digital Transformation
• Jeff Bezos: The API Mandate — Install API Thinking at Your Company 
• Nationwide: PSD2, APIs, and Opportunity
• Pitney Bowes: Transforming a business and an industry with APIs
• Royal Bank of Canada: How APIs scale banking innovation
• Tradier: Trading on the power of APIs 

Afterword

Recently, I had a chance to run a workshop on the various pathways to growth for the management team of company, Jivox, a creative ad tech company. 

CEO, Dias Nesamoney gave this feedback that floored me. Thank you!

“Marketing Patterns is the modern B2B SaaS marketer's handbook to growth and success. It explains many foundational marketing concepts that B2B companies think don't apply to them or don't know how to apply to their business. 

Anurag explains in very easy-to-understand and visual terms key concepts to power growth in any B2B SaaS company. The blog quickly became "must read" material for the Jivox Management team, and we have already started putting into practice some of the strategies outlined. 

If you are wondering where your next wave of growth is going to come from, chances are that this blog will have the answer.”