The role of a web API product owner is still pretty nebulous, largely due to the fact that it’s a relatively new position. That’s interesting, because anyone keen on API business development knows just how valuable such a position is. A great API product owner can be hugely beneficial, and can leverage the product’s strengths to greater heights.

In this piece, we’re going to discuss what qualities make a great API product owner, and what these qualities mean to the development process as a whole. Once you’ve finished this piece, you should have a solid understanding of these qualities, and a basic rubric upon which they can be compared and contrasted with your candidate of choice.

Why API Product Ownership is Important

API product ownership is an important facet of modern web API team organizational structures. Despite this importance, the relative newness of the role is such that, even when the value is recognized, what makes a good placement is not as obvious. Having someone who can both manage a team and a product is powerful — having someone who can do that while also evangelizing your project internally and externally is exponentially more so.

There’s a difference between “getting something done” and “owning a project,” however, and it is this distinction that makes a position placement either a big win or a massive failure. Ownership of a project and all the elements of that project have a sort of cascading effect that can be more powerful than the sum of its parts, boosting productivity, improving organizational well-being, and creating a culture of personal accountability.

But what specifically does an API product owner position even entail? And more importantly, what elements are to be expected of a person in such a position?

Developer vs. Product Manager vs. Evangelist — When Worlds Collide

The classic paradigm of digital product creation is a battle between developer and manager. Developers try to create something they believe in that is functional and high quality. Product managers, on the other hand, are trying to meet business goals, trying to ascertain the true value of the product that others would be willing to invest in it. Evangelists occupy an entirely different, unique space. They come from a technical background but are often more concerned with generating awareness, both internal and external.

This outlook is old-fashioned, but it worked in past eras of development. The new developmental situation, however, has rejected traditional roles in many cases, with small studios and groups having more tools and better funding than ever before to create unique, personal, and often niche solutions.

In this new paradigm, the old-fashioned approach simply does not always work. The new development ecosystem often entails product managers as developers, evangelists as developers, and so forth — and as those lines have blurred, so too have the positions that occupied those spaces. With developers having to wear so many hats by the very nature of the development cycle, API product ownership — as a concept and as a “position” within a company — can entail many things.

With that in mind, let’s look at some of those important attributes that define this role.

True Leadership

“Focus on constant iteration of your product or service. Never hold too closely to your idea but be open to change and innovation.”

– Candace Carpenter

An API product owner is not just selling an API, but everything behind it. For developer consumers, value is the sum of the support offered, the experience of the developer team, the developer support, the documentation, and other developer portal materials. All of this extra value, however, is directly powered by the leadership of that team — documentation is worthless, for instance, if leadership does not allow for it to be vetted and reviewed.

Accordingly, the value of a product is magnified by the quality of leadership in the API product ownership space. Product owners must be leaders, and a strong ones at that. They need to take the initiative to develop new projects, be willing to take risks for new solutions, and do all of this while maintaining value for the company and to the user. In short, the old adage rings true — head in the clouds, feet on the ground.

Part of this also means, of course, that the product owner needs to be accountable for their decisions, and able to rationalize these choices in product and project movements to not only the company and the team, but to the user base as well. Clear communication plays a huge role in this, and effective documentation is a big part of this approach.

Proficiency with Language vs. Familiarity with Solution

The balance between proficiency in a given language and familiarity with the implementation type is a delicate one, and one often overlooked. Let’s imagine you are building an API in Go. Now, is your choice of product manager driven more by someone who is a master of Go, or by one who has heavy experience with distributed microservices, but not necessarily experienced in Go?

This is the balancing act that needs to be considered carefully. It might be tempting to look at what your product is built in, and then hire based on language, but this might result in a candidate who is an expert in the language but can barely understand the distributed structure of your microservice family.

Understanding the specific design requirements of an API is a must here, but always consider the attached attributes. If you are designing RESTful applications, you need to find someone versed in JSON. If working with SOAP, then XML is definitely an added benefit. Knowledge of open-source API standards and solutions is important if that is your final intent.

These considerations are vital, and if properly considered, allow for movement if your API ever needs to pivot and change. Having the ability to adjust to the ever-changing tides of web development makes a powerful API product owner even more so.

Marketing vs. Development

“Brand is just a perception, and perception will match reality over time. Sometimes it will be ahead, other times it will be behind. But brand is simply a collective impression some have about a product.”

– Elon Musk, CEO of SpaceX and Tesla

A chief consideration in the API product ownership mindset is whether or not the product owner should be positioned more in terms of marketing or in terms of development. While this somewhat ties into our earlier comparison of development, management, and evangelizing, this is much more a mindset consideration than a job duty one — for reasons that will soon become apparent.

Bill Gates innovated the workplace computer, Steve Jobs innovated the way we consume mobile media, Elon Musk innovated the way we process online payments (not to mention space exploration, and renewable-energy driven vehicles). When people talk about innovators, those names are often attached to the product. The point is that, in the tech space, the product owner is as much a brand as what they are trying to sell.

Accordingly, there’s no such thing as “just” a developer or “just” a marketer in the modern workspace. With the modern ecosystem of development and innovation, the product owner should be just as recognizable as the product itself.

Accordingly, the product owner should have qualities that reflect and enable this. Being able to bask in the spotlight, while redirecting that spotlight to the product, is immensely valuable. Framing the solution with specific business critical use cases is likewise valuable. Being able to oversee development, stand up and say what it specifically is and does, and why it’s needed — that makes a good API product owner.

Team Management

“I have learned that nothing is certain except for the need to have strong risk management, a lot of cash, the willingness to invest even when the future is unclear, and great people.”

– Jeff Immelt, CEO of GE

Team management is a huge part of any organization, but within the API-fueled web economy, this is even more important. With so many remote workers, sometimes located half a world apart, the ability to inspire, lead, and most importantly organize defines successful leaders, and thus successful organizations.

Likewise, being able to identify weaknesses within the organization allows for culling and for making leaner work groups. Restructuring teams, being able to managerially outline working group responsibilities, and delegating the right tasks to the right people are all huge elements that must be done correctly in order to leverage any team’s strengths.

No manager can function by themselves. Behind every Jobs, there is a Wozniak — and in the modern space, it’s more often a requirement that an effective API product owner be both.

In terms of skill set considerations, knowledge and experience with toolsets that enable team collaboration in this space are key. Knowledge of messaging solutions like Slack can be hugely beneficial, and being experienced with task distribution systems like Trello equally so. Even adopting online collaboration IDEs like Squad can mean the difference between team failure or team success.

Experience

“There are pros and cons of experience. A con is that you can’t look at the business with a fresh pair of eyes and as objectively as if you were a new CEO. Fire yourself on a Friday night and come in on Monday morning as if a search firm put you there as a turn-around leader. Can you be objective and make the bold change?”

– Andrea Jung, CEO of Avon

Experience is a yet another nebulous point to consider in balance with other qualities. While it’s tempting to think that experience means success, this is somewhat of a misattribution — experience can also just mean time spent, and sometimes, you may want a greenhorn rather than an expert.

This is very much a balancing game. Too much experience can lead to bias for a given solution or choice, and can result in rote implementations that just only slightly change from version to version. Having too much experience can also lead to complacency, and in some personality types, arrogance, both of which allow for consistent failures to go unnoticed.

Likewise, having too little experience can have damaging effects as well. Innovative approaches from a newcomer may not be grounded in reality, and can lead to some expensive failures. Additionally, while a greenhorn may be more creatively oriented, newer developers or managers can also lack crucial experience, making learned lessons come at a price.

What you really want here is a mixture. A good product manager can be highly experienced, but they must have the mind of a newbie, willing to take risks and do things outside the box. They must be willing to think big, and most of all, be willing to fail.

Meeting Business Objectives

This is not a nebulous concept, and in fact, might be the most concrete of all advice in this piece. Your API product owner must own the product, and thereby, be responsible for and cognizant of the business objectives that have been given to them.

A product owner has a unique position in that they are straddling the world of development and business. While they can see the intimate details of both sides, they must be able to see the larger picture, and where the product fits in that picture. They must be able to guide the project in such a way as to promote the attainment of business objectives, balanced of course by all the other attributes on this list.

Seeks to Understand Developer Audience

Finally, and perhaps most importantly, a product owner must intimately understand their audience. A product is worthless without a user base, use case, and no desire for implementation — thus, an API product owner must be familiar with all of them.

As a point, here, the API owner must cater the API, its marketing, and its approach to promote both the best developer and user experiences possible. This includes everything from beautiful documentation to basic outreach, from error codes to code distribution — everything should be designed to help build a community.

Simply put, the API product owner must act as the unifying node between several diverse points within the community, addressing analytics, the development team processes, marketing and sales, and user experience, with the end goal being at any cost to satisfy the customer base and achieve the goals they desire.

Hiring Internally vs. Externally

While it might seem easy to consider a candidate based on the concepts introduced here, there’s one variable that’s not quite as easy to answer — the question between hiring internally or externally.

On the one hand, there’s a definite value to hiring from internal staff. Internal staff are already intimately familiar with the solution and the language — this saves development time, and definitely helps when it comes to documentation and other practices. On the other hand, this also leads to the issues we talked about earlier when it comes to experience bias — and in this case, new blood can be just as powerful as old.

Outsourcing to Jump-Start

One remaining topic is the prospect of outsourcing the position as a temporary method to jump-start API development or marketing. This is becoming a much more common tactic as years pass, and has been used to great effect for API development. This strategy can allow for rapid initial development, getting the project off the ground. That being said, there are some issues.

Chief of those issues is outsourcing ignores the value of veterans. Having a long-term, proven manager is very important, and cannot be ignored for the sake of a quick fix. While having too much experience can be a problem as previously stated, when it comes to getting a program off the ground, having a proven manager can help give predictable insights into the response you can expect from the community.

With all of this in mind, our advice would be this — jump-starting through outsourcing is a valid approach, but it should be used sparingly. When used, whenever possible, an agreement should come with the caveat that the manager, having proved themselves through successful iteration and launch, becomes a permanent fixture on the team.

Conclusion

We hope we’ve helped illuminate all of the various qualities that make a great API product owner — or at the very least, given a strong rubric with which to judge possible candidates. While there’s no possible way to cover every single possible skill, caveat, and quality, those we’ve discussed in this piece should serve as a solid basis to start.