Technical Product Manager

As more products came to be used by developers rather than by people looking at screens, the existing approach stopped applying. An application programming interface (API) is an agreed channel for programs to exchange things through, and a product made only of those has no interface to look at. The vocabulary of screens and buttons that requirements were normally written in simply doesn't apply.

With nobody owning that, the specification gets decided by whoever implements it, and each team decides differently. One returns errors as numbers, another as sentences, and a developer integrating with two products from the same company has to learn both conventions. Changes are worse. When a customer's engineer asks why one field disappeared from a response, there is nobody to ask, and their service is already down. The cost of that lands on someone who never chose the shape of the thing.

A technical product manager (TPM) exists to fill that seat. Among the variations of the product role, this is the one whose territory narrows to technical products. Specifications get decided instead of screens, integrating developers get met instead of end users, and more time goes into not breaking promises already shipped than into adding new things. That last part is the part the job is usually judged on.

A day is made of reading and writing specifications, talking to the people integrating, and managing the schedule for anything changing.

1. Decide the specification and write it down. Which fields come back for which request, what error a malformed request receives, sentence by sentence. Whether to add one field to a response can be the day's main decision, because a field that has shipped is hard to remove once anything depends on it, and you rarely find out what depends on it until it is gone.
2. Meet the developers integrating. Customers' engineers and integration partners. They tend not to report that something is awkward — they build a workaround and move on — so problems only surface if you ask how they're actually using it. A workaround in the wild is a design flaw nobody reported.
3. Manage versions and removal dates. Splitting the specification so a change doesn't break existing users is API versioning, and announcing something in advance to discourage its use is deprecation. What gets announced this quarter and when it gets switched off is decided in this seat.
4. Read usage records. Which request arrives how many times a day, whether one customer is calling in bursts. The numbers in a rate limit policy — how many requests are accepted in a window — get set here too. Raising 60 calls a minute to 100 weighs server cost against how customers actually use it, and both numbers come from records rather than from a negotiation.
5. Fix the documentation and the examples. On a developer product the documentation is the sales material. Cutting integration time from two days to two hours moves conversion directly.

With no screens, the output is sentences and specifications. Asked to show what got built this quarter, this role quite normally answers with three response fields and a scheme for error codes. Neither of those demonstrates well in a meeting, which is a real part of the job.

The closest counterpart is the tech lead, the role that steers technical direction and implementation quality. The boundary generally falls along what versus how: which fields go into the specification is decided here, and how that gets built is decided on the other side of the table. Blur it and the specification ends up shaped by what was convenient to implement, leaving something odd for the developers who use it.

Outside the company, the counterparts are the integrating engineers and the salespeople who own those contracts. Enterprise customers lead with technical questions during the deal. How much response time is guaranteed, what goes into the service level agreement (SLA) — the service level promised contractually — comes up right there, and the answers get built here.

With the product manager who owns the product with screens, features often get split across both. A new capability on screen usually changes the specification underneath it. Get the sequence wrong and the screen ships while there is still no way to do the same thing from outside, and the gap gets reported by a customer rather than noticed internally.

"If we drop this field, how many customers break right now?"

A request to count the blast radius before changing a shipped promise.

"We'll announce v1 ending in six months and run both until then."

Setting a removal schedule that gives existing users time to move.

"That one should ship as a specification before it ships as a screen."

The integrating side needs it first, so the order should change.

When Pagedeck opened document search to outside callers, this role's judgment showed. Theo wanted to expose the search results in exactly the shape used internally — it was easy, and it already worked.

The TPM declined to publish that shape. The internal one carried fields likely to change later, and once published, every change to those fields would break the companies integrating. A separate specification was drafted using only the fields that would hold, shown to six integration partners in advance, and finalized after their comments came back. Sofia attached the resulting document to the enterprise contract material as it stood, since it answered the questions buyers had been asking anyway.

The most common mistake is assuming the seat requires a background in engineering. The subject is technical, so it looks like you'd have to be able to build it. But the job is reading specifications and explaining decisions, not writing code. What's required is understanding what breaks when a response field is removed, and being able to explain that decision to the companies affected. Reaching further and doing the implementation overlaps with the tech lead's seat, and then decisions come from two places.

Reading it as project management for engineering is the other one. The word technical suggests schedules and coordination. But what this role answers for isn't the schedule — it's whether the specification was worth shipping. Ship a channel on time that nobody calls and the responsibility stays here. Watch only the dates, let the specification follow whatever was convenient, and two quarters later the same thing gets rebuilt while every integration built in the meantime has to break.