If you've ever worked as a developer in a corporate environment, you've probably come across a product requirement document or PRD for short. This document enforces something extremely valuable. You have to understand what you are building before you build it. With Ralph Loops in mind, this document is actually very important. This document will be loaded into the context of the model on every single iteration. Remember, the context will be

be loaded into the context of the model on every single iteration. Remember, the context will be cleared between iterations, so our PRD will be at the base of the context window on every iteration. It's essentially the bigger picture for the model with all important decisions front-loaded. So, what is a PRD? Well, a product requirement document is a written description of the problem, the goal, the constraints, and most importantly, the success criteria. It answers some fundamental questions, like what are we building, why are we

criteria. It answers some fundamental questions, like what are we building, why are we building it, and when can we call it done? A typical PRD defines the destination, but not necessarily the route. And I say typical because an agent-ready product requirement document can, and often should, go a bit deeper. When you're working with humans, it's easy to clarify things through conversation, or incorporate land through 12 meetings, 3 follow-ups, and a

through conversation, or incorporate land through 12 meetings, 3 follow-ups, and a slack track that never dies. Agents don't attend meetings, they simply execute what's written. So, an agent-ready PRD doesn't just describe the destination, it actually adds guardrails by including things like code examples, API contracts, database schemas, and maybe even some light code, or studio code. Let's take a look at an actual PRD I defined to ship a feature into production

code, or studio code. Let's take a look at an actual PRD I defined to ship a feature into production in my app. But first, let me show you the problem. This was the onboarding form of our business, it's a pretty simple form we ask for the name of the business, the name of the owner, the last name, the email, the phone, we choose a password and we agree to the terms. And let's quickly fill this out. And after a successful onboarding, we land on our management interface and we

let's quickly fill this out. And after a successful onboarding, we land on our management interface and we see two products have been added. And before we jump into the product requirement document, let 's briefly take a look at the result. The new onboarding flow is split into two steps, we can switch our language to French, English, but let's keep it a Dutch for now. Let's choose a unique name. Let's leave our language on Dutch. And now we can choose the type of business we have, for

name. Let's leave our language on Dutch. And now we can choose the type of business we have, for example, a fry shop, let's fill out our personal details. Let's create our account. And now we get an error because we used example.com, which before was allowed, but we got a lot of lazy account. So in the new onboarding, we disallow it. Let's create our account. And now instead of landing on our management interface with only two products, we have 23 products already

instead of landing on our management interface with only two products, we have 23 products already filled out. And the products that are preloaded are context aware, because we chose a fry shop, we will get products that are relevant to fry shops. So this is a huge improvement. Now let's jump into the product requirement document. I'm not going to go over it in full detail, but you can find the entire document in the sample repository attached to this lesson.

find the entire document in the sample repository attached to this lesson. All right, we start with the problem. The onboarding added a lot of friction. The UX is bad due to it being a massive form, that's a slight exaggeration. But after onboarding the business owner must fill out the entire menu, as we saw before, we only had two non-context aware products pre-filled into the menu. Filling out the entire menu is a time- consuming process,

products pre-filled into the menu. Filling out the entire menu is a time- consuming process, and on top of that, the business owner will always land on a Dutch interface, even though they may prefer French. Then let's go to the goals. We want to modernize the UX. We want to collect the business category, which is very important. We want to support multiple language like we saw, and we basically want to reduce the time to first order by preloading relevant menu items for

and we basically want to reduce the time to first order by preloading relevant menu items for businesses. We have a few user stories, we have a few requirements. In here, we save things like the business categories, like fry shop, bakery, sandwich shop, etc, etc. We define our language selection, which sets this column on the business in the database. We talk about the preset structure, we'll talk about the validation, so we'll reject things like example.com to prevent lazy test

we'll talk about the validation, so we'll reject things like example.com to prevent lazy test accounts, and let's jump to the technical approach. We'll talk about the new files that have to be added, we'll talk about the modified files, and the database changes. In the database, we have to add a new string, the category, and we have to append this at the end, because our LLM likes to do things like this table, string, category, after title, and let's say it's null able, but this will

things like this table, string, category, after title, and let's say it's null able, but this will actually trigger an entire table rebuilt, leading to downtime in production. So we cannot do that. Below, we'll talk about some API endpoints, we'll talk about the front end components, we'll make sure to tell Ralph to reuse our existing components, so it doesn't go invent new components. And then we'll talk about some backend logic, we'll talk about the enums,

new components. And then we'll talk about some backend logic, we'll talk about the enums, we'll talk about the preset classes, we have some pseudocode that instructs the model how to call these preset classes, so we'll say fry shop preset apply to the entity and the business, if the category is fry shop. And this way, the model knows how we envision it. Then we'll talk about some testing strategies, we'll talk about the UX and the UI. It's also very important to

about some testing strategies, we'll talk about the UX and the UI. It's also very important to talk about the things that are out of scope, for example, email verifications or social logins, these things are out of scope. And finally, we'll reach our implementation tasks, which is the most important thing of the PRD. As I said before, this entire document will be fed to the model in a loop. So initially, it'll reach this task, it'll say create migration to add a category column

in a loop. So initially, it'll reach this task, it'll say create migration to add a category column to the business table, the model will do this. And when it's done, it'll mark the task as completed and exit. Then on the second iteration, it'll create the business category enum , mark that as done, it'll create the onboarding controller, mark that as done, etc, etc, until all the tasks are completed. After seeing this document, it's pretty clear that a lot of effort

all the tasks are completed. After seeing this document, it's pretty clear that a lot of effort went into it before building it. This type of upfront research is where we can actually shine as engineers. And I personally really like this step. We essentially give a strong outline to the model and have it fill in the blanks. By creating a PRD, we are forcing ourselves to think about the problem and front load the most important decisions. We need a new column in the business

the problem and front load the most important decisions. We need a new column in the business table to hold the category. The type of this column should be a string. And we append the column at the end, so we don't rebuild the MySQL table and lock it. And this way, we can safely execute the migration without downtime. For this category, we need an enum in PHP. The front end should live in our onboarding inertia app, and we need to reuse our existing component library,

live in our onboarding inertia app, and we need to reuse our existing component library, where we have things like drop downs and select pre-made. And the beauty is, we can actually have Cloud help us with creating this PRD using a dedicated skill. Join me in the next lesson, where I show you how.