The intro to PRD I wish I had when I started

Today we're going to learn how to clap. No, we're not. My name is Parker Rex. I build a lot of stuff with AI. Today we're talking about PRDS, product requirement documents, why you need to know about them, what they do, and how to get the most out of them for AI. PRD is a product requirement document, and why is it important? For a lot of reasons. I've got a new setup, and it's confusing. I'll just show you. I just got a new keyboard and I got a lot of stuff actually. Let's see. Got a new keyboard. That's what this thing is. The Advantage 360 Kinesis. And we got the little pad over there that we're going to try to scribble on. But I also set up them a lot of Lua. Why is a PRD important? It's because it sits at the center of three areas. sits at the center of design business development. So when you do product management, which is what the product manager does, PRDS, you're sitting between design, business, and development. So your role as a product manager, and most likely if you're watching this, you are figuring out that you need this magical document so that you can get more out of your tool. But I will pose in this video that you don't want to just get a prompt and give it to the LLM and just cross your fingers because I've tried that a lot of times. Trust me, I've wasted a lot of time, a lot of tokens and money doing this the wrong way. So, you need to get better at thinking through the product strategy. And I've done this for close to 10 years. That's crazy. But the product requirement documents at every company is different. and I'm gonna pose two different ones for you. So, we'll go through how Amazon thinks about product requirement documents just so you can get a kind of 101 on it. And then I want to go and pick one that will be much closer to what I think is the best, which is how DHH and Jason Freed do their product requirement documents. Now, some people might look at this and be like, "Oh, this is not a PRD." Cool. Don't watch the video. But I think this is a great way of doing it. At Amazon, they have what's called a six- pager, and it's a lot, but they literally invented the Kindle, the Amazon Prime, I don't know, a lot of stuff, right? They've invented a lot of stuff. And they use these six pages, which is written as pros. And you'll find that any sort of product requirement document, it figures out the what and the why, the purpose behind what you're building. It doesn't really pose or care all that much about how that's what the LLM's are pretty good at. Now, can they build Netflix? No. But they can build something that looks like it. They can fake that. You still need to be competent to take advantage of the capabilities of LLM. But in this case, they talk all about how you go in and you write a whole story about what this thing is that you're going to build. So, in the case of a Kindle, think about a Kindle. If you have a Kindle, how do you charge it? What's it made out of? What are these frequently asked questions that you, the customer, would have if you bought a Kindle or if you heard about a Kindle? Because Kindle wasn't a word that we all knew until it became this popular e-reader that was everywhere. So, you're answering all these questions and that's part of the six-pager. is figuring out what are the FAQs, what is the press release that would have been written if this were to go absolutely wild because that headline is the juiciest part. That's what you would explain to your friend when you're making a new feature or a new product. Inevitably, if you're going to be building something, you'll have a lot of different pitches and you're going to be pitching your engineers. If you're working with engineers, you're going to be pitching yourself when you run into problems with it. So getting that down to X product solves Y pain for Z audience something along those lines. That's what the headline would be and that's what they cover in a six- pager. You can go and read this article by Sigop Pearan but it covers a whole lot of stuff. All the printouts are handed to you at the end of the meeting. So, you've written this six- page pros that lines up everything about this product, what it's going to do, why it needs to exist, how it's helpful for customers, and you can't hide in pros. So, you're probably already so bored. But this is how it works where you have the introduction. So, this needs to precisely set up the material that we're going to cover. covers the general direction of where the document's going. The goals, so what are the goals, the metrics for success, so we can use them as a lens to see through the remaining of the document, tenants, state of the business, lessons learned, strategic priorities. So this is like a really extreme one right now. I think if you want to get good at product, it's worth this as an exercise, but a little bit overkill. I know when I was a product manager full-time that I hated writing these, but I wanted to bring it up. So, if you're still here, then let's get into something a little bit more interesting. So, this is where I would go is before you actually give a PRD or a plan or whatever it is that magical prompt that you want, which I can give you plenty of them. Before that, you got to think through the why. And I keep saying this, but it's really it's so true. It's like why are you doing this? What's so good about this thing that you are posing that you should be doing it to begin with? So it should start with a problem. It really should. So that would be the problem, right? It would be the raw idea, a use case or something we've seen that motivates us to work on it. And so in my case, I'll give you a real example. So in my case, my problem with something that I'm personally building was I don't live in San Francisco. I live in South Florida. It's a tech desert. I want to be around people that care about this stuff as much as me. So that would be where I start. And there's a lot of different solutions for that. Okay, go to a meetup. You don't have to build anything. Go find better friends in South Florida that are into tech. Okay, I tried that. Try to build a community online. Okay, I did that. didn't build anything. Now I run into the next problem which is the technology stack or the technology platform that I'm using is really limiting and because we're all technologists we want better technology that we can use to collaborate and share ideas. So then the solution to that might be oh go build something. So it starts with that problem and I always find that it's best if you personally are solving your own problem. Now, that's going to be totally different for you if you work at a company and you don't have the luxury of working on your problems, your own problems, which is most people. You need to talk to the people that have that problem. And that's the feedback loop that you always hear. So, I think there's a lot The biggest problem that I saw with most builders and something that I've run into a bunch over my career is you assume a problem and you find the problem after you've come up with the solution because there's some flashy technology or you want to use something or you had this idea in the shower and you're like, "Wow, this is going to be great." You're a solution in search of a problem. You don't want that. You really want to validate that this is a very painful problem. And it's so important that if there's one thing in this list that matters, it's like validating that. And you can do that by talking to people. You can do that if you're super introverted. You can go and search around Reddit and find threads where people are blowing up about something. And that's a good sign. Then you have what's called the appetite. So the appetite is the bet size. So how long are you going to spend on this? Now, I wanted to make this video because I personally got a little loosey goosey on this because I had a side project that had turned into a real project because there was a lot of interest from not just the people in my community but others where I was like, "Ooh, I don't need this appetite thing. I've done product forever." No, stupid. Because I didn't time limit it. I didn't set a budget on it. I allowed the scope to explode and not even in terms of like feature set, right? But scope can mean that you wanted to rebuild it in this new language because it sounded cool, right? And these are beginner mistakes, but they're mistakes that you fall back into when you have all this technology that's coming out. So, you'd come up with that problem. You would constrain it with the appetite, which is the bet size you're going to be making. Because whenever you build something, you don't truly know if it's going to work out. You can get validation. A lot of people I see as well, and I've fallen into the same trap both on the intent of a customer or the intent of an investor, which can be sometimes worse, is they'll give you a verbal where you have this problem, you say, "Hey, if I go build this, would this be cool?" And that's a horrible way to validate it because that's not the truth. You've already set them up in a direction where it's an assumptive question. You've guided them to say yes and they're your friend. They're someone that knows you. That's not the raw truth. If you want people to give you real feedback, it's look up the mom test. It's a really good one for customer feedback. But you can't guide them into the answer that you want because you're just creating false validation which in the end is going to hurt you because then when you go and spend the time on this and you get in front of a customer, you don't know if it's actually going to work or not. So that's why I like to build stuff for myself because faster feedback loop. Is it good enough? Is it not? And then you can build stuff really quick. I've built a lot of projects. If you check out my GitHub, I have projects that I've spent a weekend on. I have projects that I've spent a couple hours on. I've had projects that I've spent a couple weeks on and I try not to get them past two weeks until like I've gotten it in front of someone besides me. So that's the second one. The solution is when you actually are going through what would this look like? So in the case of we'll use my community, right? It's easy one. So in my case, you'd probably have some posts and then you'd probably have the notion of members and you I would just be thinking of what are the primitives here, the actual data. So it's like we have members, we have posts, we have comments, people are sharing prompts, they're sharing workflows. So we could just say that those are bucketed into resources. But at this point, I'm just ideulating on what are the building blocks of this thing. And then I can go draw something that's a lot better than that. But you get the idea. You're making assumptions. You're just sketching things out. And then you go into what the rabbit holes are. So these are things that you totally want to avoid. And then you go into the no- go, which is we're just not going to even touch that. So rabbit holes are the known areas that could explode the project and could put the appetite at risk. And then the no- goes is if this is going towards mobile, bye-bye, we're not doing it. So, I highly recommend reading that. It's really helpful. And then how would you take this and put it into practice, right? So, you'll end up with this kind of outline where you have the problem, the appetite, the solution, the rabbit holes, and the no-go. And this is what I just like to call the pre-work. So, before all this AI stuff, I'll just give you how it used to work on Teams. So, I would go and I'd write a pitch and that pitch would then go and I'd have it refined with the customer. So, customer feedback plus pitch. So, at that point, I hopefully before this step already have a real reason why we're doing it. Otherwise, I'm doing a bad job. I'm just building stuff just to build stuff, which a product or a service is only successful if it solves a problem. Otherwise, no one's going to spend money on it. the hobby. So hopefully I've already gone into the pitch and I know, okay, this is worthwhile. I have a bunch of examples. I have evidence why I should do this. And then I go and I meet with the customer and I don't pitch this. I come with that and I ask questions and I'm asking them, "How do you do this now? What would it look like if it was better? How could we delete this step from the process? Can you walk me through all those steps?" It's all these questions that are hopefully outlining some sort of like workflow of how they do it now. And then your job is to find the bottleneck. Not to take what they're saying as gospel because that's the job of someone who's good at product is to actually translate this like all the jibber jabber. Like if you go into a meeting, they're going to say let's call it like I don't know maybe a hundred things. It's called they say a hundred different things. And your job then is to be like, "Okay, here's the couple of things that actually matter." Like, "That's the sauce. Let's get that." Now, those things will probably be problems. And so, hopefully this pitch that you did write, you walk out of there and you're like, "Man, I nailed that." But most of the time, you won't. So, then you come back and you're like, "Okay, cool. I now have done, let's bucket all this as like the pre-work." At that point, then you can start figuring out. So, this will be in another video. I'll leave a prompt that you can take with you. Now, it won't work perfect for you, but this one's pretty good. I recommend using 03. If you have cursor, I recommend using augment if you have augment. I don't recommend using a cloud model without augment, but that's what I would do. And that would then enter into your planning. So this guy, I think it's yeah, velocity coding. So this guy has a pretty good prompt and it just basically takes your PRD, puts it into a format for planning that has context of your codebase. So this is the job now guys. The job is getting better at product, figuring out how to then turn that into like actual action items for your coding agents. And let's see if I can't find my ghosty. Where is it? There we go. So, let's see if I have one in here because I've been doing a lot of stuff manually. I'm trying to get better and I realize I don't get better if I just lean on an AI. But let's see if we don't have a plan in here. Slashcomands feature. This one's okay. Yeah. So, let's take this one for example. So, this would be the output of that prompt that I just showed you. So, in this case, my problem was we have a text editor for making posts. So, it's a rich text editor component basically. And so I'll show you that real quick and I'll show you the problem that I have with it. So this would be for a feature. So if I do command L and then I go to actually is it open? Yeah, maybe. Can I log in? Oh, I got to get a code. One moment. I don't have Oh, my phone's recording. I don't feel like checking my email. Basically, I want to have better writing experiences. Now, there's a reason I didn't do this is because I it wasn't enough of a problem to stop pushing this out into the world, but I know it will be soon if we want to have better writing experiences, or I believe so. So, the idea was I don't like to write posts in text editors that suck and I don't have the ability to format things the proper way. I don't have the ability to do block quotations, code blocks. It's particularly important for when you're sharing a lot of code snippets. So, because that's a core tenant to the product that I'm building, sharability is huge, right? So, this one makes sense to me, but again, I haven't built it because I don't think it's too important. There's bigger fish to fry. But I started there and I was able to basically put that plan together and say, "This is the experience." a little bit of linear, a little bit of notion, a little bit of tip tap editor, which is the thing that powers those. And it broke it out and it gave me a nice phased way of doing it where you have the task breakdown, you have the different ways to trigger those commands and it's all in here. It's got some technical architecture as well. Oh, for slash commands, this is how you'd think that it would work. A command registry and they're broken into these phases, right? So what you get is basically this document that sits in a directory for plans. So in my case, I switch these things a lot, which is partially why I haven't made a video in a while because it's like I don't want to share stuff that changes every single day, but I still will. But you have AI docs and then plan and then to-do and done. And so in the to-do, I have a bunch of these ones where it's, oh, here's the enhanced news feed, and they have different phases in them. And these are all driven through either augment with its context engine. That's honestly their sauce. Full disclosure, they sponsor the channel. So if I were to like look at a different one, I don't know, remove hardcoded tier settings. trying to find one that I didn't clean up yet. But it's again, it starts with me putting in like basics. So like this would be, okay, cool. Let's come in here and let's actually write out what is the problem, right? And then I'd say, okay, users don't have the ability to update their settings. Which settings actually matter? Maybe you're making an assumption. Maybe people don't want that many settings when you get started. Who knows? But that's how I would do it. and it's worked really well for a long time this whole planning thing. I hope you found it helpful and if you did, make sure you like the video, make sure you subscribe to the channel, and drop a comment below of the kind of video that you want to see in the next one. See you.