← Behind the Craft
Behind the Craft
Everything You Need to Know About Context Engineering in 40 Minutes | Ravi Mehta
00:38:49
Loading summary
Transcript61 lines
- [00:00]
A
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 degree 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 structure structured data. 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. We've moved from a really fast assembly line approach to much more of a jazz band.
- [00:43]
B
Okay, welcome everyone. My guest today is Ravi. Ravi was previously the CPO of Tinder, but now he is a product advisor and full time vive coder.
- [00:53]
A
I do do a lot of vive coding. Yes, you do. Right?
- [00:55]
B
Yeah. And I think, Ravi, you've done more thinking on AI prototyp thing that anyone else I know. So, yeah, really excited to have you demo your workflows and show us how it should be done.
- [01:04]
A
Awesome. I'm excited for the conversation. Yeah.
- [01:07]
B
So before we get into the demo, maybe let's talk about, you know, this is like buzzword going around like you shouldn't do prompt engineering, you should do context engineering. But what does that actually even even mean? Like, do you have some slides talking about that?
- [01:17]
A
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 framing what is actually the task at hand. I have a few slides that I pulled together which think about what is context engineering from very first principles of what are LLMs doing and why is context so important? The move to context engineering, I think captures this overall shift from the idea that you're having a conversation to the idea that you're 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 degree way. And as a result 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 when they had all of these different artifacts that are a critical part of the product lifecycle. And so something that 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.
- [02:54]
B
Yeah, when I make prototypes, a lot of it is just like, yeah, I use some screenshots or one line 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, 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 keep using the same prototype over again to add different features.
- [03:19]
A
Yeah. And I think it's okay if ultimately your prototype is disposable, that's totally fine. But 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 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, 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 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 this suspension of disbelief and have them talk about what they are doing rather than what they would do.
- [04:16]
B
They.
- [04:17]
A
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 and show some ways where you can actually get much more robust output from a prototyping tool.
- [04:32]
B
Okay, do you want to just get into it then? Should we just do a demo of how to prototype design systems, all that kind of stuff? Should we try it?
- [04:39]
A
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 agent system. Right. You might use Claude for one thing, chatgpt 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. So that sounds a little abstract. I'll show what that means. But here we have Reforged Build, which is great prototyping tool. It's aimed specifically at teams that are building prototypes of existing products. So where they have context or design systems or other things that they want to integrate into their prototyping process. And if we think about. 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 prompt that looks and feels a lot like a mini spec. So build a music genre detail page for down tempo. So that's the music genre that we want to use with the following sections. I want to have a hero image. I want to have a large placeholder image at 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 chronological list of landmark albums grouped by year for each album. I want to have artwork and name, an 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. 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 whether it's reforged 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 this multi step mode that 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, is actually a pretty good output. And so I'll actually just jump to 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 very small amount of information that we got a pretty nice output. It took a lot of steps for us. It generated an overview of the down tempo 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 pretty much anything that you want to ask questions about it can pull in information. Even though we're using the model for AI prototyping, it's essentially doing copywriting for us as well. And then we've got our list of albums organized by year and it's working pretty well. But there's also some things that kind of break the suspension of disbelief. I think the biggest one is probably 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 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 contexts 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.
- [08:52]
B
This episode is brought to you by Granola. If you're in back to back 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 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 their notes directly in Slack with my colleagues or even get Granola to share their 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 Peter and use the code Peter to sign up and get three months free. That's Granola AI Peter. Now back to our episode. So what are the different levels of context that are available?
- [09:42]
A
Yes. So I think the next level is. This is functional context. The next level that is really important is Visual context. 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 if you're building a house, you would never work with an architect that doesn't know how to draw blueprints. 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. 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. 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 very quickly in Figma, just taking 20 minutes, done a wireframe and sort of outlined what I want this interface to look like. It's actually surprising with just words how close to the wireframe the prototyping tool was able to get. But there's a couple of things that I don't love about it. I'm not sure about this header. It feels not quite as tight as we would like. It doesn't work great at all levels of responsiveness. So if I go down to mobile width, a lot of space is being taken up by the album cover and so we don't have as much space to work with for the descriptions. Whereas here in the design, I've specifically solved for that and said actually 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. So we've made some very specific design decisions here that we want to make sure are incorporated. We can actually just provide that as a. Here's actually we finished the generation here also did a really nice job, but we can just provide the wireframe and nothing else 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 tempo 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. Now we have essentially a 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 interface and user experience here. This is two different versions of context. In this case we start with text based 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 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.
- [13:29]
B
Yeah, let's take a look at that next. Yeah, that sounds good.
- [13:32]
A
Yeah, that sounds good. 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 separately 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. So here I have a thread that I've already created with Claude. It says, I'm interested in the history of down tempo music and I'd like to prototype a feature to browse music by history. Generate a JSON file. So JSON is a data centric format that any prototyping tool or rib coding tool will understand. Just like today we're using Markdown to do a lot of prompting for 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 of the genre, a 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 one to two sentence description, and a list of tags associated with that. So we've asked Claude to do quite a lot of work. 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. We've got a description, we've got who are the seminal artists, 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. 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 Claude code. And that took about an hour. But it was good because I was able to create something where I could get album covers from free services rather than having to have a Spotify API account.
- [16:17]
B
Okay.
- [16:17]
A
And so I ask it to do that. It uses the MCP server, goes through for every single album, identifies the URL, has the COVID URL, and then in this case, it provides me both the COVID it provides me the URL for every single album. So we've got here, if I were to go in and look at this particular image, I'll see the album cover for this particular album.
- [16:45]
B
So you basically like in cloud code, you're like, hey, find me some free sources of album covers and I found the user or something.
- [16:53]
A
Yeah, yeah, exactly. And in this case, we're using the album cover MCP server, so it can go out, it can make an ABI call and say, for this artist, Morchiba, for this album, deep dive, give me the URL album cover, and then you can add that to your data set. You can also do that for unsplash, for example. So if you want 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 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 very simply, just build a music genre detail page for DAM Tempo 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, I haven't said that I want a year by 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 because JSON files are the 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 the essential albums in the genre. We have the 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 2x2 grid. I can search, I can determine the sort, I can just filter down to particular tags, like only those that are related to hip hop, or only those that have sort of more of a cinematic feel. And so in this case, because we've given it the underlying data, it's actually said, okay, based on this data, here's what the UX should look like 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.
- [18:57]
B
The album color makes a big difference.
- [18:59]
A
Yeah, 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 part of the way there, but it still feels like. It kind of feels like AI slot. 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. I specifically designed the UX this way, but 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. But it's not quite what I had imagined. I actually like some of the things here better. 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. And so here we have a full stack prompt that focuses on functional context, visual context, and data context. 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. It says design the page based on the attached wireframe. I've attached the wireframe, use these colors and then populate the page with real down tempo content using the following data. I added a couple of things to make sure that it's pulling the album covers from the URL data. And then I've asked it to save the data as a separate file 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. Claude and now we have this really nice, very realistic looking interface. It looks a lot like the wireframe that I wanted. I was able to build that wireframe quickly in figma. You can also use a hand drawn sketch, or you can use balsamiq, whatever you want. The LLMs do a remarkably good job of interpreting those. We've got realistic album data, album covers, tags. And so now this is something that it feels polished, doesn't feel like AI slap. We can put it in front of users and see whether or not this is the sort of experience that they would want. And we can iterate on it from here. Right. If we want to say, make the album covers larger, we can do that. And one of the things that 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, it'll make them bigger, but it will also make sure that it's pulling in all of the image data and do a really nice job of responding to our requests. And so when you start in this way, it creates a prototype that is a lot more iterable than if you're letting the AI kind of figure out all of the details. In that case you might get an underlying structure that doesn't make sense.
- [22:19]
B
It's kind of funny to think about it because, you know, we've both been in product for a while and in some ways the waterfall process is kind of dead because like, you know, it's so much easier to generate these prototypes. But I don't think it's actually dead, it's just kind of accelerated because like we just walk through is actually just writing the spec, creating the wireframes and even think about a data structure before you get this thing to actually code.
- [22:41]
A
Right.
- [22:42]
B
So it's not just like a two week wireframe, two week wireframe process. Now it's like a ten minute waterfall process, but still have to do it. Yeah.
- [22:51]
A
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 and then you do engineering and kind of. And then you launch and things follow this linear process. We move 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 has a specialty, but people are riffing off of each other and there's no one that's necessarily leading the lead might change, you know, from. 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 riffing 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.
- [23:42]
B
Yeah, I think jazz band sounds a lot more fun than an assembly line to work for.
- [23:46]
A
Exactly. For sure. 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 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 tempo, they may or may not engage with this in the way that we want them to 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 to save a separate file called Data JSON. And here's where we have all of our data. 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, 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 seminal 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 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. 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 also generates better structured prototypes that are more flexible and robust. Because this idea of data context, visual context, usability, functional context, it's pretty similar to how software is built. Software, you have the front end, you have the underlying data structure, you have the services. And so when you give it this style of 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.
- [26:19]
B
Yeah, dude, I've gone so lazy. I just gave the AI vague requests and I thought what you were going to do with the JSON was paste it into the AI chat window and make it update. But the fact that you have a separate file for the data actually makes just ways to just copy and paste the stuff directly. It's way faster and way easier.
- [26:39]
A
So I try to keep my requests in the chat really clean and then I use other tools to prepare the data as I need it. Or sometimes I edit the code directly or just replace the code directly.
- [26:51]
B
Awesome. Let me dive a little bit deeper into one area. I think, like you said, what makes prototypes a lot more engaging is the visuals and the art, right? Is that your typical process? Because I know there is free stuff like unsplash and maybe use nanobana or something to generate some images, but the fact that you went over to cloud code to build an MCP server is pretty unique, I think. How do you do that? Do you just kind of set up a cloud code project? Be like, hey, like for example, let's say we were trying to build the same for movies instead of albums. They just like, hey, hey, Clocko, 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.
- [27:35]
A
Yeah, I would check and see if there's an MCP server first. There probably is a movie cover MCP server. 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, 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 to have an API key. And Deezer provides a lot of this album art for free. And so it just built the server based on that. 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 claude. And now I have it. I built that a few months ago and I use it whenever I do this demo or if I have a similar need. I also have one for locations for a travel oriented prototype. So for the Eiffel Tower in Paris or those sorts of things. And so I think the combination of using Claude, potentially using Claude skills or MCP servers gives you a really nice palette of different capabilities with which to create data sets that feel authentic.
- [28:40]
B
And the MCP server, after you made it, just deployed to GitHub or something and then you just added it to this thing and then it works.
- [28:48]
A
Yeah, you can do a local MCP server, so you just need to edit the local settings for claude. So it's just code that's sitting on my computer. I haven't had to deploy it anywhere. Got it.
- [29:00]
B
Okay, so let me ask you some about how it takes. I was talking to Jeff, who is Ramp's cpo. So I was asking him to show me his prototyping process too, and he said his PMs don't prototype. They just like, did you just build and submit PRs? Because the prototyping phase is almost like an interim step. If this thing is so easy, why don't I just let them actually submit real code? Do you have any thoughts about that?
- [29:21]
A
I do. You use another analogy. I think it's like the difference between sketching and painting and oil painting. If you know what you want and you're ready to commit to that and you're ready to 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 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 how your system works today, to the data that your system has today. 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 product folks and for designers who want to explore the solution space before committing to a direction and do that unencumbered by all of the details that are required for production Code.
- [30:22]
B
Okay, so my second question is a lot of designers still use Figma and some of these other tools.
- [30:27]
A
Right.
- [30:29]
B
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 one solution. But I almost feel like these days it's faster to explore using code because I can just prompt the same to be like, hey, make a two by two grid or something. Then it has another variation. Do you think these design tools are kind of like fading importance and people are just going to be like doing this stuff in code?
- [30:58]
A
Yeah. And I know it's really topical. I don't think so. I think that there are two different ways to think. There's a text based way to think and there's a visual way to think. 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 without blueprints. You shouldn't be building 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 the 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 particular experience in mind versus just you could draw something on a piece of paper and take a photo of it. You can use balsamiq, 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 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 be. You don't have to use all three types of context all the time. 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 conclusions. Like we want to have a two by two grid and we want to have 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, these different ways of providing context to the AI so that you can have a much shorter path from what you're imagining to what is actually in front of you from a prototype standpoint or from a production feature standpoint.
- [32:55]
B
Yeah, hopefully. I think Figma's already working on this where 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 like you said, it's kind of like a jazz band. You're mixing and matching different tools. Just explore that idea.
- [33:09]
A
Absolutely. And I think that kind of round trip Figma's getting better. It's not quite there yet. Cursor just added the ability to do some visual manipulation within the tool, which is really good. V0 has some of that as well. And so yeah, I think it's pretty exciting that 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, execution side, the craft around, what do I want the copy to say, what do I want the layout to be, what font do I want to use, what spacing that I want? Do I want to use all of that stuff that's really taste based? Is it going to become more important and that's going to set apart a product that feels like really dialed in versus a product that feels like AI slot?
- [33:59]
B
Awesome. I think. Last question. So you know, you and I grew up in PM where like you know everyone. Like I remember working at Microsoft and people were writing like 17 page PRDs.
- [34:09]
A
Yeah, I was there too.
- [34:12]
B
Yeah. And part of me is so glad that phase is hopefully over at most companies. But I do think the exercise of writing a prd, there's stuff that is not covered on a prototype. Like for example, who are you building for, what problem are you solving, what kind of goals you're trying to achieve. That kind of stuff I think should probably still come before this or maybe like maybe the PRD still exists, but maybe even after doing this you still write a prd, but it just doesn't have all the details about the user stories and all that crap. It just focus on what is the problem, what is the milestones.
- [34:43]
A
I think we're used to working in sort of this strict linear fashion of the PRD comes first, then we do the wireframes, then we do the 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 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 sometimes the PRD will come before the prototype, sometimes the PRD will come 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 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 onto the right thing 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 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 path forward. And I think that that process is really organic. 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 and create value for the company.
- [36:33]
B
Yeah. And I do think having these prototypes, because it used to be like people follow this waterfall process for like three months and then they have a product and then they launch and the customer is like, I actually don't want this shit.
- [36:45]
A
Yeah, exactly.
- [36:47]
B
But now with the prototype, like even without like any write ups, 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 visceral than like a document. Like you don't really know what the hell a document is talking about. But like a prototype, like 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.
- [37:09]
A
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 centric 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? Are you creating a lot more stuff that you end up never shifting? Because you're finding out that wasn't the right thing early and you're finding out what the right thing actually is.
- [37:52]
B
Yeah, as long as the stuff you're creating is not a 17 page doc.
- [37:55]
A
Yes, yes, yes. 100%.
- [37:58]
B
Cool. Well, Ravi, thanks so much, man. Where can people find you and your upcoming course?
- [38:03]
A
Yeah, so I've got a course upcoming on AI prototyping with Reforge. It's going to be completely free. We've got our first cohort starting next week actually, and then we'll have another cohort in the spring. 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 and then you can find me online on Substack. So I have Substack newsletter called Ravi on Product. I post once or twice, twice a month, so would love to see you there. You can also connect with me on LinkedIn.
- [38:35]
B
Awesome. I didn't realize your course is free. I'll definitely take it and try it myself.
- [38:39]
A
Definitely.
- [38:39]
B
Yeah.
- [38:40]
A
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.
- [38:46]
B
Cool. All right, Rory, thanks so much, man.
- [38:48]
A
Yeah, it's great to see you.