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.