The shift changes at five in the morning at the dhaba on Asad Avenue, the one tucked behind the CNG stand in Mohammadpur. I cook the night, eleven to five, rickshaw drivers off duty and the occasional Pathao rider waiting on a fare. The morning cook arrives in a clean apron, hair still wet from the tap. I have learnt over the past two years that the only thing a tired night cook owes the morning cook is a clean mise en place. Cutting board wiped, ladle on the hook, three steel bowls on the wood. That is the handover. The chits will follow.
A friend of mine PMs at a Banani startup that ships an agent built to catch fraud. He has taken to coming by at half past four for a cup of cha and complaining about the gap between the way he was trained to do product, in Lean Canvas and Aha! roadmap form, and the work he actually does now. He keeps trying to explain his stack to me, and I keep telling him it sounds like the bowls.
The first bowl, the one closest to the burner, is the prompt. Chopped onion, in our analogy, the thing you reach for every two minutes because it goes into almost everything, and its freshness is what decides whether the dish on the plate at 2am tastes like a dish or like a punishment. The PM at the Banani startup writes prompts the way a sous-chef chops onions, which is to say a lot, and badly at first, and then over months in a way that other people can taste but he can't explain.
What changed in the last two years is that the prompt, not the PRD and not the figma, became the artifact the PM actually ships. It's what the model receives and what the eng team versions in their repo, and it's the thing the customer's question collides with at three in the afternoon. PROMPT The PRD is still around, of course, the way the dhaba's menu is still pinned to the wall, but the menu doesn't get touched once the burner is lit. The prompt is what the lunch cook is actually holding in his hand.
The cook's version of this is the recipe card, which everybody at the dhaba writes in their own hand, none of them quite agree on, and the head cook quietly maintains a master copy of behind the chai tin. The PM's version is the prompt template in the agent's repo, with eighteen variants in version control, each one named after the customer call or the bug that birthed it. Karpathy keeps saying the prompt is software, and he's right in the boring way that the recipe card is software. It's a sequence of instructions that, given the same inputs, produces the same outputs, until somebody changes the gas pressure on the burner and nothing works the way it did yesterday.
The second bowl is the eval. Ginger paste, in this analogy, the thing you make once a week and nobody at the front of the dhaba thinks about, though it quietly decides whether your kitchen has standards or just opinions. Hamel Husain, who has been writing about eval design for the last two years on his blog, keeps making the same point in different forms. If your eval suite is a vibes check on a Tuesday afternoon, your model behaviour is a vibes check on a Tuesday afternoon too. The product ends up being whatever the eval happens to say it is, which in most kitchens is only as sturdy as whatever the team had the patience to write down that week.
The PM's job here is closer to a magazine editor's than to a quality engineer's. You are reading model outputs at speed, deciding which ones are "right" in a way that is largely taste, then writing your taste down as a scorecard somebody else can apply. The trick is that the scorecard has to be specific enough to grade with, and general enough to survive contact with the next ten customer cohorts. Most teams I've watched write the first version of an eval in a Friday afternoon and never touch it again, the way most cooks taste their ginger paste once on the day they grind it and never taste it again for a week.
The good eval suites I've seen at startups in the Gulshan and Banani belt all share roughly the same composition. There is a set of adversarial cases, prompts modelled on the customer from hell who broke the agent the week before. Alongside those sit the simple, dumb regressions, prompts that should always work and quietly stop working when somebody updates a dependency. And a sample of real production traffic gets folded in too, sanitised, so the eval isn't just measuring the team's imagination of what the customer is asking. The team that builds an eval like this stops shipping fewer features and starts shipping more, because the rollback decision becomes obvious instead of political.
The third bowl, the green chillies, is observability.
The thing that tells you what the burner actually did to the onion, instead of what the recipe said it should have done. For a PM working on AI products in 2026, this is a Langfuse dashboard or a Helicone trace or the bespoke logging table the platform team built in February because the off-the-shelf options were too expensive. The shape is the same in every case. Every model call leaves a trail that records the prompt, the response, the tokens spent, the tools the agent decided to call, and the time each step took to complete.
The PMs who can read these traces are the ones who can ship. The PMs who cannot are the ones whose roadmap slides have a sentence on slide eight that says "we are seeing some quality regressions" and no detail on slide nine. The trace turns "the model hallucinated a refund policy" into something more useful. On Tuesday at 14:47, the agent called the tool that looks up policy, got back a 503, retried twice, then synthesised a policy that does not exist in the knowledge base, and the customer accepted it. That second version is fixable in a sprint.
The thing the trace teaches you, which no PRD ever did, is that the model is doing roughly six things on every call and only one of them is the thing you wrote the prompt about. That work breaks down into parsing the schema, selecting a tool, interpreting whatever the tool returned, deciding whether to ask the user another question, and composing the eventual response. In some agent frameworks there's a quiet final check where the model decides whether it is done at all. Each step has its own failure mode, and the only document that captures all of them is the trace. The PRD captures intent, and the eval captures the standard the team agreed to hold the model to. Neither of them shows what the trace does, which is what actually happened on Tuesday afternoon, with the particular customer who walked in expecting a refund.
So that is the handover. The bowls are on the wood, the burner is lit, the ladle is on the hook. The morning cook will work the lunch rush in his own style, and that is his business, but the mise is the mise and he inherits it whether he likes the way I cut the onions or not.
Nothing I have described here kills the PRD. The roadmap survives, and so does the executive review on Thursday afternoon, and anyone who tells you those are dead is selling something. What has happened is smaller and more annoying than a death, which is that the daily work moved one cabinet over, to the prompt template the eng team versions, the eval scorecard the PM maintains, and the trace dashboard the engineer on call keeps open in a second tab. The PMs who can read all three are the ones whose models keep shipping. I can read two of them properly and I bluff the third, which I am telling you because every version of this essay I have read elsewhere is written by someone who claims to read all three fluently, and I do not entirely believe them.