Writing PRDs

"In this day and age, if you're not prototyping and building to see what you want to build, I think you're doing it wrong. I call it the prompt sets of the new PRDs. I really insist on folks saying if you're building new projects, new features of course come with prototypes and prompt sets."

"Whenever we're devising a new product or feature, we're going to start by writing a press release describing the feature and describing it in a way that speaks to the customer and to some degree the external press and world where the idea is, in my description of this, it better jump off the page of something like, wow, as a customer I will really need this."

"What I work first is to say, okay, for your product development process, let's start by using this method as the method to decide what am I going to go build? And oh, by the way, to use it as a method to sort between a lot of different choices of what you might build."

"I had used ChatGPT and a prompt to come up with a very serviceable PRD spec for this very technical product... I eventually ran into the monetization and access wall that is the GPT Store right now. And so... I thought, this is easy. We're just going to stand up a standalone app."

"In a Claude Code world, where you're not coding a lot, you end up spending a lot of time essentially typing PRDs... you could spend a little bit of time being like... I'm going to write a prompt that can take my rambling thoughts and then turn that into a PRD."

"In the second month, we're going to build out a PRD for engineers to start working on. In the third month, they're going to start working, and they're going to ship this."

"Unless there's something that's very sophisticated that we're working on, we tend to keep them pretty light. I like to just have the minimal amount of context possible, that just ensures everyone's on the same page and that the key outcomes for whatever feature that we're working on, are going to be present when we get there."

"This is the purest sense of what a product requirements document should be, is this eval judge that's telling you exactly what it should be, and it's automatic and running constantly."

"You're never going to know what the failure modes are going to be upfront... PRDs are a great abstraction for thinking about this. It's not the end all, be all. It's going to change."

"The product management team is fascinating, because now they're actually building the product. So last night I saw how we've specced out in v0, think of it as like a live PRD, we've specced out how the new functionality for deploying a v0 to Vercel is going to work. The amount of detail that was contained in that v0, I mean, we're all just saying, 'Well, just ship it. There's nothing else to discuss.' It was animated, it was interactive."

"The most important section in my opinion in the document is the first part, which is like what is the background and context? What is the problem, why does it matter and why does it matter now?"

"Can Claude be a partner in figuring out what to build? What the market size is if you want to approach it that way? What the user needs are if you look at a different way? ... Models can do that today."

"Is your PRD quality good enough? Are you writing that the draft notes that go and circulate to the care teams, to the marketing teams and so on? ... You must have that impact to impact through the artifacts that you work on."

"Can you show me your last PRD? Can you show me the last product note that you sent? Can you show me the product strategy doc that you have or collaborated on? Can you show me the brief that you sent to the design team on the problems and the ranking of those problems? Usually, you'll find something or the other missing."