For API products, how do you push back against engineers who believe they know what to build because they "are" the target user?

I think that the whole team should strive to build a product that end users love. I love when there's passion on the team and ideas about what to build. When you are building a product for a persona that is close to you, it's important to gather data from end users to ensure that you have a complete picture of their needs. 

This generally comes in two forms:

Problem Validation: Identifying your end users' pain points. This can also be confirming of a problem hypothesis. https://about.gitlab.com/handbook/product-development-flow/#validation-phase-2-problem-validation 

Solution Validation: Ensuring that the solution will meet end users' needs. https://about.gitlab.com/handbook/product-development-flow/#validation-phase-4-solution-validation 

Sharing customer learnings with your team goes a long way in helping get alignment about what you are doing and why. I like to post summaries of my findings on our team Slack channel and document my detailed findings in places that are accessible to the whole team. Ultimately, product managers are responsible for the product roadmap, but collaboration is essential! Some of the best ideas for features I've worked on have come from other team members. 

"Push back" is a strong term. With developer tools, you can't just discount what your engineering team says out of the gate, since they already have a lot of built-in empathy for the target customer. So listen to them carefully but remember (and also tell them) that they are unlikely to be right 100% of the time.

What you have to do in this situation is to elevate it to use cases. Developers paying for the product aren't just sitting around calling APIs for fun. They have an objective in mind as those API calls support something else they are trying to do. Bringing those common use cases to your engineering team ("here are the 15 customers I talked to in the last 4 weeks who are trying to paginate this way because of reason X") helps them to gain more empathy.

Finally, it can also be very instructive, particularly for dev tools products, to have engineers sit on customer development calls. That way they can have an engineer-to-engineer discussion. As the PM, you just have to moderate, so that it does not devolve into a pissing match of who is the better engineer, which can sometimes happen when engineers get defensive about what they have built.

As a product manager, it's essential to consider the perspectives and expertise of all team members, including engineers. However, it's also important to remember that as the product manager, you are responsible for representing the needs and interests of the target users and ensuring that the product meets their needs.

Here are a few strategies you can use to push back against engineers who believe they know what to build because they "are" the target user:

1. Gather data: Use data, such as customer feedback and usage metrics, to back up your perspective on what the target users need. This can help to provide a more objective view of the situation.
2. Emphasize the importance of user research: Make it clear that user research is a crucial part of the product development process and that the insights and perspectives of the target users should be given weight. It's too easy to assume we know what customers want if we have been on the customer side before or identify with their needs. This is a common trap that all of us have to work against actively.
3. Encourage collaboration: Encourage engineers to work closely with you and other team members (design, research) to better understand the needs and perspectives of the target users by participating in interviews and surveys. I've found it helpful to record user interviews and share snippets of the recordings and the transcripts with the entire product team to foster customer-first thinking.
4. Communicate your perspective: Share your perspective on the needs and interests of the target users, and explain how the proposed feature or update aligns with or deviates from those needs. Centering the conversation on the customer, their context, and their problem helps to shift conversations back to the actual customer.

Ultimately, it's important to foster open and respectful communication with your engineering team and to work collaboratively to find solutions that meet the target users' needs while also considering the product's technical constraints and capabilities.

I encountered this and similar scenarios with numerous teams, with successes and lessons learned. As others echo, successful public APIs (I’ll define success as achieving adoption externally with positive feedback) have APIs designed based on validated use cases for external developers (commonly termed  “Design-Driven APIs”), rather than publishing what’s used internally.

Sometimes it's a simple matter of explaining Design-Driven API principles with examples, but often it's more complicated. To make the case for a design-driven approach effectively, it’s important to  first listen to others and understand their perspective, then make your case with love and data.  That also means not looking at this as about “pushing back.”

Firstly, I've come to understand a spectrum of opinions on this topic by those who don’t support design-driven principles, including but not limited to:

• A belief that building separate external APIs is inefficient, and already built APIs should work.

• Engineers who look forward to collaborating with PMs on APIs, but want to be involved in their designs, and perhaps feel left out.

• A more territorial, political motivation, to maintain ownership of a product area.
  

For the first case, a genuine opinion that “I’m the user,” the matter can be handled as I would with a very junior PM who’s acting on gut rather than validated feedback. It may be easily handled by listening, then sharing stories that show how another developer may have a different use case. 

Or, perhaps an engineer has a specific idea based on their experience, in which case you can 1) make sure they feel that their idea has been heard and 2) encourage them to gather data or talk with an external developer to validate that their idea will work with others. Perhaps offer to help them conduct this research.  They can experience Product process and see for themselves the need for validation, and also see exactly why their ideas may not work for a public API.

For the second case, which I’ve commonly seen, it’s up to the PM to change their perception and process.  Rather than designing APIs and assigning tasks to Engineering to implement them, bring your Engineering team into the design process. I like to share the feedback I gather and work together on the API design itself. 
 

The third case is the most challenging. I’d first emphasize not to try to win with facts.  It’s not about what’s in the company’s interest in this case.  Sometimes you can build rapport, if not with a primary opposition still with other stakeholders. I’d also categorize this as more a politics problem that PMs commonly have to deal with, for which I can recommend several books.  It’s out of scope for this question.