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

If we were discussing this live, I’d first ask what exactly are you pushing back on, and why? The context matters. Like any feedback, input should be evaluated based on its quality and relevance, not just who it comes from.Start by clearly defining your target user segments. Once that's established, you can assess how closely your engineering team aligns with that profile.For example, if you're building a SaaS product for enterprise SaaS engineers, then there’s strong overlap. In that case, you’ ...Read More

This is a common misstep for everyone, PMs included. I’ve certainly been led astray by assuming I know what users want. It’s important to have empathy for users, but not to confuse our own experience with theirs. That said, engineers often have valuable insights because they understand what it takes to build and maintain a successful API. Their perspective should absolutely inform your decisions, but not replace direct learning from users. The best approach is to observe real users, validate ass ...Read More

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/ ...Read More

"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 ...Read More

This comes up a lot on teams that build for developers. It’s great when engineers are close to the problem, but personal experience is not a substitute for user research or product strategy. Being the user doesn’t remove the need for empathy, validation, or iteration. In fact, it raises the bar because we’re at risk of building for ourselves instead of our users. Here’s how I usually frame the conversation: Your experience is valuable, but let’s validate it. Instead of pushing back hard, I try t ...Read More

That's a nuanced challenge unique to API and developer products, where your builders are often your primary consumers. My approach, refined at companies like Microsoft while building developer platforms, isn't to "push back," but to shift the discussion from personal preference to validated, market-level customer needs. I agree that if our engineers are the precise Ideal Customer Profile (ICP), their firsthand experience is a high-fidelity data point we must capture as the customer truly knows b ...Read More

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 ...Read More

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: Gather data: Use data, such as custom ...Read More