How I approach PRDs as an engineer

Most product requirement documents are written by someone who will not build the thing, for someone who will not decide what it is. I write mine from the other side of the table: at MapMyIndia I author the PRD and then I am one of the people who implements it. That changes what goes in the document, and what stays out.

Start with the problem, and write it down before the screens

Every PRD I write opens with a problem statement, not a feature. The Mappls Shop Admin work is the clearest example: the problem was a fully manual billing process, and the document said so in one sentence before it said anything about an admin panel. A feature list without that sentence is a wish list; with it, every later argument about scope has something to argue against.

User stories are how you find the states you forgot

I write user stories not because a template asks for them but because they force the states out. In fleet software, the interesting question is never the happy path, where a vehicle is moving. It is what the product does when a vehicle is stopped, idle, delayed or offline, and who needs to know which. On the telematics platforms those five states became the vocabulary for the whole product: the map, the alerts, the compliance views. The stories surfaced them; the screens came after.

Acceptance criteria are a contract with your future self

When the person writing the criteria will also be the person tested against them, the criteria get honest fast. Vague criteria do not survive contact with a Tuesday afternoon build. I write them as things a tester could check without asking me: what appears, what does not, within how long, and what happens on the failure path.

Edge cases are where the engineering knowledge earns its place

This is the part an engineer can do that a pure spec-writer often cannot: knowing which edge cases are real. The kind of thing I mean: a route playback with a gap in the GPS data; an alarm that can fire twice; a dashboard that is fine at a hundred vehicles and unusable at ten thousand. Writing these into the PRD up front is cheaper than discovering them in a demo.

What stays out

Implementation. The PRD says what the system must insist on and what it must never do; it does not say which library. That boundary is harder to hold when you are also the implementer, and holding it is most of the discipline. The document is for the people who have to agree on the problem (the operations team, the client, the other engineers), and the moment it starts describing the code, they stop reading.

Then ship, then look

The loop I work in is problem → understand → strategy → UX → build → ship → learn → next problem. The PRD is the artefact of the first three steps. Its real test is the last one: after shipping, does the document still describe what the product does? When it does not, the gap is the next PRD.