Why are you building that API?
It’s a fundamental question to ask yourself before building anything. If you want to build APIs that provide value for your customers, consider putting product thinking into practice. Make changes that will allow you to build APIs strategically and ensure that every team aligns around business goals.
In a recent API Intersection Podcast, host Jason Harmon (Stoplight CTO) and Brian Otten (Axway VP of Digital Transformation Catalysts for North America) discussed product thinking and creating APIs based on a common definition of value, so we wanted to dive further into the topic.
Think Strategically to Deliver Better API Products
Having an API strategy enables the alignment of technology and business teams around business objectives. This alignment means that every team works together to maximize the value of every API your organization develops. It also helps ensure that you build something of value for your customers. In the podcast, Brian mentions talking to a big energy company, the team telling him that:
“Our problem is, we’ve got lots of teams doing APIs, but they’re doing them in so many different ways. And when we start to look cross-functionally across the organization or the enterprise, it’s hard to really start to combine these APIs and build something useful because everybody has done it in a different way. That adds up to time spent, which is a cost.”
As part of your API strategy, we recommend treating your APIs as products, which means you design your APIs to solve specific pain points for consumers. It also means you talk about the value proposition of that API before you decide to build it. Having a value proposition helps inform your API design and allows you to create an API for more than one type of consumer.
So how do you define the value proposition for your API?
Amancio Bouza published an excellent post on his blog answering this very question — “How to Create the Value Proposition for an API Product in 5 Easy Steps.” The blog post explains how to use a Value Proposition Interface Canvas (VPI Canvas) to show how you’re creating and providing value with your API for customers.
Before defining the value proposition though, you should recognize that an API product lifecycle is not one cycle but 3 distinct cycles:
- Business operations — This is where people come up with ideas, innovations, and applications for the API. They also determine the functionality and features needed to make their customers happy.
- DevOps — An operational process where people want to develop APIs or applications faster, mainly through automation. The aim is to deliver releases and updates consistently and continuously.
- Product operations — This is the missing piece in many organizations. Product operations is the opportunity where business product professionals and technology product experts come together to work out the details of the API, determine the value proposition, and think about the problems it needs to solve.
So how do you encourage product thinking across your organization? Well, an increasing number of organizations have hired an API product manager.
Is Your API a Product If You Don’t Have an API Product Manager?
We’re starting to see the rise of the API product manager, a title that is becoming more common among organizations developing APIs. Jason explained this trend in the podcast:
“We’ve seen the trend of API product manager titles popping up now in a way that even two years ago you didn’t see. And we’ve seen examples of the practice of designing an API from scratch is, in some places, being conducted by product managers, even though they don’t have any technical background. But the guardrails are put up in such a way that they’re able to design something, to pass the tests, and it should be close enough that the team can massage it from there.”
The API product manager is a function more companies now need, but what exactly do they do? The short answer is they manage the design, development, and deployment of a company’s APIs while also ensuring those APIs provide value to all stakeholders.
The API product manager is a multidisciplinary role. It requires a range of traits, such as literacy in API metrics, empathy for developers, and understanding the needs of stakeholders.
API stakeholders consist of four main groups: providers, customers, consumers, and end-users. The API product manager needs to work with stakeholders to ensure the API provides value to all, a goal that requires the manager to complete many tasks and duties.
Do You Need an API Product Manager?
The API product manager plays a critical role in producing high-quality, valuable APIs. But what if you don’t have one? You may be able to achieve some of the same goals with other API collaboration models, such as:
- Single Cross-Discipline API Team — A single team that includes a range of disciplines, skills, and functions similar to a product team.
- Designated API Representative — Have an API representative on every engineering or product team, plus an API oversight committee.
- DevOps-Focused Governance Model — An automation-centered approach that requires some DevOps expertise on each engineering team. It’s well-suited for deploying API changes quickly and smoothly.
These collaboration models can help you produce consistent, well-performing APIs. However, without an API product manager, it may be challenging to instill a product mindset within your teams. You can encourage a product mindset by:
- Using design-focused tools that help make cross-functional collaboration easier.
- Including metrics that measure product success in regular project reviews.
- Taking an API design-first approach and getting design feedback from API stakeholders early and frequently in the design process.
Treating your API as a first-class product doesn’t depend on a single job title or set of tools. It’s a mindset and a set of habits that you need to cultivate over time. Once you’ve figured out your approach for implementing product thinking and an API product strategy, you’ll need to set your API objectives.
Set Objectives Based on Real User and Product Outcomes
You need to set clear objectives for each API, which can help you establish product thinking. An Axway blog post explains why setting clear objectives helps:
“The best objectives are those that relate to how customers interact with your company and your product. By doing the work to develop clear objectives, your roadmap contains a set of customer-focused initiatives, not just a wish list of features.”
What are the clear objectives for an API? The answer varies from company to company. Typically, organizations set business objectives that revolve around API adoption, engagement, and retention.
- Adoption — Once you’ve launched your API, you’ll likely focus on driving adoption and monitoring the consumer growth of your API. Your efforts will revolve around expanding the user base of your API.
- Engagement — Once you have more API users, you can focus on engagement and finding ways to encourage users to use your API more.
- Retention — To make sure people keep using your API, set objectives that will encourage product retention.
Before you can set clear business objectives, however, you need to ensure that every team understands the API’s value. Brian says in the podcast:
“Converging on the common definition of value — that’s where I think a lot of the technology people struggle. I certainly remember throughout my career trying to be a technology team and thinking about:
- “What is the value of what I’m doing here?”
- “What is going to move the needle for the business or not?”
- “How are we going to track it?”
- “Are we going to have a bunch of operational metrics in our API platform that we have to then piece together to make sense of it?”
It’s really hard retrospectively to do that [converging on the common definition of value] if you haven’t thought about that up front.”
Organize Your Technical Teams Around Products
When everyone on a team has the same technical function, they tend to set technical objectives, such as improving latency or creating and maintaining documentation. Product-focused teams bring multiple functional perspectives and focus on shared goals and objectives based on desired outcomes instead of pathways.
In the podcast, Brian and Jason discuss organizing tech teams around products, not systems. “We’re starting to have organizations move to a product organization,” Brian explained. “One pharmaceutical company that we’re working with, we just happened to start helping them with their API strategy program at a time when they were already starting to think about reorganizing their technology teams along product lines rather than systems.”
“Previously, you might have — we’re the SAP guys. We manage this backend and all the master data. But now they’re starting to think we own the capabilities for business partner data, vendor data, customer data, orders, invoices, and things like that. And it gives them a chance to really see their place and start to get some accountability and ownership there,” Brian said.
You need to align all of your teams around products. Business teams, vendor teams, partner teams, engineering teams — all working together around API products instead of working in isolation and around systems. Enabling cross-functional collaboration and fostering strong relationships among all these teams is vital to building consistent APIs — and the right tools can help you achieve this.
Enable Product Thinking with Collaborative API Design Tools
Enabling product thinking and aligning teams around business goals is much easier when you have API tools designed with collaboration in mind. For example, Stoplight allows you to bring stakeholders together in a single platform and collaborate on API design and development in real-time. API program leaders, team members, and stakeholders can also collaborate anytime (real-time or at their leisure), from anywhere. Make your APIs feel like products for stakeholders through collaborative API design tools that speak their language.
Want to learn more? Check out our demo. And don’t forget to listen to the API Intersection Podcast that inspired this blog post!
