I’ve been waiting for someone to write a piece like this, thank you for doing so. I’ve been thinking a lot about this topic over the last year and in particular your point around: ‘Which is easier? Teaching an engineer product management? Or educating a product manager about technical concerns?’
My 0.02c, I think both. APIs and API products aren’t going away, so in my view you need both to get on board with the other; what’s murkier to me right now is how it’s actually being tackled on the ground. How is that Inter/intra-team collaboration or, in some cases, trade off, going? Hope you get some inside insights as would love to see them collated.
I would also argue that as APIs enter mainstream parlance more and more, the quicker they will move into the realm of PM. With AI & new no-code / low-code solutions we will soon reach a point where PMs easily launch & manage their own APIs with minimal tech / platform team guardrails. Then they can get onto the fun part: taking those APIs to market!
Few engineers believe that API as a product is feasible because of how their work is funded and/or assigned. They are fine with treating APIs as just another integration technology, because nobody is proving there is a business investment to the contrary. Engineers tend to be grounded in the real world and telling them you want broadly utilized API Products, when you a) have not funded them that way and b) do not have a product manager calling the shots on that product, just reinforces that all you really want is integration by the delivery date. Product Managers MUST be able to identify when exposing technology in the API interface is being proposed (Like using Odata query syntax instead of classic REST approaches) and they must be able to rationally discuss with engineers why that is not a desirable solution approach. All of these things begin with a lack of API Product oriented focus and funding, where the business makes the API a viable "system" that is sustained and maintained and LED by a product owner, just like many of the monolithic legacy systems they have in place. You can't do things like you always have and expect the engineer to be the nexus of change...it simply won't happen.
Is API Product Management a Role or a Person?
Its like you knew the answers I was seeking. Fantastic piece and love that garden analogy 😀
I’ve been waiting for someone to write a piece like this, thank you for doing so. I’ve been thinking a lot about this topic over the last year and in particular your point around: ‘Which is easier? Teaching an engineer product management? Or educating a product manager about technical concerns?’
My 0.02c, I think both. APIs and API products aren’t going away, so in my view you need both to get on board with the other; what’s murkier to me right now is how it’s actually being tackled on the ground. How is that Inter/intra-team collaboration or, in some cases, trade off, going? Hope you get some inside insights as would love to see them collated.
I would also argue that as APIs enter mainstream parlance more and more, the quicker they will move into the realm of PM. With AI & new no-code / low-code solutions we will soon reach a point where PMs easily launch & manage their own APIs with minimal tech / platform team guardrails. Then they can get onto the fun part: taking those APIs to market!
Few engineers believe that API as a product is feasible because of how their work is funded and/or assigned. They are fine with treating APIs as just another integration technology, because nobody is proving there is a business investment to the contrary. Engineers tend to be grounded in the real world and telling them you want broadly utilized API Products, when you a) have not funded them that way and b) do not have a product manager calling the shots on that product, just reinforces that all you really want is integration by the delivery date. Product Managers MUST be able to identify when exposing technology in the API interface is being proposed (Like using Odata query syntax instead of classic REST approaches) and they must be able to rationally discuss with engineers why that is not a desirable solution approach. All of these things begin with a lack of API Product oriented focus and funding, where the business makes the API a viable "system" that is sustained and maintained and LED by a product owner, just like many of the monolithic legacy systems they have in place. You can't do things like you always have and expect the engineer to be the nexus of change...it simply won't happen.