Taking a product mindset to APIs is becoming a key ingredient in successful API-driven strategies. Because, applying product management principles to APIs helps keep the business side of the equation involved, which could unlock some interesting possibilities as API programs mature.

At the Platform Summit 2023, Jason Harmon will share the benefits of beginning with a business-driven API-as-a-product approach.

According to Jason Harmon, CTO at Stoplight (acquired by SmartBear), API-as-a-product is a beneficial strategy to consider, even for internal-facing interfaces. Doing so could help future-proof the business and prepare for externalization if the opportunity arises.

Ahead of Platform Summit 2023, we’re connecting with key speakers to learn what they’re working on and to get their perspectives on the API economy at large.

Jason Harmon, a veteran Nordic APIs speaker, has been working with APIs in some form or fashion for years across companies like Paypal, Typeform, Expedia, and now at Stoplight. As such, he has an excellent view of the productization potential APIs offer and the techniques necessary to optimize them for consumption with superb developer experience.

We caught up with Jason to dig into the API-as-a-product trend, a theme of his upcoming session. Below, we’ll explore what API-as-a-product enables, the advantages of a design-first approach, and more. Check out Jason’s answers below, and attend the Platform Summit 2023 for more discussion on this topic and plenty of others!

Why should you view your API as a product? What are the benefits of doing so?

The first and most important is readiness for business opportunity. If an API was never designed to be externalized, and an unexpected business opportunity to integrate externally arises, you are likely to face delivery delays as redevelopment will be required in order to make these integrations possible.

In addition, APIs are increasingly strategic in nature for successful businesses. If business stakeholders and other development teams are unaware of API capabilities, as you only treated APIs as an engineering-owned implementation detail, your business’s strategic viewpoint is highly flawed. Applying product management to APIs means that business stakeholders can gain stronger insight into what is possible and make more effective business decisions.

Do you think taking a product mindset is always necessary or helpful for internal APIs?

If you apply a product mindset to all APIs by default, you can make explicit decisions about what should not ever be externalized (typically core intellectual property) and make design compromises that optimize for internal use for those exceptions. If the default state of API development is classified as “internal only,” then all externalization will induce delays in redesigning the API to be ready to share outside the company.

On the contrary, if all internal API development defaults to an externalizable, productizable state, there is inherent future-proofing. When business direction changes or partnership opportunities arise, building with an API product mindset in place should best prepare you for a faster and more flexible approach to enabling these integrations.

How does design-first, or spec-driven development, support an API product?

In more traditional software products, we always try to build with a mindset on user experience and apply design techniques that ensure consistent and obvious design patterns with a focus on ease of use. Developer experience is no different in those aspects, but can have a far greater business impact in the ability to connect your business to other platforms, increasing your sphere of influence.

If your APIs are purely designed as engineering artifacts, the experience for consuming developers is likely to feel “engineered.” Even for APIs intended only for internal use, a poor developer experience could lead to weak adoption, minimizing the chance of building shared leverage and stronger API capabilities inside your company. For externalized APIs, a poor developer experience could lead to a failed business opportunity and ultimately harm your company’s reputation.

Beyond producing a quality developer experience, there are practical time-to-market and efficiency advantages to a design-first approach. If an API is developed without forethought, and review is only achievable once development is complete, design changes can become very costly, producing delivery delays. Furthermore, having API designs and mocks discoverable before development (typically in an internal developer portal/catalog) can avoid duplication of effort. With a code-first approach, there is always the risk that multiple teams will develop similar or overlapping functionality, creating a future redevelopment need.

How do you best iterate and evolve such a product?

One of the primary advantages of applying product thinking and designing an API before development is that these designs can be shared with key stakeholders much earlier. Engaging future end users with API designs and mocks can produce high-quality feedback before development has begun, avoiding costly changes that often occur when feedback comes too late. Abstract designs are easy to change; code is not.

Once APIs are released, especially in an externalized context, change is harder to manage than most products. Ensuring backward compatibility is critical to avoid breaking all consumers of the API. This is another reason why thinking far into the future and validating assumptions early with key stakeholders is so essential. You really want to do your best to get the core capability defined strongly enough that it can be an evolvable concept.

Of course, the likelihood that we build any perfect software is quite low, so it’s best to prepare for change. While we always want to avoid breaking changes to backward compatibility, part of your standards for API design should include versioning. If the original API product is well-designed, most changes should be backward compatible and will not require major version changes. However, you do not want to be in a position where you have to inform a network of consumers that they need to coordinate a breaking change all at once, so have a versioning strategy in place for when the need arises.

Why are you excited about Platform Summit 2023? Assuming you are. 😉

Nordic APIs has built a strong community over the years by always producing consistently great content on the subject of APIs from a wide variety of contributors. The Platform Summit is always well organized, treating speakers with the utmost respect. As such, there is always a strong showing of well-respected voices in the API community, both in terms of speakers and attendees. I have attended most of the Platform Summits and have always returned from Sweden inspired by sessions and discussions with really smart folks.

While I always encourage the organizers to pick a different month (it’s already so dark in October, and the summer is so lovely in Sweden!), Nordic APIs Platform Summit is my favorite API-centric conference of the year, and I always look forward to the inspiration I know it will produce.

What do you hope attendees take away from your session?

I hope attendees will leave with a strong recognition of the strategic importance of APIs and return to work armed with approaches to build support for APIs to be treated as products. Building business support for this is most essential, and we will talk about approaches and concepts to build this support. For those attendees filling the role of API product manager, they will also learn some practical strategies for how to build quality into their API development process.