AA123 - Product Requirements Document in Agile Development

Why does Agile need PRDs? Why use PRDs in Agile development? When you go through your two day CSM or like if you work on development teams, you may have never even been exposed to a PRD in your whole career. And then you'll, you'll roll into one of these shops that say, Oh, well now we need you to do a PRD. Now luckily. I had been exposed to PRDs way early in my career when I was a team member, but the product requirement documents that I was exposed to early in my career were very exhaustive, top to bottom business UML diagrams. I mean, thick books of requirements. And, we just don't do that, in agile software development. So if you're, if you're in the world of agile software development and you hear about PRDs or you got a job as a product manager and you're being asked to do a PRD and you've never, done one before. Or maybe you don't want to do one and you're kind of resisting your organization. this is what we're going to cover in this podcast. What are they? Should you do them? How do other companies do them? What are they for? And how, you know, potentially how to do them by sharing the templates and things like that. To PRD or not to PRD? That is the question. Maybe we could just start talking about what PRD stands for as an acronym. And so a lot of the Agilists of today may not have heard the term PRD. And if you haven't, it stands for product requirements document. There are other types of documents that kind of allied, or I guess they fall out of there. Technical requirements document or, functional requirements document. Those aren't part of this podcast necessarily because they're fairly well, I think, covered elsewhere, but they're also obsolete or obsolete. Yeah. Yeah. As I said, they're no longer relevant, for, for our needs today, or have been replaced by other things, other tools. Let's dive into this. We've searched all of the internet and we've chosen a few good examples of PRDs to show. So we're going to show the, the outlines of PRDs from a couple different places. The first one to highlight is Amazon's six pager. If you're, if you're listening on audio, I'm going to denote each section of the Amazon, six pager. And, if you're watching, I'll put the bulleted list next to me on the screen as we walk through rather than trying to, Jockey back and forth. Oh, yeah. Yeah. Yeah, it'll make you dizzy. The amazon six pager Which basically is a prd like whether you want to call it that or not I don't know if people are gonna like throw a fit whether i'm calling the amazon six pager prd, but we outline their process, their process being picking a single threaded leader in the organization who just does that one initiative, that one business initiative, and carries it out into the market and oversees it. That basically is a product manager anyway. Yeah. And their outline, is as follows. Number one is the, the list of purpose of the document, right? They'll, they'll outline The reason for the solution, they'll outline, it's like an executive summary session. Right? The, the, the reason for the solution, the reason for the meeting, because they, they present the six pager at a meeting where everyone reads it together. Executive summary. Very important. Right. Right. Even not in what we're talking about, executive summaries are still important. You gotta know your audience when you're writing. They'll, they'll go into a narrative where they'll describe the, the background. The demographics or user segmentation. I'll say user segmentation, right? That they're, that they're servicing here. The business environment. This is a bit of marketing that I go to when I, when I say like product in the last episode, we talked about product marketing and product management. A couple of episodes ago, when we did the Brian Chesky video breakdown, we talked about product marketing being a function of product management. Rather than being separate. This narrative section tells, tells me, tells me the business owner that you wanted or whatever the, you know, whoever runs the business, it tells me that you understand the market. That's a little bit of that in the narrative. So you're telling a little story here that, that's your opportunity is to tell a little story and inform the audience about the business. Hopefully with numbers and, you know, real, yeah. It should be, yeah, it should, it should be with numbers. And then, we're going to talk about the problem. Like, this is where we get into, very basic product management. What is the problem that you're trying to solve? What is the problem? outline the problem, you know, in detail. Show that you understand it. Give me some stats. Give me some actual, research that you've done on the problem. And then, now that you understand the problem, and you've given me some business context about the business around the problem, now, let's dig into some solutions. Here's some solutions we could try, outline different ways that we could solve the problem. And then at the end, you give me your recommendation here. Here are the ways that we could solve the problem, but here's a way that I think we should solve the problem. Since I am the single threaded business leader here, basically, here's my plan. And then, when you have that plan of action, there's some appendices at the end of the document that you should have a plan of action. You should have any, any references that you go to. You should call out here. They ask that you shop the document around. I mean, you don't have to, but you probably should shop the document around to the other department heads or other people, other stakeholders that need to be in the meeting and, figure out what they need, figure out what questions they're going to ask, roll it into the frequently asked questions at the end of the document. That's good to have. References, frequently asked questions, stuff like that. Basically it's a big document of why we're doing this. Why we're doing it, and kind of what we plan to do generally speaking. Right, it's also, for whom, like who is our target audience? How big is the market we're trying to tackle here? Again, to your point earlier, numbers, right? So how big is the market? that can be, you could use appropriate numbers there. It could be dollars, it could be, you know, number of users or whatever it might be. Yeah. The nice thing about this document for me is like clarity and alignment, like anybody in the organization, if they're not clear about what your teams do or what your, you know, what, what your product is as a product manager, they can come along and say, let me see your six page, like they can pull your card, let me see your six pager. And read and understand what your line of business is, what your products are, what business are you in? What segment of that business? Maybe if you segmented the market and then what problems you solving, they can get all of that from reading this document. And they don't need to interface with you, bother you, you know what I mean? Any of that kind of stuff. Theoretically, right? Theoretically, right? That, that's pretty cool. Well, yeah, I think someone who doesn't understand what you're doing, they should theoretically understand all of that. And guess what? They've only spent six pages, like whatever it takes to read six pages. Not, not a whole lot of time, basically, right? Um, so that's great. I like the, the, the point that is made here. The narrative should be from the perspective of the end user, it says here, as opposed to, you know, from an engineering standpoint or, or just even pure finances. You have some in there. You need, you need that. So you need to understand is it worth going after the market or not. But that's about it. That's where this, this tower of cards starts to break down. Like as we start digging into like, yeah, I should be able to read your six pages and completely understand your segment. Whoa, whoa, whoa, hold on. You should have some idea. Yeah, right, right. But you may not be able to understand everything. Yeah, no. Six pages. Yeah. Like the, the issue here is like after these six, well, maybe we should go to different examples before we start digging into it. Like, let, let's jump to a different example. Yeah, let's do that. Let's do that. Let's jump to a different example. So, AHA has a section on PRDs on their website and, for people listening, what I'm showing is aha on their website. their breakdown PRD is an overview that basically the basics of what you're building. And, the objective, which draws back to the strategy, some context, which is the personas that we were talking about, the business cases, use cases, a little bit about the market that you're operating in. some assumptions, things that you might look to validate later, the scope, which I don't know about as a bullet point item on here, cause the Amazon one didn't necessarily had scope. It like the Amazon one didn't necessarily have. Scope it probably had scope in terms of like these are things we're going to do These are things we're not going to do I don't know. Like it wasn't called out so clearly. So I'm not, sometimes people don't call out what they're not going to do by implication is this is all we said we'd do. That's what we're doing. Yeah. Sometimes people say this is what we're doing and anything outside of this document is not in scope. I can see that. And then down here they have requirements, details of what should be built, such as user stories or wireframes. I can see some high level mockups that, that, that makes sense. Performance metrics for success. And then open questions. I said, Q and a was part of the other document too. So some sections overlap with this one. There's some new ones. Yeah, there's some new ones. There's some ones I don't like in this one quite to be honest. And, like while we're pontificating, let's, Ooh, I guess. We do that sometimes. Pontificating. Another site that I think is actually lends itself to what we're talking about is a product school, product school. com. I'm going to take you to product school. It's as long as I don't hit detention. I'm good. PRD, So, in their version of PRD, they have the same overview, you know, that, that Amazon had. Success metrics, that's common to every single one. Product marketing messaging, that, that's been pretty common as well. Like, what market does it, you know, lend itself to, and what's the, what's the message we want to project into this market. It has personas, just like everything else. It has a timeline slash release planning, which, again, that was the one I was, I was kind of shaky on that one. I was like, Hmm, this is kind of you. Hey, this is useless. So that does not sit well with me. Well, we'll get into it. We'll get into it. I understand that this, the product school here says user scenarios, but. But what they're, I think what they're trying to say is what, what, what, what experiments or goals are we shooting for in here? But also that then they go off and they say user stories, features, requirements. So then maybe I don't know if I was trying to paint them in a good light and then they went and broke the law or whatever. And then some designs. Early sketches, wireframes, that kind of stuff, a Q and a section, just like the six pager trying to answer common questions. So, so it makes me think that they've kind of shopped this around before. Basically everybody had the same basic shell a few people had some extra stuff that I don't really think is super necessary like you don't need timelines when you're launching a business strategy What I do have to say most of the ones I've seen have had a Change history in there. Yeah. Versioned change history, right? I'm okay with that. I mean, you can do that in wikis and stuff like that. Let you roll back. Yeah. A lot of times they come built in. But, like the, the, the, the first thing to point out, we started touching on this, like all these, all these documents are trying to do is they're trying to promote clarity and alignment throughout the business. It basically clarity and alignment in the form of, you don't really need to talk to anyone. To understand what this sec, this segment of the business. What their purpose is right? So I'm a new CFO I come on and I want to check every line item on my budget and make sure everyone's Punching out widgets, and I'm getting paid appropriately. I don't understand what this Brian& Om's development team is doing over here I need to read their six pager and understand what they're doing. Okay, now I understand what they're involved in. And why they're doing what they're doing. Yeah, yeah, yeah. So from that perspective, this document's great. My immediate pushback to this one is, do you need to know what all the teams that you don't understand are involved in? I mean, a lot of times people have FOMO, that's why they need to know, right? I need to know because I'm a CFO. Ideally, ideally, somebody new coming in and looking at stuff that's in, you know, in history or in flight, let's say, that's one thing. But ideally, you should be attending the readouts of these things, right? Ideally. So then you know. And then you have the opportunity to voice. Your opinions, concerns, whatever, right, at that point. So you have the right audience in place. What will be promoted as a pro for maintaining a PRD would be that there is documentation. There is a paper trail for what you're doing. There is something written down, there's an archive of what you're doing over time. Whereas like Agilis often get accused of not writing any documentation and having no to being anti documentation. Which like, for the purpose of not, like that could be a whole different podcast by itself. But for the purpose of this, something is required to engage in a new business activity. You know, something. Yeah, and this is something that, you know, if um, if people are keeping the document going. Through its life cycle. It's great because you not now know the way the pivots were Hopefully it also contains the reasons why. So you're doing that. I think people need to stop thinking about the documentation aspect merely as just CYA. It's, that's not, they're missing the point, if that's the case, right? It's to have a record within the company of what was being done, for what purpose, to what end, right? And then how it evolved as well. where we're going now is, you know, well, well, there's got to be some documentation of what we were working on over time and when and stuff like that. I have a a Miro template I created myself for walking, business. And other product managers through the thought process of creating new, new products and new features of new products to try to, to try to answer the common questions, stuff like that. Basically that reverse engineering this whole document. And I created this, I don't know how I'm going to, I don't know how I'm going to get this out on the audio version. Like YouTube. I think you're going to have to narrate the points. Yeah, but what I can do is if you're listening in audio, I'll add the link to the image I'm about to show on the screen so you can click it and see it as you're listening to the podcast, because one of the big reasons I wanted to have this podcast is I'm not sold that you need to create PRDs in agile. Product development. I'm not sold. I can see pros and cons and I'm kind of, I'm kind of 50 50 I'm kind of on the fence. Like if, if, if my company were to come to me and say, oh no Brian We decided we're gonna do PRDs for everything now. Every program, project, product, whatever, all the P words Are gonna have PRDs now. I think I'd be on the fence about whether I should Fight it or whether I should just do it and get over it. You know what I mean? Cause I see pros and cons here. The immediate con here is like. Why am I going through all this time and effort to write a document that lives out there when this stuff that I'm outlining like here's a problem we're trying to solve and here's a possible solutions that we can do like I can get into solving the very first solution and the very first thing that we do to solve the business problem that we're trying to solve here is Wildly successfully solve the problem. Or completely the opposite. We get in and the customer's like, Actually, this is not the problem I need solved. Or, or actually I'm not, I don't want to buy the solution. I went with a different vendor or whatever. Like now what I went through all, like I got my tech lead involved. I got my team involved. Maybe I got more than one team involved. I got all the people from the executive team or leadership I got all of them involved, wasted all their time. And now the customer is like, nah, actually. Nah. Thanks, but no thanks. So I think there's degrees, right? So, I mean, initially, for a draft review, you wouldn't need to spend hours and hours on it. It is not the final polished thing. But I'm also not suggesting you spend hours thereafter, even, to polish the thing ad infinitum. Just enough, right? Just enough is what we need. So six pages, okay, you're gonna spend as much time as it takes to create six pages. They don't even have to be full six pages, they can be bullet lists. Yeah. They can even create a Miro board like you've done, right? And just talk through that. It's sticky, it's dragging them here and there and having people have a discussion around it, which is where the value is. Well, that's, that's what I'm worried about, about a document like this. It's not the summary six pager that kicked off our product. It's referred to back as like, hey, I'm not going to go look at the backlog. I'm going to go look at your living document, and I expect that every time you update a feature, every time you put out a story, every time you finish a development task, it goes and gets added, the date that you finish, like that. I'm looking at , a genuinely helpful practice like this and thinking like how will companies take this and make it the worst version of what this is supposed to be? It's supposed to be a high level get funding kick off the initiative Declare the person that's gonna be leading it and go and now it's tracked via all of our other methods But this original document that kicked it off is still there. It's still kind of being adjusted as we learn things in the market, it's being tacked onto. The keeping it up to date and like having to put all your stories in Jira or Azure DevOps or whatever, and then also having to update this and then giving progress updates like that, that, that's where I see PRDs going. That's the evolution that I see from this, and it's super scary to me. That is, that's just the extreme extremes, right? Yeah. So, I, you know, when I say there's this degrees, what I mean is keeping this updated would be in simple business language, right? And no more than a paragraph or two for these pivots that you have. We're not saying here are the 130 stories that, you know, we embed in here. Extract them out of your LM tool. That's, that's asinine because nobody's going to read those. You've now gone from six pages to 60 pages and completely, you know, missed the point of this, right? So a good product manager, whoever's keeping this updated, it doesn't even have to be the product manager. They need to recognize that this is, like you said, super high level. It has to be relevant. Right? And have just enough detail to say this is what's going on and having that change history will help because you'll be able to tie back to the timing of those pivots. But then this should not serve as a dictionary of what's going on. This should serve as simply a list of things that, could input into a, a meeting, let's say. So if somebody is really interested. In a specific aspect, solutioning or the strategic piece of it. Right, right. Or more importantly the marketing aspect of it than Yeah, yeah, yeah, yeah. So you can have a discussion with them, right. And you can say, well, initially we thought the market was this big. Yeah, we did this experiment. Found out it was only this big, or it was bigger, whatever it is. Well, that's it. Where this document can be helpful. is in involving the appropriate stakeholders at the appropriate time, a. k. a. stakeholder collaboration. That that's what this ties back to is like, I'm bringing in sales. I'm bringing in marketing. I'm getting their input and and they're and they're giving me questions back. Hey. I don't think this market is this size. You need to run some tests. You need to go gather some data. You need to go pull some surveys or something. You know what I mean? Whatever. Something like that. Okay. I, because I know when I invite them back to the big kickoff session where I'm asking for funding or whatever I'm asking for they're going to want to know that their questions have been answered and it's my responsibility as a product manager to engage them before we get to the point. Where they're asking those questions. So if I haven't synced back with them, it says, Hey, I've answered your questions and these are the answers I'm going to roll it into the document. So anyone else can see what we talked about. Okay, cool. And then i'm gonna sync back with you to make sure you don't have any further questions That I need to track down tracking down all those questions This is like the the four the four risks the marty Cagan four risks, you know usability, viability. Feasibility. Feasibility. the usability, feasibility, business viability and value. What you're describing though is, is the intent behind this artifact. In, in practice, we don't necessarily see that in, you know, in practice I see project managers. Delegating a whole bunch of detail to BAs to fill in and this document bloats to 100 plus pages is what I've seen. Yeah, that's exactly what I'm trying to avoid. A document like this is, I'd say, absolutely needed before you get funding because your finance is going to look at this information. They're going to run some ratios and calculations, et cetera, right? Uh, NPV, those kinds of calculations. When are we going to start making money? You know, sure, it's laden with a bunch of assumptions, but they're going to need all of that before they say, yeah, sure, go spend, you know, 10 million developing this thing that we're hoping will turn a profit. They won't necessarily just grant you the money on hope and prayer. They're going to want to know these numbers. And if you don't know the numbers... Then what chance do you have? Well, I'm glad, I'm glad you took us down this road. Because, I don't, I don't necessarily agree that all of this has to be done. Because the, the, the template that I was referring to earlier that I'll, I'll pull up now and again, for anyone that's listening, you're not going to be able to see what I'm sharing on the screen. Uh, but I will put the link to this, image. It's a, it's a, it's a JPA. It's a screen cap of a mirror board that I have created to help the product managers and the company leadership figure out. What they want to accomplish in terms of, product vision and strategies and dealing with business problems and goals. It has several swim lanes. And at the top you have the company's mission and vision. And you have the product vision; below product vision, we have strategies. Now, Om and I were talking about this before we started the podcast. Strategies, arguably, can flip flop in the lane where product vision lives. So, strategies could live in that, lane. Or they could be mixed in one lane, potentially. The upper lanes are the why are we doing this and the middle lanes are the what problems are we trying to solve and the lower lanes are the goals. That we're going to one after another, so, the idea, the idea here, with relation to the six page, where you're like, well, you need to kind of give everyone an idea of what you're going to be, involved in before you do it, because otherwise you're not going to get funding. I kind of agree with that because most companies are, have traditional financial models where you do have to prove a bunch of stuff before you do it. But, the most agile companies will, start with a strategy. They'll start with that third lane that I have on here. They'll start with a vision. From the vision, they'll say, Okay, this is our vision. We want to be... Like the Tesla vision like we want to enable the whole the entire world run on renewable energy, right? And they'll say well, how are we gonna do that? Well, we're gonna create a really expensive really fast Roadster and make a ton of money off this really high end car that runs completely off electric and we'll market it to high end clients, and then the money that we get, because that's a high margin car. We make a lot of profit on the car. The money that we get from that car, we'll turn around and invest in developing a... A super affordable car an affordable car a car that's under whatever I don't know thirty thousand dollars But the the tesla equivalent of thirty thousand dollars is probably eighty thousand dollars I don't know how much normal Tesla costs But the point is they have one strategy And that strategy is still going because they still produce that line of cars And they leap they use the money and they leap from that one strategy to another strategy Now, segmenting the market and proving that strategy will work, that's a whole different deal. And also below the strategy is what is the problem that we are seeking to solve with this strategy. A lot of people start with the, what is the problem we're seeking to solve. First and reverse engineer their way back to the strategy. And that is completely okay. I'm not trying to say that's, that's wrong or whatever, because there could be several problems at one strategy solves. It's okay to work backwards at this. The point is I'm not starting on the bottom of this chart saying we're going to develop this and then trying to work our way all the way back up to the vision. That's not the way that this, that you, I don't, I doubt very much you'll be successful that way. Maybe if you start with a goal and you work your way back up to the problem, but I, that, that, even that seems like you're. for a, you're searching for a problem for your solution. That's what it seems like to me. I think the, where you start is, either you start with a problem or you start with a strategy and you get either of those. From your company vision or your product vision, one or the other. this is sort of like my own six pager because each section of the six pager fits one of these categories. And the, the, the gold bars on the left. Hey, we only, we're only showing you gold bars. The gold bars on the left. Mission and Vision, Strategy, the Diagnosis, the Guiding Policy, and the Actions that come from that Guiding Policy. Those all come from the Richard Rumelt, Good Strategy, Bad Strategy book. Oh yeah, this is, this is uh, so this is gold here. Yeah. And gray and blue. But um, the thing that... Is that pretty gray? A little. This is, this is I think... A lot better as a tool to collaborate with others in, in co creating some of this stuff, right? I mean, the mission may be given to you because you're a product manager. The company is huge. They've got various lines of products. You're not going to create a new vision necessarily. Might have a product vision that you work on. But when you're collaborating in Miro, in your, in your case, it could be anything. This is fantastic. You're still not going to go to a CFO and say, look at this. I've done all this work. Please give me money. Yeah. It's all gonna work. Well, each of you, I mean, your, your strategies, your strategies should be measurable. I mean, this is where OKRs kind of come in as a framework. Your strategies should be measurable. Your goals and objectives and the actions or experiments you're, you're moving forward with to figure out which goal or objective is the right one to move forward with. All those experiments, like they may not be part of your initial document because you need to engage a team to figure all that stuff out. So like the high level goals, maybe. Maybe that'll be part of like, these are some things that we could try would be part of your six pager, your PRD, but you got to be ready to throw all those out as soon as like, Oh, we did, we did a couple of actions to figure out if this is the right goal or objective. And we found out very quickly that like, these are all everything I put in the PRD or all the wrong goals. And that's okay, So it should be okay, should be okay. But again, like if you're, if you're an environment where you don't get any, any shred of funding until, you know, the finances, until finances on your side. This graphic, what I just showed, everything relies on you trying a couple of different things to figure out where the signals at, Hey, is this the right goal? Hey, is this the right strategy? Hey, is this the right problem for these customers? Right? Let's make sure. We got to make sure, I guess you can, you could, you could say, but when you're writing the PRD part of writing the PRD is the process of making sure it's the right problem, but I don't know that the PRD just seems to me like it seems too easy to take the template of the PRD and go over here in the business and do it in a silo. You know what I mean? It seems too easy to fall into that trap, and that's why I'm super, I don't know, man, I'm, I'm still, the more we talk about it in this podcast, the more I'm really on the fence about these giant documents about everything we could do. They shouldn't be giant documents, right? It's, it's a six pager at worst, and maybe just a mirror board at best. So it should not be a giant document. If it takes you longer to read a PRD than it does to consume a cup of coffee, you've not got it. Yeah, on that statement, I agree with you. If it's going to stay as a, this is the core of what we're doing. I guess what I'm asking is, is a PRD considered the thing that you need to launch and then once it's live, it works through all the rest of the reporting mechanisms of the business or Is, do you have to keep coming back to the original document and making sure it's current? I guess that's my question. That's, that's a really good question because that is often raised by those that are, you know, vehemently against doing a PRD. It's too difficult to keep up to date, right? And I don't think there's a black and white answer to that. I think the answer is it depends because if your pivot is so hard. That your product looks way different. What you should have been doing all along is to make those updates so that a year later, you don't say, wow, this is radically different now and keep it updated. But that doesn't mean you've got to go change all of the other stuff that you showed on your diagram, the vision, et cetera, doesn't really change. What changes is through the results of these experiments we conducted, we have found this. So we've basically validated or invalidated our assumption, right? And therefore we're making pivot. So in a long answer, all I'm saying is Keep it updated. Design your experiments such that the pivots are small enough and don't go overboard with the details. Just put in the relevant stuff in there. Now whether you create a brand new one depends on whether the product is now so radically different. Right? Then, yeah, you might, really nobody dies on that hill if you create a new one. You simply point to it from the old one. So in the Amazon six pager example, the opening sections are the purpose of the document, basic executive summary, right? The narrative, which includes a bit of the marketing and the audience segmentation and whatnot. And then the problem you're trying to solve. Those are the three things that are in the early sections. And then they go into solutions, meaning which ways could we solve this problem. How is that different from like, an epic and a feature and then, jira has initiative and then epic. And then stories, right? Aha has business objectives and goals and, oh, okay. No epics. Yeah. I was going to say is there a reason to write this in document form rather than write the epic or initiative, let's say like the super epic or initiative, the high, high, high level work item and into the high level work item, you write the purpose and the narrative and the market information and the problem you're trying to solve and then in the epics, you basically each epic is a potential solution to your problem. And then from there, each epic, you can kind of decide like which one we should work on or test each one or whatever. And then maybe write stories or spec out, you know what I mean? To get your scope with some of the other documents that I think weren't really that great, but you could do it that way. I feel, there's a way you can do it in, in whatever ALM tool you're using. And then it becomes like a refinement activity more than it becomes like a document review activity. I think you achieve the same objective in the end, if you do it well, right. There's a structure itself doesn't really change radically. It's just got different labels now, right? You have a super epic and the super epic contains some of these things. Then the, the narrative, for example, maybe even the problem, some ALM tools are better suited at this than others that ALM tools that are product centric, I think are better suited. Like I know about, I have more than I do about. You know, other ALM tools , in the product space, but, in the dev space. Yeah. I mean, you could create it that way and then collapse that up and expand it down as needed. Yeah. You could do that. You could do that. I was thinking to myself and I was like, well, the, the business would say like, well, the advantage of a document is it's all in one place. And I can just read it very, very quickly. Plus they never go into LMTLS. And yeah, and I don't even know if I have access to the system anyway. And also, the interface with JIRA sucks. So why would I use it? And you know what? I don't really have anything to say against that. It does suck. It does. And why would you use it? Well, when we're calling out the problems in JIRA, you know we're done. I was already on the fence going into this with an initial leaning of like, this is a lot of bureaucracy to stack on top of all the stuff I'm already doing. Now that we've kind of talked through it with just like just for the alignment throughout the business On launch not necessarily on keeping it up as it goes along but on launch I'm kind of leaning towards it because every, every piece of content you generated in this document, you can take and move into your ALM tool. Easy. No problem. And I would even say like if an enterprising couple of people wanted to generate a Jira plugin that just auto generated this, that would be amazing. I was on the fence when we started leaning one way. I'm still on the fence. But I kind of, I don't know, I'm kind of leaning the other way now. I'm happy to hear you say that. You know, I do want to say, in conclusion, that if you're doing PRDs, and your PRDs are 130 pages long, and you have a nice, Document change history and every little thing that somebody puts in there, you're putting in your change history, you've missed the boat. Yeah, and also, don't talk to me. Exactly. Who has time for all of that? But that's what I see. I see project managers doing this stuff. Purely from a perspective of, I'm going to document it so that nobody can blame me. Again, if you're doing that, you've... Missed the boat. In fact, you're in the wrong port. I'm interested in anyone that's kind of listened to, my ramblings on this and survived the entire podcast to the end congratulations to both of you. Go to ArguingAgile.com. com fill out the form. Yeah, that's right. Um, but, yeah, I'm interested , if this really is like a change in anyone's minds or if, if anyone came to any learnings, cause I, like I said, I, I'm sort of leaning the other way on this one. Well, yeah, and uh, if you've listened to this and you've had some experience with PRD's good bad Otherwise, let us know we're interested in hearing from you. Oh, and uh also like and subscribe below