The document emphasizes the importance of treating APIs as products to drive business growth and adaptability. It outlines strategies for recognizing relationships, gaining executive buy-in, and enhancing acceptance criteria to foster a customer-centric mindset. Additionally, it highlights the necessity of aligning APIs with overall business models to avoid commoditization and maintain user-focused design.

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

3. 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
● Founding member of RAML Working Group

4. 3
Stoplight.io - Collaborative
API Design Platform
Design
Mocking
Documentation
Governance
Visibility
Collaboration
Development

5. 4
The Business
Value of APIs

6. 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

7. 6
APIs Help Your Business Become Composable
& 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

8. 7
Ok, so APIs are
important.
How should we treat them?

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

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

11. 10
Recognize
Relationships

12. 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?

13. 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.”

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

15. 14
Gain Executive
Buy In

16. 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.”

17. 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.

18. 17
Most importantly…

19. 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."

20. 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.

21. 20
Enhance Your
Acceptance
Criteria

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

23. 22
For more tips
and tricks on the
API space...

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

25. 24
Questions?