Behind the API: Writing, Strategy, and Technical Execution as an Amazon PM-T

The first time I sat in a real Amazon document review, I thought I was prepared. I had written a six-page narrative, run it past my mentor at least twice, and triple-checked the metrics. Then the meeting started, and nobody spoke.

For twenty minutes, the room was silent except for the sound of senior leaders scrolling through my prose, leaving comments in the margins, occasionally pausing on a sentence that didn't hold up. There were no slides to hide behind. No talking points to smooth over a weak argument. Just the words on the page, judged on their own. That was the moment I understood what it actually means to be a Technical Product Manager at Amazon.

The PM-T Is Not Just a PM with a Technical Title

People often describe a PM-T as someone who sits at the intersection of business strategy, backend architecture, and customer trust. That is true, but it sounds grander than the daily reality. The daily reality is that you are the person who must translate a customer problem into a system design, and then write your way into convincing a room full of engineers, principals, and senior leaders that your proposed path is the right one.

During my senior PM-T internship, I owned a data product that served a growing ecosystem of internal teams. It pulled data from several surfaces, including page views and search signals, and every team that consumed it had a slightly different idea of what the data meant, how fresh it needed to be, and what shape it should take. As usage grew, those small differences in mental models became a serious scaling and reliability problem. My job was not to write the ingestion pipeline. My job was to make sure the pipeline we built actually solved the right problem for the right customers, at a scale that wouldn't break down six months later.

Writing Is the Primary Mechanism for Thinking

Amazon's narrative culture is real and relentless. Major proposals usually begin with a PR/FAQ, a document that includes a Press Release written as if the product has already launched, plus Internal FAQs that force you to confront every constraint before a single line of production code is written. The PR/FAQ is perfect for building something new.

But I was not building something new. I was expanding an existing data product. So I started with a BRD, a Business Requirements Document. A PR/FAQ asks you to imagine a future customer experience from scratch. A BRD asks you to define exactly what changes, what stays the same, and what breaks for the customers already using it.

The BRD still made me write my way into the real shape of the problem. If the existing dataset is already serving customers, why does it need to change? What does the change actually signify for the teams downstream? Will the additional records help them, or will they just create noise? What is the business case for expanding the dataset at all? Then the technical questions come. What is the latency requirement? What happens when an ingestion surface changes its schema? What is the cost per query as the dataset grows? Who owns the SLA if a downstream service breaks? For an existing product, these questions are sharper because you are not just designing for a future customer. You are designing around the constraints of every current customer.

It was not just "make the dataset bigger." It was: how do we expand the dataset significantly without silently changing the semantics of a record that hundreds of internal teams already depend on? How do we onboard new ingestion surfaces when each one has its own freshness characteristics, its own edge cases, its own definition of what an impression even means? You cannot PowerPoint your way through questions like that. You have to write them down, line by line, until the logic either holds or breaks.

Strategy, Semantics, and Customer Obsession

Amazon has a culture that pushes you to think big and, when the moment is right, to go big or go home. My project forced me to figure out what that means in practice. The question was not whether we could expand the dataset. We could. The question was whether we should, and how big the bet should be. It sounded like a scaling challenge. It was not. Every new ingestion surface introduced its own semantics. A signal captured from one part of the system is not the same as a signal captured from another. Treating them as equivalent in the data model would have quietly baked assumptions into the system that hundreds of teams would eventually depend on.

This is where the PM-T role becomes technical. I did not need to write the service code, but I needed to understand it well enough to ask the right questions. An early proposal would have made the system easier to reason about, but would have broken the assumptions of downstream teams. Instead of debating in a conference room, I went back to the customers actually consuming the data and asked whether the change aligned with their use cases. Some needed fresher data. Others needed the schema to stay stable. A few did not need the expansion at all. That feedback let us design around real needs instead of theoretical elegance. It was the clearest example of Customer Obsession I experienced in the role: the customer was not an abstract persona. It was the team whose pipeline would break if we got the semantics wrong. That is the operational reality of strategy. Not roadmaps. Decisions about data models and migration paths that other people will live with long after you leave the room.

AI Helps, But It Does Not Own the Outcome

Generative AI has become a genuine force multiplier for PM-Ts. It can parse telemetry logs, summarize large batches of user feedback, generate mock API payloads, or give you a first draft of a BRD. I use these tools regularly now. But they do not change the core expectation of ownership. An LLM can help you write faster. It cannot be accountable for whether a schema change breaks a downstream SLA. It cannot be the one who defends a strategic decision during a silent document review. It cannot sit across from a senior engineer and explain why the customer experience matters more than the elegant implementation. The PM-T still owns the architecture, the strategy, and the customer outcome. AI just makes the scaffolding faster to build.

What I Took Away

Being a PM-T at Amazon forced me to sharpen three things at once: technical intuition, written precision, and customer obsession. You cannot fake any of them. The data product I worked on taught me that scale does not just mean more records. It means more teams, more assumptions, more edge cases, and more opportunities to make an irreversible decision that looks harmless until it isn't. The writing culture is what stays with me. Every proposal, every trade-off, every risk has to be argued on the page. If you cannot explain it clearly, you do not understand it well enough. That discipline applies whether you are at Amazon or building a startup in your garage. The job is not easy, but it is clarifying. You learn to move fast on reversible decisions, slow down on irreversible ones, and let the clarity of your written thinking carry the argument when your voice cannot.