Learning to Fly From a Book… Doesn’t Work

When I first started working in product, I was a junior Product Development Manager (PDM) working on a public-facing website. My boss was an experienced product manager and an excellent mentor and suggested many great books and blogs for me to read on product and marketing. As I learned the basics of product management, I was able to apply them to what I was working on every day.

In time I moved to a new role where I had my very own product: a collection of APIs that are used by all the company’s client-facing products. It was great! And, slightly unnerving. I didn’t know much about APIs at the time, but I had confidence that I could figure it out with practice. I had read lots of books and had done some of the work before, so why not?

It was a little bit like when Hermione Granger learns that she can’t learn to fly a broomstick just by reading about it. For those who don’t know the Harry Potter series well, Hermione is known for reading her textbooks ahead of time and then waltzing in and acing the class with ease. When the kids go to their first flying lesson, though, she realizes that her book-smarts alone won’t cut it. And that was me trying to apply the usual product tricks to my work with APIs.

It wasn’t that the normal product strategy advice didn’t apply at all, but it took me a while to figure out how to make it practical in the world of APIs. Because the product wasn’t as tangible as a website or an app, it wasn’t immediately clear how my users were different and that I needed to adjust my approach. My solution feels instinctual to me now, but I struggled to adapt to this when I first started. So, here are some of my thoughts on how to tackle product strategy when you’re the product manager of an API.

Two Sets of Users…

In product management, users are always your north star. As you ask them questions about what they need to do and gather data on how they’re actually using your product, you learn what their problems are and solve them. It’s not as simple as it sounds, but it’s straightforward: center your efforts on your users and their issues, and it’s hard to go wrong.

That said, APIs usually have two distinct groups of users: developer users and end users. And if you’re not thinking about them both, you’re going to run around in circles and wonder why you’re not progressing the way you’d like to be.

Developer users are going to directly interact with your API, calling it from their code. Your developer users care about whether your API is easy-to-use or well-documented; they’ll care that it’s RESTful, that it has quality DX, that it’s not unnecessarily complicated, and that it performs well whenever they call. Developers want your documentation to be the ultimate in self-service because so they don’t have to ask you questions all the time. In truth, they want the API to be like something they would have built themselves. Depending on your business model, these developers might be internal or external developers at a company that’s going to use your API.

End users will benefit from your API through some kind of interface: sometimes, that’s a product that your company has built, and sometimes it’s an interface that your client built and will plug into your API. Even if these users are technically proficient, they’re likely not going to know (or care) about your API when they’re using the end-product. They just want what it can do for them to happen as quickly and invisibly as possible.

It’s clear that these are two groups of users with distinct needs and goals, whose jobs feel very different and whose user problems don’t really look alike. How do you meaningfully serve them both?

If you spend your time focusing on developer user problems, you’ll spend a lot of time on technical and operational enhancements. It will be an API that’s very easy to do business with, but it won’t necessarily be delivering on the end-user experience that will really move the needle – or even get a mention in the release notes. Alternatively, if you spend your time delivering nothing but the features that both the end users and your senior product leaders will get excited about, you’ll soon build yourself a stack of tech debt that will never get resolved. Your own developers will start to let you know how unhappy they are with the API they’re building and maintaining – and their grumbles will reflect the dissatisfaction felt by external developers.

…Two Roadmaps.

The solution I’ve found for this challenge is to accept that you need to have two roadmaps. This means identifying user problems for both sets of users, giving your developers the details they need to create good solutions for those problems, and mapping out two streams of work.

The next step is every product person’s favorite: prioritizing. You’ve likely got loads of stakeholders who will tell you what the right priorities are, and your job is partly to defend your choices based on what you know about your users and your market. With two distinct sets of users, your job is slightly more complex. Ideally, you want to balance between developer users and end users as evenly as possible.

There will always be plenty of work in both stacks and, when time or resources are short, you’ll inevitably face a situation where you can’t balance them equally. At that point, you’ll have to favor one group over the other. They aren’t conflicting per se, but they will lead your dev team in different directions when it comes to the work they’re doing. When you must choose one over the other, always prioritize the end-user – but never at the expense of your developer-users. You should always be listening closely to your technologists, and especially in these prioritizing moments, pay close attention to their suggestions on the right way to get through feature solutions. As a product person managing APIs – and serving developer-users – your technologists are one of your very best resources for candid conversations about what (not) to do.

One way to visualize multiple product roadmaps

The diagram above demonstrates one method to visualize your product roadmaps. In it, each swim lane is a project, which is taken from a list of defined user problems. These could be end-user problems or developer-user problems. The “Category” column lets me mark the project’s primary type/impact: is it UX? Is it a tech/ops improvement? Is it driving revenue? I use four categories overall, but one could use as many as makes sense. The “Primary User Impact” column is a clear binary: is this mainly affecting End-users or Developer-users? Some projects will impact both, but there’s always a primary. Lastly, the color-coding of these elements lets me quickly see how I am balancing the two different stacks of work.

Finally, I’ll add a note on format: you can keep everything in one mega-roadmap file with multiple swim lanes if you want, or break it out into two separate product roadmaps, or any structure that works for you. As someone who maintains three formats of the same roadmap, I’m not here to tell you the One True Format that your roadmap should have. Let the aesthetic choices be whatever you (or your Executive Leadership Team) want. The important part is to understand how these users are distinct, to clearly describe their user problems, and to create two parallel streams of work so that you can consciously create solutions to support both sets of users without either group losing your attention.