What we talked about
Saumya Bhatnagar is a Forbes 30 Under 30 alum, Co-founder and CPO of involve.ai, and one of the Top 50 Most Powerful Women in Tech. She has built her career at the intersection of product, engineering, and AI:helping companies scale smarter and predict customer needs through data-driven insights. Saumya is also a Stevie Gold Entrepreneur of the Year award winner and a two-time honoree among the Top 50 Women CPOs in the U.S.
Show notes
Saumya Bhatnagar argues that product managers who can’t validate engineering estimates, or who can’t reason about why a RAG implementation is preferable to a larger context window, are already falling behind. Her position: vibe coding closes the gap between product and engineering, but it also raises the bar for product thinking.
What we covered
- The product-engineering relationship has fundamentally shifted in the last six months. What used to be two teams with “scheduled interactions” and a handoff document is now one continuous feedback loop, product managers can drop a Git repo into a codex tool and independently assess feasibility, effort, and timelines, which ends the inbuilt mistrust between the two functions.
- Saumya identified a concrete example of what siloed dashboards cost teams: her growth team spent two quarters re-optimizing a feature’s UX to fix drop-off, only to discover the real problem was an API call taking too long, information that lived entirely on the engineering side. Combining those data streams changes what decisions are even visible.
- Her PRD template required product owners to answer three questions before engineering ever saw a ticket: why is this the most important problem right now, which of at least three solutions is best and why, and, in a section she called the premortem, if this feature fails after launch, what will have caused it. That last piece gave QA a checklist before a single line of code was written.
- On vibe coding, Saumya’s view is nuanced: product owners can now build working prototypes in Lovable to test with users before engineering touches the work, which removes one of the biggest sources of wasted cycles. But she is direct that vibe-coded output is not production-ready, she found a function running at O(n²) complexity that no AI tool flagged, and product managers who treat it as a finished product are cutting corners that will generate technical debt.
- Designers in this new model no longer start from a blank page. Product owners arrive with a first-pass Lovable mockup; the designer’s job becomes optimization, edge-case identification, and UX critique, “starting at level five instead of level zero,” as Saumya put it.
- Her single piece of advice for aspiring product managers: build the muscle of first-principles thinking by practicing on products you don’t work on. She specifically suggested asking yourself, “If I were the growth PM for Cursor tomorrow, what would I do?”, and using AI to stress-test the answer rather than to generate it.
About Saumya
Saumya Bhatnagar is the co-founder and CPO of Involve AI, a company that uses data-driven insights to help businesses predict and act on customer needs. She is a Forbes 30 Under 30 alum and a two-time honoree among the Top 50 Women CPOs in the US.
- LinkedIn: https://www.linkedin.com/in/saumya-bhatnagar
- Website: https://www.jeeva.ai
Episode 38 of the PreVetted Podcast.
Full transcript
Federico Ramallo (00:00) Welcome back to the Prevetted Podcast where we spotlight extraordinary people and remarkable talent reshaping our world. Our guest today is Saumya Bhatnagar. She’s a Forbes 30 under 30 alum, co-founder and CPO of Involve AI, and one of the top 50 most powerful women in tech. Saumya has built her career at the intersection of product, engineering, and AI.
helping companies scale smarter and predict customer needs with data-driven insights. She’s also a Stevie Gold Entrepreneur of the Year award winner and a multi-time honoree among the top 50 women CPOs in the US. Her journey from building her first company straight out of a coding class in India to leading cross-functional AI-driven product teams in the US is a masterclass in innovation, resilience, and…
leadership. Welcome Saumya to the show.
Saumya (01:00) Thank you for having me. I appreciate it.
Federico Ramallo (01:03) Yes, I’m honored to have you here.
So tell us about the relationship between product and engineered, how that relationship evolved.
Saumya (01:12) Ugh.
I think in the last six months, think product and engineering has completely switched the way we used to function to what it is right now. Earlier, product and engineering used to be two separate organizations with two separate work structures and two separate ways of working. And there was a very tiny intersection which we would all recognize as the handoff.
where product would think up of something in the vacuum not involving engineering maybe at some moments involving engineering for like feasibility but most of the time not.
And then finally at the end of a quarter, kind of just giving them a roadmap and a product requirement document. And then it kind of went away into the vacuum till the end of the next quarter to figure out, okay, what got built? So there was interaction every now and then, but I think it was very scheduled and ⁓ with a very limited amount of agility, just because everybody had to focus on their functions.
there has been a massive switch where the gap of technical feasibility analysis and understanding not just what we’re going to build but how we’re going to build it has come into products per view thanks to AI. Like you can literally now there’s codecs available where you can just literally stick your Git repositories and product has a better idea of how things are built, what is feasible to build, how much time would
to take, what effort it is to build something. So we have a lot more knowledge upfront to have actually very informed negotiations with engineering on things like timelines, on things like how something should be built, how quickly we can turn it around. And similarly, I think engineering, because of that, is understanding business strategy a little better. I think it’s much more important for engineering to realize
that feature A is more important than feature B because feature A is going to get you much more revenue or customer engagement or whatever that metric is. So I feel the gap is closing between the both of them. Now thanks to things like lovable and Cursor, product can literally vibe code, you know, something to test. We don’t need engineering resources anymore to build testable features anymore. You can vibe code something, test it with users, figure
out if it’s going to work or not, iterate on it, and then give a final refined version to engineering and they already have a lot of the code to start off on.
So I feel there is so much co-mingling that is happening that we’re not product and engineering anymore. We are product development and engineering, like one big team that can function together without this, you know, scheduled interactions. Now we’re just working together in an agile manner.
Federico Ramallo (04:13) Right, right. So before product teams and engineering teams used to be think about to independent teams with a very limited subset of communication, right? Yeah, and now with Vive coding and the evolution of engineering, now we can see them as a single team with lots and lots of interactions and…
and continuous feedback between each other.
Saumya (04:39) Yeah, continuous feedback is like spot on. That’s exactly what is happening.
Federico Ramallo (04:44) Right.
What do you think is the biggest misconception product leaders have about engineering teams today?
Saumya (04:49) Good question. I think the biggest misconception is a lot of the times a feature looks very easy to do.
and they’re like this should be done really quickly and it really isn’t because product does not have a deep understanding of how the actual product is built. They understand the features but they don’t understand the, you know, how, like how the pipes actually are set up.
So I think that is a very big misconception that product has about engineering. The other thing is I feel like in the past, product and engineering have an inbuilt mistrust with respect to each other. Like we always think that engineering is out to reduce things on the product roadmap. And engineering is always trying to think that product is trying to like add more than they can do. So I feel like there was a very inherent mistrust and a very easy scapegoat. So if something didn’t work,
Product could very easily blame engineering and engineering could very easily blame product and There was this inherent mistrust that used to happen So I feel like now because everyone’s on the same page that is kind of Shifting where more trust can be built everyone’s on the same page and everyone in the grand scheme of things at least knows the same amount Like it’s not that
I can validate if you’re an engineer and I’m a product manager, if you’re telling me this is going to take me four weeks, I can validate it on my own to figure out if it is actually four weeks or not. So in a way, it kind of ends up building trust between product and engineering as well.
Federico Ramallo (06:30) Right. I used to think that the intersection between product and engineering is application behavior, right? That product would say, OK, based on what we talk with users, we understand that this is the behavior that needs to be done, right? And then on the engineering side is, I don’t care about the user.
Saumya (06:39) Mm-hmm.
Bye. ⁓
Federico Ramallo (06:55) tell me what needs to be done and I will build it. But what you’re describing is a complete change on that ⁓ old mindset. ⁓ So now product is more involved on how it actually works.
Saumya (07:03) Bye. Bye.
Yeah.
And I think the beauty of that is because if you think about it, even though both engineering and product are trained to be informed teams, the dashboards they’re looking at are completely different. So product would be looking at user behavior, retention cohorts, where is drop off happening, where are rage clicks happening, what are the UX gaps? That’s what we look at in terms of measuring. And what engineering looks at
is availability, uptime, concurrency requests, how is the database performing, is the query optimized or not. So they’re looking at very different data points than product is. And there is no interconnectedness or no way to explain the importance of a metric that is important to engineering to product or the other way around. So now, with AI, can put together
all those data points and it creates a much more rich picture for you to figure out actually what is happening because a lot of the times like I’ll give you an example we kept seeing drop-off on one feature continuous drop-off
And me and my growth team were like just, it was an important feature on our happy path journey, which is like, we want the user to follow these steps. So we’re nudging this user towards this critical step and we would get drop off like within, I want to say two minutes. And we would like just keep racking ahead. So we updated the UX, we changed things around. We had no idea what’s happening. And then,
Somehow I ended up talking to our VP of Engineering who was looking at a different data set and said, the API call for this is taking way too long. And that turned out to be the same feature that we spent two quarters trying to optimize and re-optimize.
But we didn’t realize that it’s an API call problem. So now if you put all of this data together, it’ll give you a much richer picture of the true customer journey. Because now UX is not just about how the feature looks. It’s how fast the feature behaves. Does it give the right outputs to you or not? Are the evals in the world of AI, are the evals and the benchmarks actually performing how we’re expecting it to?
Is their model drift or not? Is their data drift or not? And product earlier was not given this information for us to make informed decisions. So now when you can put this together with AI, both teams get very, very enhanced information to make even better judgment calls on.
Federico Ramallo (09:54) Right. I think that engineering focuses more on efficiency. How fast it works, response time, those types of things. then on the product side, it’s about effectiveness. Is the feature adding value to the users? Is this a good experience for the users?
So I can see how integrating both teams into a single metric dashboard and helping them see the same things would add value for the whole product. I’ve been teaching the team that I work with on the engineering side that
Saumya (10:23) It tells a better story for sure.
Federico Ramallo (10:36) we need to focus on understanding what is the value for the user, right? I mean, we’re not going to do the product owner job necessarily, having an understanding of the whys. Why are we building this feature, right? And what is the value for the user, right? And ask more questions to the product owner to understand the whys, because that for the engineering side means that we have a
Saumya (10:40) Bye.
Federico Ramallo (11:04) a much higher purpose, right? Because now we understand that we’re changing the life of the users, right? One way or another, right? ⁓ And it is also that change of mindset of, if I’m building a test, am I testing based on the user expectations, right? What is the behavior that the user would expect, right? And that…
Saumya (11:07) way.
Right. Correct.
Right.
Federico Ramallo (11:28) make because sometimes we get the feature requirement, but we don’t understand the why. And the product owner doesn’t tell us. And we don’t ask on the engineering side. And that disconnect makes that the feature that we build eventually doesn’t make sense because we didn’t understand the why. And that helped.
Saumya (11:43) Hmm.
Bye.
correct.
Federico Ramallo (11:53) helped a lot, right? We haven’t gone into this transformation that you’re talking about that is, you know, on these teams having the product and the engineering working together as a single team, although I’ve been working towards getting them working together, right? And the way that I’ve done it is the bridge for us was the designer. Having a designer working with the product owners, right? Because then
Saumya (12:10) Bye.
Mm-hmm.
Federico Ramallo (12:19) the designer would not only build the mockups, which would provide more clear requirements for the software engineering team, but also would allow us to answer a lot of the questions, right? And before it is hand over to the software engineering team, the designer would work back and forth with the product owner to provide the clarity that the product owner might not have, right?
Saumya (12:30) with.
Federico Ramallo (12:45) asking the questions, asking the whys and working back and forth. So that way we can have this independence of, when we’re building something, we don’t need to go back to the product owner every five minutes to validate something because we have all the clear requirements and we can just focus on building. And then when we sit down in order to understand a new feature and…
why it’s going to be built in a specific way, then ⁓ that comes back in a much more mature way because now the product owner hasn’t been alone designing how the feature is going to be. It had somebody a little more technical to work with.
Saumya (13:16) Yep.
Okay.
We always used to include in our product requirement document, we used to include what is the core problem that the user has and why are we solving this? Why is this problem the most important problem to solve instead of the others? So that forced the product owner also to really think about it. That why is this problem the, I used to call it why is this the biggest fire? So I had it in my template.
problem
out of all the fires because at any given point there are like eight fires that you’re trying to like take out and you know the user has a login issue and there’s this other issue and that other issue it’s out of those ten problems that exist why are we picking this one and they had to write that in their PRD and then what other solutions then there was like I always used to force the product team to think about
The first solution, I would say if you have the first solution out to a problem, it’s always the wrong one. The first answer to any question is the wrong one. You have to think about three or more solutions to the same problem and pick the best one and actually do a pro-con analysis of why that is the best solution. So we would actually put our three solutions like in a very short form manner because I know engineering teams hate reading a lot.
It used to be like in a really like one-liner that we picked this solution, this solution, this solution, and this is the best one because of these reasons. And then they would start going like and doing like a deep dive into like the issues, sorry into the solution of the PRD. And then in the end, I used to force them to write something called as a premortem. And a premortem is the opposite of a post-mortem. So we would say if this feature
this feature fails, what would be the reason that it failed? So we would do it before we release the feature. This is like the time we’re giving the PRD. So it’s not just thought of, but the team had to think about if this feature fails, why would it happen? And we would list out all the reasons that we thought it could fail. So we would say, oh, it’s because this is going to be like a high traffic feature, so we broke concurrency, or the UX was
very
complex, so we already came up with these so that when at the time we were building tests, you’re looking for these. So the QA team knew what to look for beforehand when the feature was delivered. So we had like this structure that we kind of tried to force at least product owners to write because in my opinion, it’s product owners who are responsible for everyone’s vision of that particular module or feature.
And if there, if engineers are confused, it is the product owner’s fault. It’s no one else’s.
Federico Ramallo (16:27) Right. Yeah, because the clarity of the behavior should come from the product owners. Yes.
Saumya (16:32) right. Correct.
And for that the product owner has to be clear themselves.
And I want to see like, it’s a 50 50, it’s a coin toss because usually a lot of the times when we’re building like this flurry of features, if you ask a product owner why this feature and why not that feature, a lot of the times I don’t think they’ll be able to give a valid response. So this forces a product owner to think that is it really that important to build it? Like you’re, you’re relying on ruthless prioritization. That’s the only way we can build features and
products of consequence. That you know what is not important, that is more important to know. That this I will not build as opposed to this I will build.
Federico Ramallo (17:17) Yeah, we used to build these product requirements. Well, the product owners would build them. It was a very long document with a lot of text that would basically, the developers would just skim it, you know, and then they would miss a lot of details and then they kind of, you know, miss the why, right? And sometimes it was not clear for the product owners, as you mentioned, you know, that could be the case as well.
So what we did to change that was we did some of the document, but with the designer, we did build the mockups and the workflow. And a lot of the requirements were on that workflow. So one thing I remember, and it’s a very small thing, but still, always product owners will think on the happy path.
Saumya (17:54) Yeah.
Right.
Federico Ramallo (18:09) what happens if there is a validation error on the form? It took us a while to get to a point where we had in the requirement which are the required fields and why. But once you had that, then, OK, what are the errors? How should we tell the user that this is invalid? And there many ways to do it.
get to a consensus on that, that took us a while. Eventually we kind of had to, we worked to standardize the error messages and the interface. So that kind of helped, but then just getting the text of the error message, right? Was something that the product owner would not think for themselves at first, right? So having the designer would ask that question before it was even presented to the developers, right? So that was a big, know, and it’s a small thing, but
Saumya (18:56) Right.
Federico Ramallo (19:05) represents the right. ⁓ And then from there, we…
Saumya (19:06) It’s a very important UX feature. Yeah. 100%. Yeah.
Federico Ramallo (19:13) we start moving towards more more clear requirements on the mockups that the product requirement document became kind of obsolete. Yeah, secondary. Yeah. It was more of an outline. And then the other thing we did is once they had that document and everything ready, they would present it to all the developers. It was probably a bit inefficient because we had all the team for that. And we didn’t know who’s going
Saumya (19:23) second.
Yeah.
Federico Ramallo (19:42) who was going to take that feature yet. But it was good because if somebody else was building something similar, then on the engineering side, we could say, we can share the behavior, or we’re going to build something similar together. Or we already built something like that. We just need to take it and modify it to make this work. So that was good. And that reduced a lot all the… ⁓
miscommunication issues we had and the engineering team felt more empowered because now they had all the requirements at once. They had time to ask questions, and then they had time to estimate it and build it. now, I mean, the product owners are always available, but still, we didn’t have the dependency.
Saumya (20:16) Bye.
click.
Federico Ramallo (20:32) And man, that was a game changer for us, right?
Saumya (20:36) Yeah, for sure. Yeah. I feel like that has also kind of changed on its head. Thanks to AI where now you don’t, because I know how long it takes to create a Figma design of the whole flow, which includes like if we have to show an error message, that’s like another page and then another page and have to connect all of this with a hotspot. So now with things like Figma AI and lovable and things like that, now a product
owner could create the first version of the mockups.
and then hand it off to the designer without needing a PRD and say, hey, can you make this stylized? Can you tell me what the UX issues are? So the designer is doing the second layer of advanced work as opposed to building something because you most likely you already have a style guide. You already know what buttons are going to look like. You already know what placements of things are going to look like. So the product owner uses that to create a lovable design and then says, here is my vision. And then the designer comes
in secondarily and then starts optimizing it for a good UX experience where they say okay this form is very bad let’s fix this or let’s improve like this journey from this button to this page and they come in secondarily and then you don’t quite need a PRD because then you literally ask lovable saying hey where could the error messages be where other gaps am I missing and the AI validates it for you and
have a complete mock-up with code. So now instead of sending a PRD, you just send that lovable file with, you know, all of the design, all of the code, and the developers have everything that they need without having to think. Like they can see the experience in front of them so they know exactly what it is. And then I, we send like a tiny blurb going like the what, why, how, like the strategy, and then everything else is in front of them. They can actually like play around
with it because it’s a working prototype that you’re sending as opposed to a PRD or a mock-up. So that empowers engineers to in a huge way because they’re testing it out real time to go like ⁓ okay so this is going to pull from there and this is what’s going to happen and it becomes very iterative and much quicker because it’s a working prototype.
Federico Ramallo (23:01) Right, right. I mean, I keep talking about using the word dependency, right? That now there is no dependency between one team and the other. And I think it’s an oxymoron because we’re also talking about a higher integration of the team, right? And I think that both are true because now the product owners can build a prototype validated with the users before it even touch the engineering side, right? With AI now,
the product team can do that. And that’s fascinating, right? ⁓ That doesn’t need to scale, doesn’t need to, you know, it’s just a proof of concept that you can show the users and get feedback very quickly, right? And you can iterate that very quickly, right? And then on the engineering side, we can get that and now, you know, from the mock-ups working with AI tools.
Saumya (23:31) Mm-hmm.
Yeah.
Federico Ramallo (23:54) to build initial mockups, send it to the designer, and then once we have that polished, then send it to the engineering team. But now they have a working prototype, they have mockups with a polished design, depending on what are the needs. But those are possibilities that we couldn’t do that two, three years ago.
Saumya (24:20) Yeah.
Absolutely not. Like I would say not even six months ago. We couldn’t do that. So it’s changed so much where you’re right. It’s both. There is independence and dependence at the same time, which is a very weird way to kind of put it, but that’s what’s happening. You are independent where like, because I know how annoying it is for an engineer to like look through a PRD and start coding and then get stuck and say, okay, this use case is not covered and I
to build it right now. So then you’re going to find someone to figure out what to do and then you spend two hours trying to talk to that person and trying to communicate the gaps. So yeah, it’s very annoying because it takes away time of truly coding. So how can you give the developer back that time to code with just headphones on and nobody bothering them and they have clarity on what they’re building, but at the same time, they’re very integrated in the product building process.
and that is the reason why they have independence to build. So it’s both.
Federico Ramallo (25:24) Yes,
yes. usually when I talk about this, think about, remember that episode of Friends where they had to get a couch into the
Saumya (25:35) Yeah,
they’re pivoting.
Federico Ramallo (25:38) Yeah, yeah, yeah.
And everybody was like, a little bit to the right, a little bit to the left, right? I feel it’s like that, you know, like we’re holding a couch, you know, on the engineering side. Now tell me what you want it. A little bit to the right, a little bit to the left. And there is an effort on keeping the couch up, right? There is an effort, you know, while we’re building stuff, there is an effort, a sustained effort, right? So if we now have to stop because we have a very particular question that it’s not clear when you just…
Saumya (25:42) Okay.
Right.
Federico Ramallo (26:08) read the document at the beginning then that kind of you know we get stuck right and it is frustrating on both sides right because
Saumya (26:10) night.
Yeah.
Agreed, because
I know how it’s like a double-edged sword on products and do because I remember like what you’re talking about. I’ve gone through this multiple times and tried to optimize this process pre AI and pre lovable and Cursor and all of the fun stuff. But you know, what I realized is it is impossible for one person to think about every scenario. There will be something that will be missing and the more
thorough you try to be, the longer that document becomes and the harder it gets to read and the harder it gets to kind of like truly like piece together. So it was actually like there was a point beyond which thoroughness actually reduced speed. So we always had like these what we started doing and that time was we used to set up daily office hours where we’re like if you don’t want to come don’t come that’s fine but all product owners were
would
be on that call for one hour. We would keep doing our work if nobody showed up. But if somebody needs to ask a question, they could just jump on that call. And there was a point when we were really, really agile. We used to have it twice a day, like morning and evening, so that whenever the developer works, we can work around their time. So anybody who had a question would hop on that call. They would go through the PRD going like, what the hell is this? How are we supposed to think about this? And then we would edit the PRD.
on fly. Like we would all be there, our product team would discuss it with the engineer, talk about feasibility, update it, say okay done and kind of go. So we were trying, so the goal became not to be extremely thorough with the PRD but just have enough information but then give, the goal became to unblock the developer as quickly as possible. So that kind of became the trade off for us because I remember a
PRD that I built that was like eight pages long. No one’s going to read eight pages. Like even I didn’t go back and read my own PRD because it was so long. So, but yes, I was very thorough, but after a point, you know, it effectiveness drops of the same PRD. So the length and the amount of information it captures can only be so much.
Federico Ramallo (28:33) Right, right. We tried at one point doing, the tickets like contracts. If it is on the ticket, then you have to build it. If it’s not, then you don’t, right? As a way to kind of like, from top to bottom, trying to give more detailed requirements. But that…
eventually backfire because as you said, it’s impossible to think of all the possible scenarios. And then when we’re building it, we realize one scenario and then we can say, well, it was not on the ticket. So then I don’t need to do it. So then the developers will become very explicit. And there are many jokes around that thing.
Saumya (29:03) collect.
Goodbye.
Right.
Federico Ramallo (29:21) And the thing is, that crumbled the amount of value that product and engineering would be able to deliver to the users, right?
Saumya (29:28) Right.
Yeah.
But then that becomes the problem of you’re trying to minimize scope creep because you said develop, because we started with an original PRD and you said it’s going to take four weeks. Now developers would come around to us and say, now you added this brand new scenario. This is going to take me another three days. So I can’t turn it around in four weeks. Now what? So it’s always like, what I kept realizing is the…
PRDs are, at least now with all of this new technology, is a very outdated method of information transfer. Because one human can’t think of everything, and one engineer can’t build everything and then stop, because they also want to provide value to the user. So at the end of the day, it’s not about optimization of PRD. It is like, can we do something that
scraps a PRD entirely because it’s just a hard way to… and AI is the only way to solve that, like in my opinion.
Federico Ramallo (30:38) Yeah, sorry. Yes, I think that AI now gives product owners much more tools. I think we were discussing this before the episode about how AI is empowering non-technical users, non-technical people to build technical stuff.
Saumya (30:51) Yeah.
right yeah you still can do it like i feel like
Federico Ramallo (30:57) And that’s a game changer, yeah.
Saumya (31:03) Like again, this is my very, very, what is that called? Unpopular opinion. But I feel it’s going to be harder and harder for non-technical product managers to keep up in the future. You need to be technical because just because it’s like, just because somebody gives me a rocket doesn’t mean I can fly it. You know, I need to know enough about it, like just enough about it, like where the fuel is and
Now, how do you press start? And what if I’m up in space and something blows up? And what do I do? You at least need to have working knowledge. You need to have enough information to be dangerous. You don’t need to be an expert at it. But you need to have enough information. And that’s why I keep thinking product managers need to learn how to code. Because vibe coding hallucinates 80 % of the time. You think you’ve built something, and you really haven’t.
You think the feasibility of something is really simple, but you don’t have context of your business. You think, I’ve seen this again and again, where people go like, oh, we can just prompt open API, and it’s going to give us all of this information. And then what they don’t know is, I’m like, we are pulling from Pinecone. This is like a rag function. We’re going to add context.
engineering that increases the scope considerably. So these small nuances a product manager cannot understand without at least having basic knowledge of how it works.
So yeah, so it’s bridging the gap, but I feel like that doesn’t mean that product managers do not have to be technical. That means they have to be even more technical and you know, AI is helping them get there really quickly. a product manager who’s non-technical can’t just sit there and say, okay, cool. Now vibe coding is there. Everything’s on production. No, vibe coding can’t build production ready code. You have to understand the how, even if you don’t understand the syntax.
but you at least have to understand how things interact with each other and what each thing does for you to truly be able to create something of consequence.
Federico Ramallo (33:16) Right, right. Yeah, the at least right now, know, in August 2025, the, you know, the the AI agents are not able to abstract as humans can on the business logic, the, you know, think, think problem in abstract, you know, when you’re building object or in the programming, you build objects that represent reality, right? It’s an abstraction of reality.
Saumya (33:41) Yeah.
Federico Ramallo (33:42) That’s something that AI cannot do very well yet. It can kind of infer it and eventually give you the behavior that you’re looking for up to a certain point. But then that code is not going to scale. It’s not going to work. You’re not going to be able to not only scale it on usage, but also add more functionality because it’s not designed that way.
Saumya (33:54) Yeah.
Federico Ramallo (34:10) And that’s the limitation that the AI has now.
Saumya (34:10) Big.
And adding to that, it cannot figure out code complexity.
Federico Ramallo (34:18) Right.
Saumya (34:18) like
which is insane to me because it can just functionally and you know syntactically fix things. It can fix a lot of lint errors great but when it comes to code complexity and as your product project becomes bigger and bigger it becomes like it becomes sluggish and it doesn’t like you need to know systems design and AI can’t do it. So you it like I remember like there was like a function that was running at ONQ
complexity and I’m like what is happening and no one knew that this is happening it was a vibe coded you know kind of function I was like someone simplify this please without Cursor or open AI like do it with your own brain like so these things AI can’t do and it’s not ready to scale but at the end of the day that is where people cut corners and that is what I think product managers need to understand they need to understand how
Federico Ramallo (34:54) the
Saumya (35:15) system design works. They need to understand how microservices work. They need to understand, you know, how indexing works and how database works and what context engineering is and why would we use rag in this situation versus just plain prompting. Like these technical decisions can you need to be aware of the why. Like it’s the same way. Engineering needs to be aware of the why of product strategy, but product also has to be aware
of the why behind systems design. It goes both ways.
Federico Ramallo (35:47) Right. And the how. How it’s been built and why.
Saumya (35:49) And that… Yeah.
Exactly.
So that is like, that is the strategy of engineering that here is how we built it. Here is how the services are built. This is how the abstraction layer looks like. This is the database. This is when we will use rag for an AI thing or not. This is where we’ll engineer more context versus not. A lot of the times when you’re in a big data company, you’re using a lot of like synthetic data. This is where we’ll use synthetic data versus not. Like these are critical.
decisions that product needs to be aware of and understand the why behind it. Which is why barrier to entry to learning how to code and how to build these prototypes is reducing for product managers. But at the same time, the need to understand technical know-how is also increasing.
Federico Ramallo (36:41) How much functional and how much technical deep do you think product owners should know?
Saumya (36:47) enough to work with an engineer to make critical decisions.
I feel like, I’ll give you an example. We recently had this issue where we wanted to figure out if we should simply just put a prompt with a huge amount of context for like, we should switch an LLM with a lot of context, or do we improve our indexing on pine cone and embeddings on pine cone and, you know, do a rag kind of.
methodology. That’s why I’m harping on drag because that is like the thing that was top of mind. And it was a very critical decision because a lot of features were built, would be built in the future on top of it. So product needed to be involved and our product manager was involved was non-technical. So they said, ⁓ whatever you see fit. And I was like, no, it’s not an engineering decision. It’s an engineering and product decision because you don’t want to go back to engineering, you know, two weeks later.
to say, by the way, these eight more features are going to be built on top of that. And then engineering is going to come back and say, we’ve run out of context. If you choose to just prompt, you said we’ve run out of the context window. We can’t add more stuff. So it is a decision for right now for you to understand that what does your roadmap look like six months from now? And will this one decision impact your six months down the line roadmap?
So if you’re trying to add more and more stuff to that feature, like if this is it, this is like the prompt and you will not change it for the next six months, great, just run with it. You’re not going to run out of the context window. But if you add four more features, that means four more parts of context, you’re going to run out of that context window, which means you need to have a vector database of some kind. So that is an important decision for product to be involved in for engineering. can take both, both ways are good ways to give
response to the user, but then how does product strategy get affected six months from now when they have to re-engineer the entire feature because you changed your mind. So that is the reason why I’m saying that there has to be some understanding of how things work. Like they don’t need to know how to code it, but they need to know the pros and cons of each.
Federico Ramallo (38:49) Right.
Right, right. Yeah, I think that we should be able to get product owners fairly quickly on the functional side. You don’t need to understand how everything in the car works to drive it. So if we can understand it as black boxes, then we can have a better understanding of how it works and the limitations.
Again, you don’t need to be a specialist on system designs to know that. ⁓ And that gives you a good idea. And then you can split those big boxes into smaller big boxes and understanding how they work together. And then you get deeper and deeper into more, of course, technical knowledge. But at least getting to one, two, or three levels of functional.
Saumya (39:32) Thanks.
quick.
comment.
Federico Ramallo (39:53) understanding, right? ⁓
Saumya (39:53) yet.
I think
that that is a basic thing that I feel I’ve seen a lot of product managers and product people not know. Like they don’t see a feature as a building block for your next quarter’s roadmap. They see it as one thing. And even if the next feature on the next quarter’s roadmap, like if something’s connected, they see it as different. However, engineers see it as all interconnected because they’re like, if you’re building that next quarter, we
need to make sure that we optimize and account for that right now. there’s a difference in the way of thinking because product thinks about the now and this is what we built. And then they’re like, oh, we’ll see what happens for the next feature next quarter. I mean, that’s a fundamental difference in the way product versus engineering think. So that is why I know that my engineering team used to ask for the years roadmap.
Federico Ramallo (40:40) You
Saumya (40:53) And we had like, we at least had an idea, like, of course, we had like, this is subject to change. But like, we would always try to be two to three quarters ahead of engineering, so that engineering has an idea of what’s coming out. And then we even tried to be five quarters ahead where the last two quarters were like just the names of the features we hadn’t thought through anything, but at least an idea of what the next year would look like. Because we started understanding
understanding the importance of system design. So they would basically like look at a ticket like that we had and then look through what is coming up in the next few quarters to see if anything’s connected and do we need to like bring it together in terms of like just the fundamentals of this feature. Especially it was like a net new feature. So we actually tried to give that to the best again nothing’s a hundred percent like the PRD but we tried to do that for engineering because we had a lot of
technical PMs on our end who understood how irritating it is when you throw like a new feature that way which is in your mind a new feature but they’re like dude we could have done this last quarter and build the foundation better.”
Federico Ramallo (41:57) I’m
Right, now we have to refactor and change and yeah
Saumya (42:09) life.
And that is the biggest cause in my opinion of technical debt. Because then you’re hacking around that feature and you’re like monkey patching everything. And then, you know, it becomes like suddenly it becomes like this monolith. But then you have to take one quarter to refactor and then no new features come out because your technical debt is so big that things start moving slower and everything becomes like at a glacial pace. But in a lot of the times, I mean, I’ll be open to admit it.
it I think it’s products fault because they don’t see it that way. So that is why like this additional interaction and this introduction of AI can help reduce future tech debt as well.
Federico Ramallo (42:52) Right, there’s so much you can learn from a… well, what I call working prototype which is basically something static that you can play with, click through ⁓ and then the other part is storytelling because if you can tell the story of… ⁓ we have Maria that does this and this and that or whoever that was a great way to engage the engineering team
Saumya (42:57) Yeah.
Yeah.
Yeah.
Mm-hmm.
Federico Ramallo (43:18) because now they’re in a story, right? And now they are rooting for Maria or whoever the user may be, right? So that was helpful. Yeah, yeah, yeah.
So what do you think would the role for the designer is changing with AI into the product development cycle?
Saumya (43:38) I feel that now I read about this really interesting concept and it’s called the K economy, but I feel like you can apply it everywhere. So they’re like, imagine the letter K. And then if you break down your job, your job is now with AI, not just, I’m a data analyst, I’m a product designer, I’m a product manager. It’s a series of smaller tasks. I do competitive landscape.
I look at the best UX solutions if I’m talking about a designer. I talk to product and communicate like best practices. I talk to engineering and give them like the feature requirements. And then if you look at it, out of it, the top 80%, the one that goes that way in K will be automated by, you know, kind of AI. And the rest of the 20 % will be augmented with AI. So I feel for design,
a lot of this job which is like starting from scratch thinking about something would be in a huge way automated.
So now the designer would start at like, instead of starting at level zero, they’ll be starting at level five, but they’ll be optimizing a lot of other people’s ideas as opposed to having to come up with something, like, which I feel like our designers are truly enjoying. because they anyway, like if you think about it, they would talk to a product owner. The product owner will give them like this data dump that then they had to like figure out somehow and put it into a some form that is acceptable.
then they would do this eight time iteration with product owner where they said no this page should be here and blah blah blah. Now product owner is giving them that to say here this is the baseline that I want and now the designer comes in and really polishes it and makes it better and thinks about best UX practices and thinks about how the user is going to interact think about scenarios that the product owner might have missed.
as opposed to so you’re getting a second set of eyes that is making that design better, thinking about newer scenarios that the product owner might not have thought of. So you have a much more polished product at the end of the day. So I feel instead of the designer starting from ground zero, their job is to improve everyone else’s work because they are the experts at it. So that is kind of how I think the designers role with Switch, whether he’s going to like a lot of the time,
I think in the next year or so the designer will tell the product owner don’t even come to me if you don’t have your first set of mockups Don’t talk to I don’t want you to tell me what it is I want you to show me what you’re thinking and then I will take that and I will iterate and improve on it So I think that is a much better use of a designer’s time rather than continually building a new login page and continually building like you know
Federico Ramallo (46:08) Right.
Saumya (46:28) one mock-up that looks like their dashboard which they’ve already built like 800 times. So it’s a much better use for them to optimize because that extra time can be really like you said like the edge cases that you know somebody didn’t think of the designer can think of the edge cases now as opposed to the happy paths that the product owner has already thought about.
Federico Ramallo (46:50) Right, right, very interesting, yeah.
So if you have to distill building products into a simple mantra, your version of this is how you build software products, what do you think that will be?
Saumya (47:05) I think like the mantra for product to build is to always be learning. I think like this is the age of everything is accessible to you with one question. And the only thing that, you know, people
need to do is have those questions in your head. Be curious and have a learning mindset. I think product for 10 years was kind of stagnated because there was a way of doing things. You could only prioritize based on the Rice framework or the Moscow framework or like these set frameworks. You could only write PRDs this certain way. You could only use JIDA for building PRDs. Like it was so set that I think product managers
just stop learning or improving on their craft, not about the product, but just their internal learnings. But I think now is the time to be continually curious, especially about engineering, especially about the how. It’s not just about the what anymore. So just always be learning something beyond product management because it’s changing.
Federico Ramallo (48:11) Right,
right. Great. And what advice would you give somebody that wants to, somebody new that wants to join, become a product owner?
Saumya (48:22) Yeah.
I think the biggest skill set that I think a good product person can have, and Federico you can attest to that, it is critical thinking. A lot of critical thinking, a lot of first principle thinking and problem solving. Your goal is to figure out and find problems that you’ve never seen before, but you can still break them down, like you said, the big black boxes into tiny black boxes, and then kind of open
one at a time and kind of like figure out the solution to one and move on to the next. But I think a good product owner has extreme level of first principle thinking, extreme level of critical thinking and you know problem solving. So it’s nothing about what you can learn, it’s about what how you think. So you have to keep like honing yourself to be that person who’s a good first principle thinker that you throw whatever problem their way they can come up with an innovative solution.
So try to put yourself in those situations. to put, know, even if it’s like, think about like next products, think about Cursor and ask yourself these questions that if I had to grow Cursor tomorrow and I was their growth PM, what would I do? And, you know, ask yourself these questions. You have AI to validate your answers to figure out are you going in the right direction? But you just need to continually hone that skill set and that part of your brain. And like, you know, brain is like any other muscle. If you don’t practice,
it doesn’t kind of grow. So you just need to practice that part of your brain which is like first principle thinking. know ask yourself these questions every day about so many different products that you know if I were Figma what would I do next? How would I grow? How would I compete with Lovable moving next? And you know asking these questions makes you more aware of all these scenarios that are popping up in the world of product.
Federico Ramallo (50:11) Right, right, yeah. I think something that you mentioned, I think you mentioned it or I was thinking it, and I didn’t say it, is that AI can help us. I mean, you kind of said it with the K example, The AI can help us in a lot of time consuming, low complexity tasks, right? But.
Saumya (50:25) Hmm.
Federico Ramallo (50:35) it is still us who are leading the way and giving direction to the tool. So we are the ones that are still in control. So it’s not like AI is going to replace us, but it’s going to augment us.
Saumya (50:40) right.
Close.
100%. Like the people who are not using AI would be left behind for sure. But doesn’t mean that AI is going to take over for us. like a human with the right prompting techniques can take over the world.
Federico Ramallo (51:06) Right, yes. And the
other thing is, and you mentioned a criteria, knowing when to use the AI and when not, right? There’s some customer user research that you can do with AI that used to take a lot of effort and resources. Now you can ask and you’re going to get a lot of good answers. But there is a limit to how much you can trust those responses, right?
and being able to figure out when is the AI hallucinating or trying to give you, trying to make up an answer to please you, right? So that’s the critical thinking part, right? Yes.
Saumya (51:40) Right. ⁓
Yeah, AI is trained
to always say yes. So it’s your job to be, you know, to look at it with a certain amount of skepticism.
And you know, the only I keep telling like my team as well, that just because AI is telling you something doesn’t mean you don’t have an opinion like your opinion, like pre-establish your opinion and then validate it with AI. Don’t ask AI for its opinion. Like that’s it. It’s a very slight difference in approach, but that in itself can move mountains that you start with an opinion and then you validate it as opposed to having no opinion and telling AI what should my opinion be.
So that’s kind of the difference.
Federico Ramallo (52:24) Right,
Amazing insights. So, Somya, we’re running out of time, but I truly appreciated you being here today. I think we had a really good conversation. Any closing remarks that you would like to share?
Saumya (52:42) Yeah, I’m just really excited how AI is changing the world. And I really appreciate you bringing all of these amazing people and their insights for everybody to listen to. So thank you for the wonderful work.
Federico Ramallo (52:56) Yes, thank you. Thank you for being here today.