Facts, Hypotheses, and the Art of Writing PRDs

During my time at Ather Energy as a Product Manager, I found myself in a unique position—mentoring new Product Managers while also managing them. At Ather Energy, senior PMs took on the responsibility of grooming new team members, going beyond mentorship into a more managerial role. It wasn’t typical to have IC (Individual Contributor) PM roles; the path for a new PM was through direct guidance from experienced team members.

Sometime back, I found these new PMs were finding it difficult to write effective PRDs. Here’s how I approached mentoring them, and in the process, gained more clarity myself—something I now use as a mantra for every new and upcoming Product Manager I work with. 🙂

Like many, I stumbled into product management by accident. I was working on Data Science & Machine Learning for an Analytics Consulting firm when I got the opportunity to build my first SaaS product, and before I knew it, I was hooked on to the world of building Products & Experiences. But maybe that is a story for a different time. When I started, PM wasn’t such a mainstream career choice as it is today. I didn’t have an MBA or formal business training; instead, I relied on first principles thinking to solve problems. While it may be a common phrase, it genuinely reflected my approach more because at that time I didn’t know much apart from it. I wasn’t against frameworks—they’re valuable and I picked up some over the years—but I keep going back to my roots in keeping things simple and logical.

At Ather Energy, one of my responsibilities was to review/edit PRDs (Product Requirement Documents) from the new PMs I managed. These were bright, talented people, but as they were just starting out, their PRDs often needed a lot of editing. I found myself leaving comments on nearly every line. I realized that if my feedback wasn’t cohesive — clear, consistent, and structured around key themes — it wouldn’t help them grow effectively. It wasn’t enough to just make edits; I needed to give them a guiding principle.

After a lot of thought, I landed on a simple framework for writing PRDs —

Every sentence should either be a Fact or a Hypothesis and absolutely avoid making Statements at all costs.

Statements are risky—they can easily mislead and stick in the minds of readers without evidence to back them up. For example, saying “Users absolutely hate the current feature” without any data or context can create a false narrative that influences decisions negatively. It’s our job as PMs to ensure that engineering & design effort isn’t wasted—that what we ask for is based on real customer pain points or a valid, testable hypothesis.

Facts should be backed by evidence, and hypotheses should come from a well-considered thought process, ideally grounded in some qualitative insights like customer interviews, competitor analysis, or broader industry trends. The key is transparency: if it’s a hypothesis, make it clear and explain your reasoning.

Interestingly, a couple of months later, I found my guiding principles validated when I listened to Aravind Srinivas, CEO of Perplexity, on a podcast with Lex Fridman. He emphasized the importance of distinguishing between facts and opinions —

“Every sentence you write in a paper, should be backed by a Citation.”

…much like the approach I used with my team, showing how this mindset is crucial even in advanced AI research. He talked about similar ideas from his PhD days—how critical it is to distinguish between what you know and what you’re testing. It was reassuring to see a principle I’d developed out of necessity, is validated by someone leading a multi-billion dollar cutting-edge AI company.