Lessons from Managing API Products at S&P Global

I spent six years at S&P Global, the last three as Associate Director of Product Management for their enterprise data-feed and API platforms. These were products with eight-figure recurring revenue, serving some of the world's largest financial institutions. Here's what that experience taught me — and how it made me a better solutions engineer.

Your Biggest Clients Are Also Your Biggest Product Managers

When your customers are Goldman Sachs and BlackRock, they don't just consume your API — they have opinions about it. Strong opinions. And they're usually right.

The best product decisions I made came from sitting in rooms with the people who actually used our feeds every day. Not from roadmap planning sessions, not from competitive analysis, but from understanding what was costing them time, what was breaking their workflows, and what they'd build themselves if they could.

Pricing Is Product

One of the least appreciated aspects of API product management is pricing. It's not a commercial exercise — it's a design decision. How you price determines how people use your product, what they value, and what they build on top of it.

At S&P, pricing a data feed wasn't just about revenue. It was about aligning incentives. Price per call? Per dataset? Per seat? Each model creates different behavior, different adoption patterns, and different support loads. Getting this wrong is expensive in ways that don't show up for months.

Reliability Is the Feature

Nobody calls you when your API is working. They call when it's not. And when you're delivering market data to trading desks, "not working" has a cost measured in real dollars per minute.

This made me obsessive about reliability in a way that's served me well ever since. When I'm architecting a solution at Conga now, I think about failure modes first. What breaks? What's the fallback? What does the customer see when something goes wrong? Those questions come from managing a product where downtime had a price tag.

What Transferred to Solutions Engineering

Product management and solutions engineering share more DNA than people think. Both require you to translate between technical and business stakeholders. Both require you to scope what's possible against what's valuable. Both require you to say "no" to things that sound good but don't serve the customer's actual problem.

The biggest thing that transferred: the discipline of listening before building. In PM, you do user research before writing a spec. In SE, you do discovery before building a demo. The skill is the same — understanding the system before you try to change it.

The Takeaway

If you're in solutions engineering and you get a chance to do a rotation in product management — take it. And if you're in PM considering a move to the field — you'll find that the skills translate more directly than you'd expect. The best technical people I know understand both the product and the problem. That understanding doesn't come from one side of the table.