Treating APIs as products is important for business success. Leaders should recognize relationships between their organization and API users/integrators, and gain executive buy-in by demonstrating how APIs fit into the business model and shift revenue streams. Acceptance criteria for APIs should be defined in customer-centric terms and include automated testing. Documentation is also a critical part of a successful API product, enabling adoption and support.

1. Why You Should
Treat APIs as Products
Tips for a Successful API Program
Jason Harmon – CTO @ Stoplight

2. 2
Jason Harmon
Chief Technology Officer, Stoplight
Engineering, Product, Security, IT
Host of #APIIntersection Podcast
Background:
● Previously:
→ Senior Director of Platform Architecture @Expedia Group
→ Chief Platform Officer and CTO at @Typeform
→ Head of API Design @Paypal
→ API Architect @uShip
● Co-founded Austin API Meetup
● Founding member of OpenAPI Initiative (inactive)
● Founding member of RAML Working Group (inactive)

3. 3
Stoplight.io – a collaborative
API design platform.
Design
Mocking
Documentation
Governance
Visibility
Collaboration
Development

4. 4
Understanding the
Business Value of APIs

5. 5
“
Why should leaders care about APIs?
“Over a four-year period that firms
using APIs saw 12.7% more growth in
market capitalization compared to those
that did not adopt APIs” (+38% growth
over a 16-year period)
Marshall Van Alstyne, Forbes (2021)

6. 6
APIs help your business become composable
and adaptable for transformation.
There’s a difference between a composable business and a marketplace.
● Technology leaders should seek a Composable business model.
→ Modularized architecture based on business capabilities,
i.e. “what do we do for customers, in their language?”
● Whereas a Marketplace focuses on supply and demand
connecting consumers and producers.
→ Usually implies composable architecture, but doesn’t
necessarily require it.
→ Understanding network effects is key to building
Marketplaces the right way

7. 7
Okay, so APIs
are important.
But how should
we treat them?

8. 8
Your API
is just another
product…
Let’s discuss
how to treat them
as such.

9. 9
Treating APIs as a Product
Recognize
Relationships
Gain
Business Buy-
In
Enhance Your
Acceptance
Criteria

10. 10
Recognize Relationships

11. 11
Identify Relationship Constituents
Step One: Create a customer-centric mindset - know who your customer is and adopt
their needs into your culture.
Step Two: Investigate API usage.
● Analyze data, and talk to power users.
Step Three: Answer these questions:
● Are there integration partners at play, and what is valuable to them?
→ Do they need access to customers’ data with consent, or in aggregate?
● Do customers need to get their own data?
→ Raw data may not be useful, are there aggregated or calculated aspects?

12. “
12
Product Managers: Know who the consumer will be
and the business relationship that you will be building.
If you understand how you're operating your
business, with adequate success measures, you’re
on your way to building a great API.

13. 13
One relationship type at a time.
Don’t boil the ocean.

14. 14
Gain Executive Buy-In

15. 15
“
“An API is no different than
an other product.
You need to help traditional
business management into
understanding the relevance
behind the API program.”

16. 16
How to Gain Executive Buy In
● Before Approaching Execs:
→ Ask yourself — how does the API fit into the overall business model?
→ Understand how your revenue is shifting from traditional channels to integrated flows.
● Gaining Buy In: Demonstrating the Value of your API
→ Don’t focus on technical operation measures but on the bigger business picture.
→ Avoid focusing on API calls or operational aspects as a measurement of success.
● Recognize when you're operating a marketplace
→ If APIs are involved there could be some marketplace construct.
→ Thinking in supply and consumption may change your business fundamentals.

17. 17
And most importantly…

18. 18
“
“If you’re not putting the
business perspective around
why you're building APIs, it's
really easy to kill it from a
management POV."

19. 19
If you don’t treat
your APIs as products…
It becomes just a commodity.
A tech artifact.
You end up with an engineered design experience
instead of designing for the end-user.
This is system-centric, not customer-centric.

20. 20
Enhance Your
Acceptance Criteria

21. 21
Automate Your Sign-Off
Build Acceptance Criteria
scenarios in customer-
centric language
Repeatable
automated
testing raises the
bar on quality
Automate
by default, no
brittle UX!

22. 22
Bonus Tip:
API Products are
Better with Great
Documentation

23. 23
“In API Product Management, documentation
is a critical and expected part of the delivery.
Developers must understand how to use the
API, what data or functionality it provides, and
how to integrate it with their systems. This
documentation often "sells" a developer on a
given offering. Because of that,
documentation has greater importance to API
product management.”
- Matthew Reinbold, Net API Notes

24. 24
Define, test and secure product boundaries for the organization and/or
consumers
Why do you need documentation?
© Stoplight 2023. All rights reserved.
Teach your customers, prospects, employees, and partners
about using products and APIs
Enable customer support offerings, especially self-help/self-service
Support technical marketing efforts

25. 25
Who benefits from good documentation?
© Stoplight 2023. All rights reserved.
Internal Value External Value
Avoid duplicated effort
Increase shared leverage
Organizational understanding
of platform capabilities
Increased adoption by
end consumers
Better relationship management
with API consumers
Reputation/credibility with
developer community

26. 26
https://www.apisecuniversity.com/courses/api-documentation-best-practices

27. 27
For more tips and tricks
on the API space…

28. 28
Check out Stoplight’s
API Intersection Podcast
The podcast on the intersection between
API design and digital transformation.
Available Wherever You Listen to Podcasts

29. 29
Questions?