Walk into most B2B product reviews and ask "who owns the API?". The answer will be an architect or an engineering lead. Ask "who owns the UI?". That's the PM. The split feels natural. It's also why so many B2B products end up with a UI that delights and an API that frustrates, and a team that wonders why its power users churn.
If your customers integrate your product into anything (workflows, automations, other tools), your API is your product. The UI is a wrapper. The API is what sets the ceiling on what a customer can actually achieve with you.
Why this gets misframed
The API ends up in engineering's lane for a procedural reason. It has a schema, and schemas live in code. So the decisions about endpoint shape, naming, pagination and error model all get made during implementation, by whoever is writing the route handler. The PM weighs in on what the feature does. Nobody asks them what the API for that feature should look like.
This is a category error. The endpoint shape is the product surface. Naming, pagination and the error model are exactly what an integrator is fighting at 2 AM when their workflow breaks. When those decisions get made, the PM should be in the room with the same weight they'd carry for any user-facing design choice.
The integrator is a user
The mental model I use to fix this is simple. The developer integrating your API is a user with a job to be done. They aren't "engineering". They're a different persona from your UI user, and they measure success differently: time-to-first-successful-call, number of failed retries during onboarding, hours spent reading docs before giving up.
Once you frame the integrator as a user, the API decisions stop looking like architecture and start looking like UX. Inconsistent naming is a UX bug. So is a vague 4xx response, and so are the missing examples in your docs. You wouldn't ship a UI without a thumbnail. Don't ship an endpoint without an example payload.
What ends up on the roadmap
When the API is on the product roadmap, you start tracking things you wouldn't otherwise:
- Time-to-first-successful-call from a new dev account
- Top error codes returned in production, by frequency
- Doc page bounce rate and which pages get bookmarked
- Endpoints with zero customer adoption (dead surface)
- The ratio of dev-portal sessions to integrations going live
None of those surface if engineering owns the API and the PM owns the UI. They're all PM-shaped questions. Where do users fail, where do they succeed, and what's the gap between the two? The instrument is different, logs and dashboards instead of session recordings, but the discipline is the same.
The AI agent angle
The argument for API-as-product has gotten sharper in the last year because of AI agents. When a coding agent (Claude, Cursor, an internal copilot) integrates your API, every UX failure compounds. The agent doesn't read your docs sympathetically. It pattern-matches on whatever is there, and then it either succeeds or gives up. APIs that are inconsistent or under-documented score badly when an agent is the user.
The PMs I see leveling up fastest in 2025 are the ones who own this end to end: the endpoint shape, the docs, the LLM-readable surface (llms.txt, MCP servers, structured examples), the metric for time-to-first-call.
A practical move
If you're a PM on a B2B product and you don't own the API surface today, ask to. Ask to be the approver on new endpoint shapes, on error-model decisions, and on the developer documentation. You aren't taking work from engineering. They still write the code. You're making sure somebody who thinks in user journeys reviews the design before it ships.
The first time you reject an endpoint name because it breaks the convention three endpoints over, you'll know you've moved the line correctly.
