Product Manager, Agentic Partner Membership Experiences, on the Amex Digital Labs team. Three one-hour rounds with the hiring manager, all promising. None of the three topics were shared in advance. By the third interview, I was able to correctly guess the topic. Between rounds two and three I built an interactive prototype walking through what an Amex MCP server for Resy could look like, end to end. The hiring manager reviewed it before our last conversation and used it as a scoping artifact during the interview. Then the role was paused.
Two structured prompts and one self-imposed one.
"Uber. No constraints. Pick anything you'd work on, and justify your decisions at every step."
I started by defining what Uber actually is, where the money flows (riders, drivers, sellers, partnerships), and which marketplace metrics matter. Then I argued for autonomous vehicle delivery for riders as the highest-upside bet, with a defensible advantage (only Uber's scale supports it), an EV-friendly cost structure, and less first-and-last-mile friction than food. Moved on to the next round.
"Walk through the Resy customer journey from discovery to booking to post-booking. Map the API endpoints at each step."
I broke it into five stages: discovery (article and content APIs), search (restaurants and timeslot APIs), frictionless mobile login (phone code, token, profile), booking (hold reservation, payment flow, confirmation), and post-booking (changes and cancellation). We then talked about LLMs, agents, context windows, and how those constraints shape what you can build. My self-assessment after: "went okay."
The round-two conversation pointed at an obvious next question: if Amex wanted to make Resy the first agent-ready surface, what would the MCP server look like, what guardrails would it need, and how would the trust model work? Nobody asked me to answer that. I built a prototype that did, then sent it to the hiring manager.
No formal prompt. The hiring manager had read the prototype before the call and used it as a scoping artifact during the interview. We spent the hour working through the MCP Server Design tab as a live scoping exercise on tool definitions, eval frameworks, observability, and minimum scope. Originally scheduled for April 3, rescheduled to April 6.
I tend to do my best work when I can sit with an idea for a bit and come back with something more formed. Round two ended with us pulling on threads we didn't have time to finish. Building a prototype was the most direct way to push those threads forward. It also let me show, not tell, that I have hands-on MCP experience.
The prototype lives at middleton.io/prototypes/amex/. The first two tabs are the round-one and round-two conversations, redrawn so the hiring manager could review them at his own pace. The next four tabs are where I went past what we'd already discussed.
Agents shouldn't make reservations directly. They place a temporary hold, the cardholder confirms. This solves the trust problem without killing the experience. It's what lets you move from informational to assistive without needing to solve the fully-agentic trust model first. That single pattern was the centerpiece of round three.
One artifact: a live, interactive prototype on middleton.io. Embedded below for a quick look. Open in a new tab to actually click through it.
The substance of every round was strong. Round three opened with the hiring manager already having reviewed the prototype, and we spent the hour on architecture, evals, observability, user stories, and minimum scope. Working-meeting energy.
The structure of the process was strange in ways I want to name plainly.
The recruiter never shared what the upcoming round would cover. I prepped each time without knowing whether I was walking into a behavioral, a product sense, an architecture conversation, or a technical screen. By round three I guessed correctly that we'd dig into MCP architecture, but I shouldn't have had to guess. This is why I built a prototype we could walk through, so that I'd have a way to visually express my thoughts. Hiding the topic in advance only makes sense if you're testing how candidates handle ambiguity, and even then it costs more than it produces.
This thread ran across all three rounds. I addressed it head-on in round three. I've been a platform PM across multiple companies. My job is to define the what, not the how. I partner closely with engineering, and I was an engineer earlier in my career, so I can translate complex technical concepts for both technical and non-technical audiences. The hiring manager acknowledged it and pointed back to the prototype itself as the answer to that question. So why was it still being asked? Either the doubt was about something else and "technical" was the language for it, or the doubt was real and the prototype, the LinkedIn series on building with AI, and the hands-on MCP work hadn't moved the needle. Both readings are useful information.
I sent the prototype over after our round-two conversation:
The reply two days later:
Round three was on April 6. He had reviewed the prototype. We worked through the MCP Server Design tab as a scoping exercise: tool naming, observability, eval frameworks, what to ship in the first sprint. The "technical enough" thread came up again, and I made the case I described above. He acknowledged it.
I'd been seeing hesitancy in the process. The delays: three rescheduled rounds, all an hour with the same person, with another two cross-functional rounds queued behind them. Either the hiring manager was under extreme stress to "get it right," or the team didn't yet know what they were looking for. I scheduled a call with the recruiter on April 23 to share that read.
She didn't push back. She said the structure was highly unusual, validated my read, and confirmed in the same conversation that the role was being paused to further define it. She also offered to connect me with other opportunities on the team and elsewhere at Amex. Four days later I closed the loop with the hiring manager directly.
Role pauses happen all the time. My one specific concern going in was working inside any group with "Labs" in the name, especially in an emerging product area where both the goalposts and the technology shift every quarter. I'd happily talk to this team again.
Push the recruiter to share round topics in advance. "Hi, what should I expect to focus on in the next conversation?" is a fair question. If the answer is "we don't share that," the candidate at least knows what they're walking into. I should have asked it once, gotten a no, and adjusted my prep accordingly. Walking into three rounds blind cost more than it should have.
Address the "technical enough" doubt earlier and end it. I waited until round three to make the platform-PM-was-an-engineer case in full. By then the question was a pattern. If a doubt comes up in round one, I'd address it once, in writing, and follow with a concrete artifact. Don't let an open question travel three rounds.
Build the prototype sooner. The prototype could have started after round one, not after round two. By the time round three landed I had three days of polish and the hiring manager had two days to read it. With another week, the Vision tab gets sharper, the eval framework gets a worked example, and the prototype carries even more weight.
The artifact is the live prototype, not a file. Click through it.