Everything You Need to Know About Context Engineering in 40 Minutes | Ravi Mehta

It kind of feels like AI slot and it's a very subtle thing that makes it feel that way. Common mistake I see with prototyping is people don't think about context within that 360° way. People just write a quick prompt or a quick little mini spec and expect the prototype tool to be able to create something as high fidelity as what they used to create before. So the next type of context for us to think through is the data context. JSON is a really good way to define structured data. And I have this data file. that's completely separate. I can just replace it with psychedelic rock. Save it. And now our prototype is going to use a completely different data set. We've moved from a really fast assembly line approach to much more of a jazz band. — Okay, welcome everyone. My guest today is Ravi. Uh Ravi was previously CPO of Tinder, but now he is a product adviser and full-time vibe coder. — I do a lot of vive coding. Yes, — you do, right? Yeah. And I think Robbie, you've done more thinking on AI prototyping than anyone else that I know. So yeah, really excited to have you demo your workflows and show us how it should be done. — Awesome. I'm excited for the conversation. — Yeah. So before we get into the demo

maybe let's talk about, you know, this is like buzz word going around like you shouldn't do prompt engineering, you should do context engineering, but what does that actually even mean? Like do you have some slides talking about that? — Yeah, I've got some slides. I've talked to a few companies about this. I actually really like the shift away from prompt engineering to context engineering because I feel like it does a much better job uh framing what is actually the task at hand. And so I have a few slides that I pulled together which think about what is context engineering from like very first principles of what are LLMs doing and why is context so important — and the move to context engineering I think sort of captures this overall shift from the idea that you're having a conversation to actually designing all of the information that an LLM or other AI models need to do their work. So I like this definition of context engineering which is context engineering is designing and building systems that provide an AI model with the right information and tools to accomplish the task. And I think a lot of the a common mistake I see with prototyping is people don't think about context within that 360° way. And as a result, people just, you know, write a quick prompt or a quick little mini spec and expect the prototype tool to be able to create something as high fidelity as what they used to create before when they had all of these different artifacts that are a critical part of the product life cycle. And so something that you know we'll walk through today is how you can think about context in a more full stack way and pull in the essential elements that include the thing that looks a lot like a prompt or a spec as well as other types of context that can be really helpful in terms of getting the output that you want from an AI prototyping tool or a vibe coding tool. — Yeah. Like when I make prototypes, a lot of it is just like yeah, I I use some screenshots or oneline prompts and just a lot of the prototypes that I make are kind of like throwaway. But I think your point is that if you set this up properly, uh because a lot of people are going to prototype from an existing product, right? They're trying to add a new feature to existing product. — So you set this up properly, it'll be much easier to kind of just like keep using the same prototype over again to add different fe features. — Yeah. And I think it's okay if ultimately your prototype is disposable. That's totally fine. What's important is that a really good prototype is a good decision-making tool. And so you go into creating the prototype with the idea of what decision do I want to help facilitate as a result of this prototype. And you know if for example the prototype is going to help you have conversations with customers, then the prototype has to look and feel enough like your product that there's a suspension of disbelief. And if there isn't that, then customers kind of shift out of actually talking about your prototype and what they do into the moment to theorizing about what they would do. And you know, as soon as a customer talks about what they would do, the accuracy of the research that you're getting is much less. And you want them to instead really feel like they're using your product, have the suspension of disbelief, and have them talk about what they are doing rather than what they would do. And in order to do that, the prototype needs to have a level of fidelity that's hard to get with sort of traditional prompting techniques. And I'll talk about some ways um and show some ways where you can actually get uh much more robust output from a prototyping tool. — Okay. Do you want to just uh get into it then? Like should we just do a demo of like how to prototype design systems, all that kind of stuff? Should we try it? — Absolutely. I think one of the fun things that I've seen with prototyping tools and the way that I approach them is you can use not just the tool itself, but you can use multiple tools in concert to sort of almost hack your own multi- aent system. Right? You might use claude for one thing, chat for another thing, the prototyping tool for another thing. And in that way, you're only giving the prototyping tool the context that it absolutely needs rather than polluting the tool with a lot of context that are intermediary steps to getting to what you want. Um, so that sounds a little abstract. I'll show what that

means. Um, but here we have uh Reforge Build uh which is a great prototyping tool. It's aimed specifically at teams that are building prototypes of existing products. So where they have um context or design systems or other things that they want to integrate into their prototyping process. And if we think about, you know, a typical um a typical prompt or a typical sort of context that we would start out with for a prototype, it might look something like this. So imagine you want to create a page for a music streaming app like Spotify where a person can see a page for a particular genre and actually see a list of albums related to that genre maybe sorted by timeline. So you can see how a genre has evolved over time. So in this particular case I have a functionally oriented um prompt that looks and feels a lot like a mini spec. So build a music genre detail page for down tempmpo. So that's the music genre that we want to use with the following sections. I want to have a hero image. large placeholder image up top. I want to have a genre header. So display the name of the genre in a bold title. I want to have some tags for artists that are really important for this genre. I want to have a timeline of albums. So a chronic chronological list of landmark albums grouped by year. For each album, I want to have artwork and name and album title and a short description of the album's significance. So, this isn't a ton of context, but it's enough that the tool can really understand what we're building. Um, so if I get it started, and I've actually got some of these kind of pre-built, so we don't have to wait around as it's building. What's really cool now is um whether it's Reforge Builds or other tools, they're going to go in and they're going to expand this prompt and reason about what exactly do you want and it'll go into kind of this multi-step mode where it's creating a to-do list and then working its way through the to-do list to create something that despite the fact that we've given it very little information um is actually a pretty good output. Um, and so I'll actually just jump to um the finished product. And so here I use this prompt. And here's what got built. And it's actually pretty incredible that based on a very small amount of information that we got a pretty nice output. And it took a lot of steps for us. Um, it generated a um overview of the down tempmpo music genre. It generated some key artists. All of this is coming out of the training data for the models. These models have gotten so powerful that you know pretty much anything that you want to ask questions about. Um it can pull in information. So even though we're using the model for AI prototyping, it's essentially doing copywriting for us as well. Um and then we've got our list of albums organized by year. Um and you know it's working pretty well, but there's also some things that um you know kind of break the suspension of disbelief. I think the biggest one is probably, you know, we're not seeing album covers and so we would expect in a music streaming platform that we would see album covers, we would see um, you know, some additional details that make this feel like a more realistic experience. But it's a start and you can certainly iterate from here. But if you start to think differently about the different types of context that are available, you can actually get much more specific and have a lot more control over what gets built and build something that's a lot more robust. This episode is brought to you by Granola. If you're in back-toback meetings, you know how much work it is to take notes live and clean them up afterwards. That's why I love Granola, the best AI meeting notes app in the market. Here's how I use it. Granola automatically takes notes during a meeting and I can add my own notes, too. After the meeting ends, I use a Granola recipe to extract clear takeaways and next steps in the exact format that I want. Then I can just share her notes directly in Slack with my colleagues or even get Granola to share her notes automatically. Honestly, of all the AI apps that I use, Granola is the one that saves me the most time. Try it now at granola. ai/pater and use the code Peter to sign up and get three months free. That's granola. ai/pater. Now back to our episode.

— So what are the different levels of context that are available? — Yes. So I think the next level is um this is functional context. The next level that is really important is visual context. Um and so when we're designing a product, a wireframe is usually an incredibly important part of building a product. The analogy I like to use here is um you know, if you're building a house, you would never work with an architect that doesn't know how to draw blueprints, right? if they just said to you, "Here's a memo. Here's what your house is going to look like. It's going to have these rooms. It's going to be this square footage. " Um, you would never go ahead and build that house. Because no matter how detailed that memo is, you can't really visualize what the end product is going to look like. And buildings are three-dimensional experiences or two-dimensional experiences. Um, and software is a visual two-dimensional experience. And so you need to be able to see the blueprints in order to really understand how all of the specs are getting rendered into a particular experience. And so here I've very quickly in Figma uh just taken 20 minutes done a wireframe um and sort of outlined what um I want this interface to look like. It's actually surprising with just words how close to the wireframe um the prototyping tool was able to get. Um, but there's a couple of things that I don't love about it. Um, you know, I'm not sure about this header. It feels uh not quite as tight as we would like. It doesn't work great at all levels of responsiveness. So, if I got go down to uh mobile um mobile width, a lot of space is being taken up by the album cover. Um, and so we don't have as much space to work with um for the descriptions. Whereas here in the design, I've specifically solved for that and said actually, you know, we want the album cover and the artist and the album name to be on its own line. And then we'll have a full width section for the description of the album as well as the tags. And so we've made some very specific design decisions here that we want to um make sure are incorporated. And so we can actually just provide that as a um here's actually you know we finished the generation here you know also did a really nice job um but you know we can just provide the wireframe and nothing else um and get an output and so here I've just uploaded that particular wireframe that I showed have a very short prompt so build a music genre detail page for down tempmpo using the attached wireframe use a dark theme with full rounded buttons, use these particular colors, and it's done a remarkably good job of thinking about the image that I provided it, not literally, but from the perspective of a wireframe, and it's filled out a bunch of details. And so now we have, you know, essentially a, you know, kind of living version of the wireframe that we just created. It doesn't have much content because we didn't have that content in the wireframe, but it's got a much nicer user um interface and user experience. And so here, this is kind of two different versions of context. You know, in this case, we start with text space functional context. In this case, we're providing visual context, but we're still not at a point where this is something we could put in front of customers in part because we've got dummy data. And so the next type of context to for us to think through is the data context. And this is really an important thing that I think a lot of people that are building prototypes should be thinking more about is what is the underlying data that drives your experience. — Yeah, let's take a look at that next. Yeah, that sounds good.

— Um, so let me pull up Claude. And this is where I think you can use multiple different tools to essentially prepare the context for your vibe coding session. um separately um and get to something that looks and feels really good before you're ready to use it as context within your vibe coding tool or your prototyping tool. Um so here I have a thread that I've already created with Claude. Um it says, you know, I'm interested in the history of down tempmpo music and I'd like to prototype a feature to browse music uh by history. Generate a JSON file. So JSON is a datacentric format um that any prototyping tool or vibe coding tool will understand. You know just like today we're using markdown to do a lot of prompting for um for you know various tools that we're using. JSON is similarly ubiquitous as a format and a really good way to define structured data. So generate a JSON file that includes the name of the genre, a description list of seminal artists in that genre. Include in that JSON an array of 15 to 20 albums that were milestones. For each album, include the album name, the release date, the artist name, a 1 to two sentence description um and a list of tags associated with that. So we've asked Claude to do quite a lot of work. Um it can use web search, it can use its own training data to fill this in. And what we get as an output is a highly structured file that has a bunch of data that we can now actually use to create a much more realistic prototype. So we know which genre we're using, um, you know, we've got a description, we've got, you know, who are the seminal artists, who are the, you know, what are the milestone albums, name, release date tags associated with that album. What's interesting here though is like one of the things that we saw in both of these prototypes is that album covers feel like an important part of the user experience. And we'd actually like the prototype to have accurate album covers to feel more realistic for users so that they're really using our prototype as if it's a real product. — Yep.

— And so one of the powerful things in Claude is you can add in MCP servers. And so in this case, I added in an MCP server to get the album cover for any particular album. I couldn't find exactly the MCP server that I wanted. So I actually created the MCP server in cloud code. Um, and you know, that took about an hour. Um, but it was good cuz I was able to create something where I could get album covers from free services rather than having to have uh a Spotify API account. — Okay. — And so I asked it to do that. It uses the MCPc MCP server goes through for every single album. Um identifies the URL has the cover URL um and then in this case it provides me both the cover um it provides me the URL for um every single album. So we've got here you know if I were to go in and look at this particular image I'll see the album cover for this particular album. So you basically like uh in cloud code you're like hey find me some free sources of album covers and then I found the user or something. Yeah. — Yeah. Exactly. And um you know in this case we're using the album cover MCP server. So it can go out it can make an API call and say you know for this artist Mortiva for this album deep dive give me the URL album cover. Um and then you can add that to your data set. You could also do that for Unsplash for example. Um, so if you want uh basically images related to anything, it can go out to Unsplash, pull in a URL, and now our data set not just has text data, but it also has um URLs to actual realistic images. And now what I can do is when I prompt, I can take all of this JSON, just copy the file. — And so here I've created a database prompt. So I said, you know, very simply just build a music genre detail page for down tempmpo using the following data. In this particular case, I haven't given it any other information about what I want the page to look like. I haven't said that I want a header. um a yearby-year list of albums. I'm just giving it the data that we created in Claude. And the prototyping tool is then able to actually understand the structure of that data. um because JSON files are the sort of ubiquitous structured data format and then it's figuring out for itself what's the right UX around this and so we have a few interesting new things here like the ability to follow a genre the ability to play um play the essential albums in the genre we have the um about section we have a bunch of seminal artists and then we've actually got kind of a different interface here which has some cool elements where it's a 2x two grid I can search I can determine the sort I can um just uh filter down to particular tags like only those that um are related to hip hop hiphop or only those that have sort of more of a c cinematic feel. And so in this case because we've given it the underlying data has actually said okay based on this data here's what the UX should look like um and here's some of the features that they likely want based on this. And so now we have three completely different ways of building our prototype. — The album color makes a big difference. Yeah. four. — It does make a huge difference. So, if you go down, you kind of look, it just feels a lot more realistic. This is the first prototype that I feel like we could put in front of users and actually get really good user data. — This got us, you know, part of the way there. Um, but it still feels like, you know, it kind of feels like AI slot. Um, and it's a very subtle thing that makes it feel that way. And that's the AI covers here. We're very specific about the visuals. I like the UX. you know, I specifically designed the UX this way, but you know, we don't have accurate data, so we can't put this in front of customers. Here, we're starting to get to something that is more realistic because we're providing it with accurate data. Um, but it's not quite what I had imagined. I actually like some of the things here better, and so AI can be a good brainstorming tool in that way. But if I have a really specific design that I want to test, the final step is

pulling all of that together into a full stack prompt. Um, and so here we have a full stack prompt that focuses on functional context, visual context, and data context. And so, um, and then I've used markdown here to make the prompt understandable in a more structured way to the LLM. So, build a music genre evolution feature. We've got all of the functional requirements that we've talked about. Says, design the page based on the attached wireframe. I've attached the wireframe. Use these um these colors and then populate the page with real down tempmpo content using the following data. Um I added a couple of things to make sure that it's pulling uh the cover album uh the album covers from the URL data. Um, and then I've asked it to save the data uh as a separate file. It's called data. json. And I'll show why we do that in a second. And then I've just pasted in the JSON data that we had generated in Claude. And now we have this really nice, very realistic looking interface. It looks a lot like the wireframe that I wanted. Um, I was able to build that wireframe quickly in Figma. You can also use a handdrawn sketch or you can use balsamic, whatever you want. the LM do a remarkably good job of interpreting those. We've got realistic um album data, album covers, tags. Um and so now this is something that it feels polished, doesn't feel like AI slop. We can put it in front of users and see whether or not this is the sort of experience that they would want. Um and we can iterate on it from here, right? If we want to say, you know, make the album covers larger, we can do that. And one of the things that uh makes this a particularly good way to prototype is by giving the tool the visual context, the data context, the functional context, it's actually built the code in a way that's pretty modular. And so when we ask to make the album covers bigger, um it'll make them bigger, but it'll also make sure that it's pulling in all of the image data and do a really nice job of um responding to our requests. And so, um, you know, when you start in this way, it creates a prototype that is a lot more iterable, um, than if you're letting the AI kind of figure out, um, all of the details. In that case, you might get an underlying structure that doesn't make sense. — It's kind of funny to think about it because, you know, we've both been in product for a while and, um, in some ways the waterfall process is kind of dead because like, you know, it's so much easier to just generate these prototypes, — but I don't think it's actually dead. It just kind of accelerated because like what you just walked through is actually just uh writing the spec creating the wireframes and even thinking about the data structure before you get this thing to actually code right so instead of just like a two week wireframe two week process now it's like a 10-minute waterfall process but still have to do it yeah the analogy I really like is we've moved from a really fast assembly line where you start with the spec and so products involved and then you do design engineering and kind and then you launch and things follow this linear process. We've moved from that assembly line approach to much more of a jazz band. If you think about a jazz band, everyone who's playing an instrument, you know, has a specialty, but people are riffing off of each other and there's no one that's necessarily leading. The lead might change um you know, from beat to beat depending on who's you know, who's playing and who's kind of leading the rhythm or the melody. And that kind of way of working together where we're all rifting off of each other. There's not as much of an established structure, I think, is going to become the norm. Everyone's got a really important set of skills to bring to the table. I don't think product design engineering go away, but I think we work together in a much more cohesive way. — Yeah, I think Jazzband sounds a lot more fun than assembly line to work for. So, you know, — Exactly. For sure. — Yeah. — And so, one of the cool things here is we've got this really nice prototype. this is something we could put in front of customers. But we also know customers, you know, sort of have their own perspective on things. And if there's a person who's interested in a completely different genre of music than down tempmpo, they may or may not engage with this in the way that we want them to um because they don't really understand the genre. They're not that interested in it. And so, as part of the prompt, I asked the tool um to save a separate file um called data. json.

And here's where we have all of our data. Um, and what's nice is this makes the whole design a lot more modular. And so if I go back into Claude, I can actually say, um, now generate a similar history for Psychedelic Rock, generate a JSON file and include album covers using the album cover MCP server. That took about 15 minutes or so to run. But I got at the end a file that is completely different. Psychedelic rock. It's got a description of that particular genre. It's got a bunch of the seinal artists in that genre, milestone albums. It's got the album covers. Now I can just copy this data. Come in here and I have this data file. It's completely separate. I can just replace it with psychedelic rock, — save it, and now our prototype is going to use a completely different data set. So, we can actually change what we're putting in front of the customer or what we're testing in a way that's really personalized that will get us much better data. So, now if I go back to the prototype, now we have a page for psychedelic rock. We have a list of the key artists and then we could see how the genre evolved over time all by just pasting in a different file. And so this way of thinking about context in a full stack way generates more realistic, more authentic prototypes, but it also generates better structured prototypes that are more flexible and robust because this idea of data context, visual context, usability, functional context, um is pretty similar to how software is built. um software, you have the front end, you have the underlying data structure, um you have the services. Uh and so when you give it this style of, you know, multi-dimensional context, it understands what the underlying architecture of the prototype should be better and it creates something that's a lot more flexible. — Yeah. Like dude, I've gone so lazy. I I just gave the AI like vague requests and I thought what you were going to do with the JSON was paste into the AI chat window and make it update. But the fact that you have a separate uh file for the data actually makes just way just copy and paste the stuff directly, right? It's like way faster and way easier. So I try to keep my requests um in the chat really clean and then I use other tools to prepare the data as I need it or um you know sometimes I edit the code directly or just replace the code directly. — Awesome. Let me dive a little bit deeper into one area. So I think yeah I think like you said what makes prototypes a lot more engaging is the visuals and like the art right. So like — and like is that your typical process cuz I know there is like free stuff like um Unsplash and maybe use like Nanobanana or something to generate some images but the fact that you went over to cloud code to build an MCP server is it's pretty unique I think like is that like how do you do that? you just kind of like, you know, set up a Clockwork project be like, "Hey, you know, like for example, let's say we're trying to build the thing for movies instead of albums. " Do you just be like, "Hey, hey, Clock, like I want to build a movie album thing. Can you set up an MCP server for me and find some free sources of movie cover art? " Is that kind of the prompt or how do you — Yeah, I would check and see if there's an MCP server first. There probably is a movie cover MCP server. Um, at the time that I was doing this, I couldn't quite get the album cover MCP servers to work in the way that I wanted. So, I just went to Cloud Code and said, "Hey, you know, here's what I'm looking for. I want to give you an album name and an artist, and I want to get back a URL, and I want it to be free. I don't want to have it have to have an API key. Uh, and Daer provides a lot of this album art for free. " And so, it just built the server based on that. Um, and then I would test it a little bit and was able to get it to a nice point where I could use it within Cloud. And now I have it um you know I built that a few months ago and I use it whenever I do this demo or if I have an have a similar need. Um I also have one for uh locations for um a travel oriented prototype. So uh for the Eiffel Tower in Paris or those sorts of things. And so I think the combination of using cloud potentially using cloud skills or MCP servers gives you a really nice pallet of different capabilities with which to create um data sets that feel authentic. — And the MCP server after you made it, you just like deploy it to GitHub or something and then you just added it to this thing and then it works. Yeah, — you can do um a local MCP server. So you just uh you need to edit the uh local settings for cloud. So it's just code that's sitting on my computer. I haven't had to deploy it anywhere.

— Got it. Okay. So, let me ask you some hot takes. I was talking to Jeff who is RAMP's CPL. So, I was asking him to show me his prototyping process too and he said his PMs don't prototype. They just like they just build and submit PRs cuz like the prototyping phase is almost like a interm like if this thing is so easy why just let them like actually submit real code. Do you have any thoughts about that or — I do um you know use another analogy. I think it's like the difference between sketching and painting and oil painting, right? Like if you know what you want and you're ready to commit to that deal with all of the complexity and the time involved in creating production code and shipping production code, then absolutely do it. The fact that like a non-technical person can do that is fantastic. A lot of times I think the value of prototyping is the fact that it is really flexible that you don't have to be tied to what how your system works today to the data that your system has today. And so you know most artists before they create something they do a bunch of sketches and studies to figure out what direction they want to go in. I think that skill is still really helpful for um product folks and for designers who want to explore the solution space before committing to a direction and do that unencumbered by you know all of the details that are required for production code. — Okay. So my second question is like a lot of designers still use Figma and some of these other tools, right? And um — and I totally understand the design process is you have to explore a bunch of different solutions first. You have to diverge first and then you figure out what you want to do and then you converge to like one solution. But like I almost feel like these days it's like faster to explore using code because I so I can just like prompt this thing to be like hey make a 2x2 grid or something and then it has another v variation. — So yeah. Do you do you think these design tools are kind of like fading importance and people just going to be like, you know, doing this stuff in code or — I don't Yeah. Um and I know it's a it's really topical. I don't think so. I think that there are um two different ways to think. There's like a textbased way to think and there's a visual way to think. And so, you know, to go back to that analogy of the architect and the blueprints, you would never build a house without blueprints. You shouldn't be building software something that is a visual experience without exploring first what the visuals look like. You can do that in code and you could do that with a prototyping tool, but it's going to require a whole lot of back and forth to get exactly what you want if you have a spe particular experience in mind versus just, you know, you could draw something on a piece of paper and take a photo of it. You can use balsamic. You can use Figma if you're really good at it. And so I think it's important for PMs especially, but also for designers as well as engineers to just understand that sometimes visual thinking and a visual prompt is the best way to explain what you want to the model versus something entirely in text. And then you know part of what I'm advocating here is it doesn't have to be one or the other. You can use these different forms of context to be really specific about what you want the output to be. You don't have to use all three types of context all the time. You know, you might want to push and pull. In fact, if we look at the data centric UI, the fact that we just provided the data and that the AI filled in the gaps created some interesting um conclusions like we want to have a 2x two grid and these filters. And so that's an interesting way to brainstorm. But I think it's important to have in your toolbox these different ways of thinking, providing context to the AI um so that you can have a much shorter um path from what you're imagining to you know what is actually in front of you from a prototype standpoint or from a production feature standpoint. — Yeah, hope hopefully like I think Figma's already working on this where like you can take this prototype, you can plop into Figma, you can move some boxes around and do some stuff and then you can plop it back into code. So it's like you said, it's kind of like a jazz band. you're mixing and matching different tools to just explore that idea. — Absolutely. And I think that kind of round trip Figma's getting better. It's not quite there yet. Um, cursor just added the ability to do some, you know, visual manipulation within the tool which is really good. Um, V0ero has some of that as well. And so yeah, I think it's pretty exciting that, you know, soon we're going to be able to do that sort of round tripping between code and visuals and copy and really dial in the experience. And ultimately, I think as AI does more and more for us on the execution side, the craft around what do I want the copy to say? layout to be? What font do I want to use? What spacing that I want All of that stuff that's really taste based is going to become more

important and that's going to set apart a product that feels like really dialed in versus AI slop. Awesome. I think last question. So, you know, um you and I grew up in PM where like you know, everyone like I remember working at Microsoft and people were writing like 17page PRDS. — Yeah. I was there too. — Yeah. And and like part of me is so glad that phase is hopefully over at most companies. But I think I do think the exercise of writing a PRD like there's stuff that is not covered on a prototype. Like for example, like who are you building for? What problem are you solving? What kind of goals are you you're trying to achieve? Like that kind of stuff I think should probably still come before this, right? Or maybe like um like may maybe the PRD still exists, but like maybe even after doing this, you still write a PRD, but it just doesn't have all like the details about the user stories and all that crap. Like it just focus on like what is the problem? What is the milestones? I think we're used to working in sort of the strict linear fashion of the PRD comes first, then we do the wireframes, detailed designs, then we do the MVP because it's actually really it has been really expensive to create each one of those artifacts. So, we want only want to create the more expensive artifact once we have some signal that we're in the right direction. Now, I think we don't need to have that linear relationship. So, you know, sometimes the PRD will come before the prototype, after the prototype, and that's totally fine. I think the thing that is important is to understand that we have all of these tools with which to explore a solution space. Really important is to understand the questions that we want to answer. When you write uh a prototype or when you write a PRD, it's basically to answer a set of questions. I think what we'll often see is people dive straight into a tool, they play around with the feature, they may get it in front of customers, they get some feedback, and then they say, "Okay, I think we're actually we're on to the right thing um in terms of what we want to solve for the customer, how we're going to do it. " Now, I'm going to write the PRD. I'm going to link to the prototype from the PRD, but in that PRD, I'm going to explain a bunch of things that the prototype can't, which is, you know, what is the problem we're trying to solve? What does success look like in terms of the metrics? How does this ladder up to our long-term strategy? And you know, by doing that, you essentially create sort of this well-rounded picture of what you're doing where each individual artifact alone is not enough to explain itself, but collectively you have a very clear um path forward. And you know, I think that process is really organic. You know, the steps are going to get mixed up, but that's okay. The real important thing is what do we need in order to establish the right direction and create value for the customer company. — Yeah. And I I do think having these prototypes cuz it used to be like people follow this waterfall process for like 3 months and then they have a product and then they launch it and the people and the customer is like I actually don't want this like — Yeah. Exactly. — But now with the prototype, you know, like even without like any writeups, you can just show the stuff to customers. It's pretty cheap and it's pretty fun to make and then they can give you your initial reactions. It's like it feels way more engaging and viseral than like a document. Like you don't really know what the hell a document is talking about, but like a prototype like I I can tell you like I actually want this or I don't want this, right? This is way faster to get to an answer. I think — and it's great for everyone. It's great for execs, for stakeholders, for your team, for customers to all see it, use it, kind of figure out, okay, is this the right direction? I think a lot of times the best companies that were really good at being product ccentric were the ones that were comfortable doing a lot of wasted work like building a bunch of things that they knew that they were never going to ship. — But that's a privilege that only the biggest and most successful and most lucrative companies had. Now every company can do that. And so I think that's kind of like a mark of are you working in a really AI native way is are you creating a lot more stuff that you end up never shipping because you're finding out that wasn't the right thing early and you're finding out what the right thing actually is. — Yeah. As long as the stuff you're creating is not a 17page doc, you know. — Yes. Yes. 100%. — Cool. Well, Robbie, thanks so much, man. Like, where can people find you and your upcoming course? — Yeah. So, I've got a course upcoming on AI prototyping with Reforge. It's going to be completely free. Um we've got our first cohort starting next week actually and then we'll have another cohort in the spring. Um we're also going to do a video series. So that will be available soon. So you can find that course at Reforge. Just search for Reforge AI prototyping. Um and then you can find me online on Substack. Um so I have a Substack newsletter called Ravi on Product. I post uh once or twice a month. So would love to see you there. You can also connect with me on LinkedIn. — Awesome. I didn't realize your course is free. I I'll definitely take it and try it myself. — Definitely. — Yeah. — Uh it's an experiment we're trying, you know, we want to This is such an important skill. We want to make sure as many people as possible have access to it. — Cool. All right, Rory. Thanks so much, man. Yeah, it was great to see