I heard that somewhere and the phrase stuck with me. I guess many people would consider PM to be an interface to the engineering team. For the majority of business functions, an engineering department is kind of a black box. They send requests there and after a while, might get some features back (not necessarily in any way related to the things they've requested).
And if people try to inquire into an engineering department work, chances are high - they will get confused. The jargon is unbearable and most of the questions get answered with "it depends". Obviously, that's not a nice situation to be in. So the business leaders hire product managers. They could speak both technical and human languages and so can translate between engineering and the rest of the org.
However, it's still pretty tricky to know what those PMs do exactly. Especially, what can they do for you? What can you ask? How? When and what kind of a response you can expect?
Welcome - PM as an API to the engineering team
An application programming interface (API) is a connection between computers or between computer programs. It is a type of software interface, offering a service to other pieces of software.[1] A document or standard that describes how to build or use such a connection or interface is called an API specification.
Let's try to imagine an API specification for a PM.
Communication
In the API world, there is an agreed universal standard to exchange data - JSON. In the PM world, people might prefer different ways to exchange data. Some like written narratives, some in favour of visual artefacts (mockups, prototypes), others might prefer presentations or verbal agreements. Before interacting with a PM it's advisable to check what communication method they prefer. This would make the whole process faster and more enjoyable for everyone.Methods
Those are some of the ways how you can interact with a PM. "Get" means you're requesting information, "post" is you submitting and "put" is updating existing data.Get market insight
Probably the most important method that so rarely gets used. Product managers are experts on their customers and the market. If you need an insight into a particular customer or looking to understand the overall industry trends - try this method and the results might surprise you.The types of responses you can expect for this method:
- 200 Success - you'll receive back the information you need, including but not limited to the first-hand customer interview notes, number of customers it might affect, competitors intelligence.
- 404 Not Found - the requested market insight doesn't exist. Maybe you have it? Enlight the PM - they would be forever grateful.
- 502 Bad Gateway - you might be asking the wrong PM. If that's the case you'll get redirected to the right one.
Post a product request
Probably the most common request to a PM. However, the success of this method would totally depend on how well it's structured. Your PMs would appreciate it if you can include into your product request the following:- What do you want the product to do?
- Why do you think it needs to get done?
- Who will benefit and how?
- 200 Success - a product request has been placed in the backlog (later you can use a "get" request to find out about the status of your request)
- 400 Bad Request (more information needed) - usually comes with the description of the additional insights PMs expect to properly assess the request.
- 503 Service Unavailable (priority conflict) - your request could be great and valuable but the engineering team might be busy with other, similarly important work. In this case, you'll get an appropriate response from the PM.
Put a bug description
Shit happens so as the software bugs. If you find something that doesn't look right - you need to make your PMs aware. Use this method to update the information about a problem you've encountered or an improvement you envisioned. Your PMs most likely will ask you for a detailed report, this will help them to locate and fix the issues efficiently and quickly.The types of responses you can expect for this method:
- 404 Cannot reproduce - a PM or/and a QA will follow your instructions to reproduce the issue in order to investigate it. If they couldn't get the results you got - they might discard the request. Add screenshots or a video to your put request so PMs can see the problem with their own eyes.
- 202 Accepted - your report is noted and will be prioritised for fixing/implementing. You can inquire about its status later.
- 303 See Other - a similar issue/idea already exist. The information you provided might be merged with it and you'll still get the outcomes you want.
Delete a backlog item
Some people treat the product backlog as a bottomless, all accepting pit. It is not. When product backlogs become too big, they turn unmanageable. hence it's super important to not only add things to the backlog but also to remove irrelevant ones. You can help your PMs to do that. A customer was asking about something but recently went quiet? - tell PM about that. A major competitor announced a feature but still hasn't released it? - tell PM about that. Help your PMs to keep the backlog lean and healthy, you all win benefit from that.The types of responses you can expect for this method:
- 410 Gone - the backlog item has been removed, either on your request or previously. You can additionally ask what took its place.
- 425 Too Early - the evidence to remove an item might be too think. So the PM might keep it for a little longer in the backlog to see if it could become relevant again.
- 301 Moved Permanently - the backlog item might be moved to another place (team, discovery backlog). It could return under certain conditions which you can discover with a separate request.
A few bonus responses worth knowing
- 408 Request Timeout - PMs are a notoriously busy bunch. Some requests you'll send will inevitably timeout. Don't get discouraged - if your request really is important, try resending it again.
- 418 I'm a teapot - PMs are resourceful but even they cannot brew coffee in a teapot.
A bit of structure never hurt nobody
- Should I really talk to my PMs as a robot? - you might ask.And the answer is obviously no. If PMs really were just APIs - engineers would have automated them by now (and made them deny all the requests by default). What helps is a healthy balance between structured and spontaneous communication between the business and PMs.
And for PMs, it might be useful to create such a pseudo API specification to help other departments to communicate better with you. At the end of the financial year, you all want the best for your product and effective collaboration is the key to that.