Keeping Your API Product Team Happy
Moesif had the privilege of picking the brain of the expert who literally wrote the book on API Product Management. In a wide-ranging discussion with Dr. Amancio Bouza we found out what you should really care about as an API product manager, and it’s not what you may think (hint: see the title). We also cover pricing your API, product manager best practices, and what books should be on your nightstand.
Amancio Bouza has almost 15 years of experience as an API product manager, product owner, technical product manager, and engineer. Besides publishing the book on API product management, he helped to establish API as products for the digital economy with novel concepts like API as interface to value proposition: VPI. Today, he helps companies create business value through a combination of lean startup methodologies, customer obsession and ecosystem development.
The following is our questions and answers. They have been edited for clarity and length.
Q: What do you see as the most important KPI for API product companies?
A: To really see whether a company that provides API products is successful, you should focus on retention.
Usually what happens is that a customer tries certain things out. They say they want to go and use your API, or plan to use it in a certain way. But when they really do the project, integrate it into their product or internal business processes, only then you can really validate that they’re using it in a way that satisfies their use case. And then if a digital product manager continues using it, and you observe a growth in API usage, then you know it’s been successful in that company.
And if you see that there’s more traction, more companies become interested in it, that’s even better. But it really depends upon the API product. It could be that the market size is really small, but the value is huge for your API product.
Q: If absolute numbers aren’t important, how do you quantify the value your API might bring to potential customers?
A: For this you really have to understand the customer’s use case.
Let me explain this with an example. I worked with an insurance company that created a new online portal to onboard users and sell insurance products. In onboarding, they saw that the conversion rate of people going to the platform, starting the registration process and signing up for the service was only ten percent. In order to increase their user-base and streamline their funnel, project management with a focus on customer need and customer feedback was necessary.
We did a deep dive into the onboarding process to see what prospective customers had to do, and what we saw was a lot of verification and validation steps - sending emails to verify email addresses, sending SMSes to verify mobile phone numbers, and even sending letters to a home address to verify where people lived.
From there we looked at the drop off numbers and saw that you lose people at the phone number stage, you lose more with email, but you lose the most by sending letters. Not only that, but letters cost six Franks to prepare and send, on top of the marketing that you invest to get them to the platform. From there we estimated that if could kind of solve this problem, not only will the company save the mailing costs, but improve their conversion rate. So we knew then when you provide a service where we can increase the conversion rate, he really gets one win, and by saving on postage, he gets another bump. Based on this we also priced the API.
So by only really understanding the process, are you able to the measure the value of your API. Part of the product management process is assessing the worth your successful product has not only to your prospective API users, but to your business and product vision.
Q: In terms of initial pricing, how do determine what to charge for your API?
A: We use a kind of general rule of thumb that we need to recoup our marketing costs within a certain time frame.
We often start with the initial estimate that the cost that you have to invest into marketing to get a new user registered is around $10 to $15. Bear in mind that with a 10% conversion rate, you’re loosing 90% of the people initially attracted by the product marketing program.
And then, for the real pricing, you just can’t say, okay, listen, you as a company or you as a prospective customer, you’ll save $10 using this API for each call, so please keep give us $9 and then you’ll save $1. It’s common to divide the value that you provide by ten, or even more to really make it so compelling, that they can’t reject it. Or as in the movie Glengarry Glen Ross, make them an offer they can’t refuse. So somewhere between ten times lower and one hundred times lower, is where you should end up.
Q: For those companies that are considering offering an API to compliment their existing “full” product that has a frontend etc, what discount should product managers apply over the full product?
A: My co-author Andrea Zulian says that it’s a defect in the DNA of APIs that you can’t just buy it and use it, you have to integrate it as well, which is often not trivial.
Integrating an API into a product usually involves quite a bit of an investment by the company. They have to open a program, put in a project team, create tasks to integrate it into their testing environment, manage continuous integration, continuous delivery pipeline, sandbox testing, whatever. So that’s quiet a huge cost that the customer has to invest in order to use the API, and that has to be considered when you determine pricing.
But that’s also some sort of an opportunity for whole API product design. Great product managers will go out of their way to make it as easy as possible for developers to integrate based on customer need in the proper way, by: providing a sandbox to test it in, making it easy to do duration testing with the API, providing the test data and good documentation, SDKs and use cases.
API Product Managers should make data-driven decisions. After specifying the API product, validate that it brings value to customers by closing monitoring log files, or using a tool like Moesif that provides more insight into what’s going on with users
Q: What’s the most important feature a product manager should provide to make the developer’s journey as frictionless as possible?
A: Others may disagree, but it’s a sandbox environment.
It turns out that only a small amount of product development documentation is usually good enough. Developers that are using or integrating APIs are capable of using the API and understanding what kind of the information they can get from it. Often, what’s really lacking is the provision of some sort of a sand box, or test environment. A good engineer wants to do agile development, they want to do continuous development, or CI/CD, and automate the pipeline. They can’t automate testing if you don’t provide some sort of automated tests.
The paradigm of development has changed in recent years to really automate the whole process. And it’s always the case that you want to optimize the pipeline and put the product into production of soon as possible. Without proper design thinking and testing you can’t really be sure that the API you’ve integrated still works, even if the API is still available.
By excluding a testing environment, engineers won’t be able to shine - they’ll be unsure that what they actually built is really what’s expected. They define the test cases, they know what should be the right answer, they know what should be the wrong answer, and they know how to use the API. But without a testing environment, a critical piece is missing. This is usually the most disappointing area for developers that use the APIs of other providers. To foster product success, allow engineers to test critical components of your API product, such as a product feature or new feature. By designing your product directly for user needs, you can gain valuable insights while instilling confidence to internal stakeholders.
Q: Is it usual for the API product manager to have to specify the test environment?
A: The best product managers need to understand how developers think, how they work and what their needs are.
API product managers should decide what’s actually delivered together with the actual API product itself. So it’s kind of part of the full platform capability, like providing a sandbox environment, test date and the like, that the product manager has to define. It should be viewed as an important feature of his API product, like a kind of SLA feature. And then of course it’s up to the API product manager’s development team to monitor that the API is working, to improve the platform, provide a better sandbox environment and so on.
This is a new skill or perspective that the API product manager has to have. He now needs to understand how developers think, how they work and what their needs are, in addition to his classic responsibility of knowing how his customers will consume the API.
Q: How can product managers make themselves more effective in their roles?
A: Fully understand DevOps and developers’ mindsets.
Really read into the topic of DevOps. DevOps it’s combines development, operations and automating the whole process of running software in production, or bringing software into production without any friction. A product manager has a team of internal developers, so he should just ask them how they’re doing it. It’s funny, the company that provides the API, they’re doing DevOps, but oftentimes the API is provided in a DevOps unfriendly consumable.
So I would really recommend that product managers go and talk with their software engineers. They should hear from them what they like, what they want, what they need, and also where their pain is. By having this kind of perspective, product managers will have a much better understanding of developers outside of the company.
Q: Is there much utility in digging deeper into the payload of the API to see how end customers are using it, or do the product managers’ scope of work just stop at infrastructure monitoring?
A: There’s a lot of value to be gained by looking into the payload.
I think that both provide useful perspectives on the API product itself. So just as an example, if you see a lot of errors happening in your API calls, like 4xx responses (something doesn’t exist), it could be that something has gone wrong, or the consumer, from his perspective, is doing something right and the error message is actually a valid result. This could happen in a search API where person doesn’t exist in the database, but the 4xx error is actually valid information.
It’s a rarity that an API product manager is able to look into the payload and really understand what kind of information is requested by the API consumer, and then interpret and learn from it.
For example, I worked with a payments API provider and we saw that all of the transactions, or most of the transactions, were micro payments. We then said, okay as a provider we need to improve our micro payments program - we need to make these transactions as cheap as possible. If you can’t support micro-transactions because they’re just too costly, maybe you should offer to batch the micro payments. So you see, in this case we learnt how consumers used the API and then adapted the API product so that our customer got increased value, and the organization also got additional value.
Q: Are there other API products you’ve worked on that have benefitted from user-centric analytics?
A: Data governance at a large telecom carrier.
At a large carrier we built an identity verification API product that had very specific rules on data privacy/data governance. Their legal department said we were not allowed to provide information on customers of the carrier, only those outside of the carrier.
During the design phase we implemented a system that allowed for a direct call to make the identity verification, with just a stipulation that you weren’t allowed to use the API if you were verifying retail, business or VIP customers of the carrier. When we looked into the log files, we saw that customers were using it when they shouldn’t have been. To guide them to do the right thing we re-designed the API product to comply with our internal rules - we implemented a secret key that was only provided after verifying they weren’t searching a customer.
Q: What is the top metric that successful API product managers should be following?
A: This may not be a metric, but it’s the happiness of the team building your APIs.
It really helps the PM when his team is inspired and motivated, when they are improving themselves learning something new. If you have a happy team then they really care about providing good error messages, they care about their customers and want to make them really successful, they’ll provide support for the API product manager helping to create the best API products to consume. I don’t know how, or on what scale you can really measure it, but at the very least you should talk to them and get a feeling if they’re happy, and if not, what you can do to change that.
Q: What’s your other most important metric to follow?
A: Onboarding time.
Number two is the onboarding process, or how much time a company needs to really integrate an API. It’s not just following a nice metric like Time To First Hello World, or time to first API call, it’s really about how much time customers need to stand-up the API: test it, integrate it and put it into production.
The good thing is that if you’re logging APIs, or have a tool that does that, such as Moesif’s, these will show what’s truly going on. You can ask your customers if they’re using your API, but if you don’t see any traffic than you know okay, they aren’t using it. We had an insurance company we were working with who said they were using the API, but we never saw any traffic, so we knew something was wrong. We approached them and asked how we can help them integrate and together we figured out what to do. Sometimes projects are postponed or there are dependencies, but other times there’s an integration issue that you can really help with.
Q: Besides your own book, what do you recommend product managers should be reading?
A: Well rounded product managers know how to create ecosystems around customer journeys. These four books provide a comprehensive picture on how to do it.
Strategize: Product Strategy and Product Roadmap Practices for the Digital Age by Roman Pichler was the first book on digital products. The author really understands how to do stakeholder management and how to define digital products as a service. He foresaw the digital product trends.
The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses by Eric Ries to understand the methodology of validating and verifying your ideas based on numbers.
Continuous API Management: Making the Right Decisions in an Evolving Landscape by Mehdi Medjaoul et al is for API architects, developers and product managers and provides the whole picture on API product management from what type of roles you need, through to organizational topics, all from a technical perspective.
The Death of Competition: Leadership and Strategy in the Age of Business Ecosystems by James Moore is about building business ecosystems. The ultimate promise of APIs is that you become part of an ecosystem, one which makes you valuable outside of your specific industry. There are no more barriers between industries, rather you can be part of creating ecosystems around customer journeys by collaborating in the right form.
Make Your API Platform Successful with Moesif
14 day free trial. No credit card required.
Learn More
Related Articles
API Analytics and Monitoring
Introducing AI Explain
We are thrilled to introduce our newest feature to Moesif - AI Explain - a powerful conversational tool that lets you interact with your API analytics data l...
API Analytics and Monitoring
Monitoring Cost and Consumption of AI APIs and Apps
Discover how Moesif can help manage and optimize your AI-driven APIs with powerful observability tools that track costs and usage efficiently.
API Development
Unlock Deep API Insights with Moesif’s HTTP Body Analytics
Learn how to use Moesif to analyze HTTP bodies.
API Analytics and Monitoring
How Moesif API Observability Compares to Treblle
Learn how Moesif’s API observability platform compares to Treblle.
