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

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

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

is Ravi. Uh Ravi was previously CPO of Tinder, but now he is a product adviser and full-time vibe coder.

I do do a lot of vive coding. Yes,

you do, right? Yeah. And I think I think Robbie, you've done more thinking on AI prototyping than anyone else that I know. So yeah, really excited to have

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 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 the move to context engineering I think sort of 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

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,

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 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 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 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 a really good prototype is a good decision-making tool. And so you go into

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

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

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 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

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 do you want to just uh get 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

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

little abstract. I'll show what that means. Um, but here we have uh Reforge

means. Um, but here we have uh Reforge Build uh which is a great prototyping tool. It's aimed specifically at teams

tool. It's aimed specifically at teams that are building prototypes of existing products. So where they have um context

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

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

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

down tempmpo. So that's the music genre that we want to use with the following sections. I want to have a hero image. I

sections. I want to have a hero image. I

want to have a large placeholder image up top. I want to have a genre header.

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

bold title. I want to have some tags for artists that are really important for this genre. I want to have a timeline of

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

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.

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

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

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

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

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

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

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

right? if they just said to you, "Here's a memo. Here's what your house is going

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

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

two-dimensional experiences. Um, and software is a visual two-dimensional experience. And so you need to be able

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

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

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

cover. Um, and so we don't have as much space to work with um for the descriptions. Whereas here in 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 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

incorporated. And so we can actually just provide that as a um here's actually you know we finished the 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 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

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

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

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

dummy data. And so the next type of context to 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 let's take a look at that next. Yeah, that that sounds good.

next. Yeah, that that sounds good.

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

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

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

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

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 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

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

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

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 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 find me some free sources of album covers and then I found the 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

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

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

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

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. I haven't

said that I want 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

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

on this. And so now we have three completely different ways of of building our prototype.

The the album color makes a big difference. Yeah. four.

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

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

covers here. We're very specific about the visuals. I like the UX. you know, I

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

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

data. Um, but it's not quite what I had imagined. I actually like some of the

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

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

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

evolution feature. We've got all of the functional requirements that we've talked about. Says, design the page

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

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

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

Figma. You can also use a handdrawn sketch or you can use balsamic, whatever you want. the LM do a remarkably good

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

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 would want. Um and we can iterate on it from

want. Um and we can iterate on it from here, right? If we want to say, you

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

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 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

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 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 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 and then you do 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

leading. The lead might change um 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

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

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.

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

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

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

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

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

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

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 I've gone so lazy.

I 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

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 let me dive a little bit deeper into one area. So I think yeah I I think like you said what makes prototypes a lot more engaging is the visuals and like the the art right. So

like and 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 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 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

hot takes. I was talking to Jeff who is RAMP's CPL. So, I was asking him to show

RAMP's CPL. So, I was asking him to show me his prototyping process too and and he said his PMs don't prototype. They

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

right? Like 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 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

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 like a lot of designers still use Figma and some of these other tools, right? And um

and 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 so yeah. Do 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

Yeah. Um and I know it's a it's really topical. I don't think so. I think that

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. 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 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 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

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

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

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 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 So

it's like 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

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? What do I want the layout to be? What font do I want to

use? What spacing that I want do I want

use? What spacing that I want do I want to use? All of that stuff that's really

to use? 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 a product that feels like AI

slop. Awesome. I think last question.

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 I was there too.

Yeah. And and and like part of me is so glad that phase is hopefully over at most companies. But I think I I do think

most companies. But I think I 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

prototype. Like for example, like who are you building for? What problem are you solving? What what kind of goals are

you solving? What 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 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

that crap. Like it just focus on like what is the problem? What is the milestones? I think we're used to

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, 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 want only want

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

relationship. So, you know, 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

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

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 that process is really organic. You know, the steps are

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 and create value for the company.

Yeah. And I 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 and then they launch it and the people and the customer is like I actually don't want this like

Yeah. Exactly.

Yeah. Exactly.

But but now with the prototype, you know, like even without like any writeups, you can just show the stuff to customers. It's it's pretty cheap and

customers. It's 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 but like a prototype like I I I can tell you like I actually want this or I don't want this, right? This is way faster to get

this, right? This is way faster to get to an answer. I 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. 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

the spring. Um we're also going to do a video series. So that will be available

video series. So that will be available soon. So you can find that course at

soon. So you can find that course at Reforge. Just search for Reforge AI

Reforge. Just search for Reforge AI prototyping. Um and then you can find me

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 twice a

Product. I post uh once or twice twice a month. So would love to see you there.

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

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

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

man. Yeah, it was great to see