Latest / The Unfiltered Engineer / Ep 7: Ask Why, Not Just What feat. Kshitij Saxena

Transcript

Ep 7: Ask Why, Not Just What feat. Kshitij Saxena · The Unfiltered Engineer

• Vishakha Motwani: Hello and welcome to the Unfiltered Engineer. My guest today is Kshitij Saxena Kshitij is a senior product engineer at ePilot in Munich, where he's been since early 2025. Before that, he spent nearly four years at New Store, growing from software engineer to soft see software engineer to software engineer to, building systems like an asynchronous message delivery pipeline and a historical order import system on AWS. Today we are talking about what product engineering actually means day to day and what it takes to own a feature from idea to shed. Welcome Kshitij Kshitij: Thank you, thank you very much, and thank you for the good introduction. Vishakha Motwani: Awesome. tell us where you're tuning in from. Are you still in Munich or visiting someplace else? Kshitij: No, I am in Munich. This is my home. That's my kitchen that you see. Yes. Vishakha Motwani: Well, I'm so glad to have you here. we spoke a little while ago, and I like this idea of networking with people who have like different titles, who have a different view towards engineering. And that's why I have you here. The first time we spoke, you talked a lot about product engineering and with so much passion that I knew I had to bring you in. And we'll get started with the first question that I had for you, which was very surprising to me when I heard it first time, was what's the real difference between product engineer and a regular software engineer or even front end engineer, in practice and not just in what you see as titles or job titles being pushed out. Kshitij: Yeah. so This is something that that I'm also learning day by day, right? What a product engineer versus what a software engineer is. And what I've learned through these years is that the line is actually very blurred. I've actually met a lot of software engineers in their daily life that are act that are behaving like product engineers in in their in their daily jobs and they are the they're doing brilliant work, right? but essentially what the difference between software engineer or a product engineer is the question that you ask when you when you do some work. A software engineer usually asks what to build. and product engineer asks why to build this qu this difference between the what and the why is is basically the the most I'd say pivotal difference. and then if I would were to give you like an example that that like a software engineer when someone comes to them that hey build like yeah I want that in in the contact form that that we ask for a phone number from the users so that we can call them. It's a very simple request, and this could come, for example, like like a feature ticket from the sales team, it could come from I don't know any any other any other part, whatever that that you're building, right? In a as a software engineer, it's not a very hard thing to do, right? You would just go nowadays you would do it with AI in seconds, right? You would not even think about this thing. But but a product engineer would go deeper. Before actually touching anything, they would ask, why do you want the field? Because are there any other differences? There could be differences that when once you add the field, your the total number of submissions that you're getting in that form decreases because a lot of people don't want to do it, right? So is this the right solution for what it what the quest what this is? So we we spend a little bit of time beforehand to ensure that whatever we are building has a outcome. not an output as a as a software engineer when you just just just build something you ask what do I have to build and you build you have an output you have you you did the ticket you built the feature right but what we are looking for is is an outcome what what will happen after we have built it we will own the feature until the end and we will see how it's actually impacting it is it is it benefiting you or is it is it a problematic feature or things like this I can go Vishakha Motwani: I absolutely love that distinction that you made at the end about the what and the why. I wanted to know, like there are two parts that I want to dissect here. One of them is you said you kind of go into the why, and that you also mentioned that we spent some time. Now, how do you know that that time doesn't impact your delivering of the feature and it comes as a part of your job, right? Like it's very instinctive for you as a product engineer to do this. However, like where do you stop? Where do you say that okay, this the why has been answered? Now I can go ahead and develop the thing that I want to develop or shift the solution, I guess. Kshitij: yes, of course. I mean once you start these once you start asking these questions you realize that some of them can be be answered from from let's say the product manager of your team or the designer of your team or the sales or the support, wherever the or you or actually one of the best things about being a software about a about a product engineer that we do go directly to the customers and ask. we interview the the customers directly, we tag along because because Because I live in Germany and I work for the German company, sometimes language becomes a problem. But in that case we go along with our product Team with our support team and we we try to bridge that language gap somehow just because we want to get that first hand information. But I agree with you that a lot of questions will not be answered. We would not have enough data. We will not have enough stuff, right? in a normal scenario, if I if I would if I would be working like in in the in the ticket-based format, right? As we used to, I I used to work in that role before, right? In that case, you would just reject the ticket. Say that we don't have enough information, we need more discovery. But a product engineer would actually make a decision. They would trust their judgment that okay, this is the data that I have and this is I don't. Based on this incomplete data, I will take a decision that I will for formulate the solution in one way. The solution is not formulated until we have whatever we can collect. we don't talk in solutions. We always talk in problems because the the whole idea of being a product engineer is to understand the problem before thinking of any kind of solution. Vishakha Motwani: god, you just dropped another follow-up that I wanted to ask. But there are Kshitij: Yeah. Vishakha Motwani: two the two things that I'm super curious about from your first and from your second. Tell us the distinction between output and outcome. You briefly hinted at it, but I wanted to give you a few minutes to just again like separate it out a little bit for us in engineering terms. And the second is thinking about problems. overthinking about solutions. So I'll let you take away for outcome and output. Kshitij: Right. So it's it's actually not not very not very hard to to distinguish between the two. It's like let's take the same example of adding the phone number field, right? when you when you just build a phone number field and then you close your ticket, you deliver it, you ship to production, your your feature is complete. You see that okay, there are no incidents, people are people are people now have to input their their phone number fields, you check in the database that now you Getting the phone number fields and so you have an output, right? That's delivered work. That's good enough for for the output part of things. But when you talk about an outcome, what actually happened when you shipped that change? What number moved? How did your company or your user or your customer benefit from whatever change that you made? Right. if we sh we we were supposed to ship this kind of a number or this number field, maybe we see that the number of submissions that we are getting reduces. If the number of submissions reduce, the number of orders might reduce, right? You might make less money, you might get less sales lead calls or whatever. So a product engineer in that case would think of another solution. Like, okay, if you really need the phone number to contact the person, maybe You ask for them to still submit the form without the phone number and then add a call me back feature at the end or give them a phone number to then call you back or whenever they have time. give them a helpline number, give them your contact, or any other solution in which that the call connects. That might have more impact, that's why it might have more outcome or a better outcome for your. The thing for the same exact problem. Now actually I come back to the to the to this problem versus solution thing, right? When you get something like this from as a request, is like, hey, I need a phone number field, they're already handing you a solution. And as a product engineer, I am not good at accepting solutions. Because as arrogant as it might seem, I always seem to think that okay, maybe maybe I have a better solution. Why are you giving me a solution? Right? So that's why we try to dig deeper. We want to go into Background and see how what the problem was and how you came up with the solution. Most of the times, because I work with very smart people, most of the time the solution that they actually come up with is right, but sometimes it might not be. So that's why we try to think more in questions, in problems and understand what exactly is wrong before we start fixing something. Vishakha Motwani: I think like a lot of it you're hinting it as I find that like just be curious about your user, just be curious about where this is taking you. And when you talked about outcomes and you also talked about like what numbers are moving, that data also takes time to come back. So to keep to be on top of it and to keep working through that problem and that solution. It becomes very essential to think in questions, and by questions meaning like getting curious, right? Like it's the asking the smart questions. And I wholeheartedly agree with you. Like we're working with some of the smart people. Eventually, it all comes down to the context, right? Like what context do they have, and what context can you add? And that might bring another new solution for everybody, right? Like it it gives everybody else a lot more to think about. So let's move towards a little bit of the other side of things, like how much of your day is spent talking to users or product versus writing code, because we've talked a lot about asking questions, understanding the problem and figuring out the root cause maybe of the problem. Kshitij: Yeah. so essentially most of the time that I spent in in in in in this job is still engineering, right? Now I don't spend a lot of time writing code, I rather spend more time reviewing code, because we we rely on on AI quite a lot at this point, right? We have multiple agents running doing multiple things of work and it's mostly reviewing, testing the stuff that that that we have to, right? Or thinking about architecture, thinking about how the solution would look like so we can actually orchestrate those AI agents to get get the right solution. but that's definitely not all of it, right? and the another good thing about about Product engineering, which I love, is no one day is similar to the next, right? One day you might be talking to your customers, you might be talking to product support. the the next day you might be just deep down just f solving the problem once you understand everything. The other day could be just fixing some bugs, fixing some issues, debugging something, doing a spike for example, te checking technical feasibility for something. It could be absolutely anything because We own the product as product engineers from the beginning, the idea stage until the absolute end and every iteration that comes out of it. So when the idea or the problem arrives at some place, that could arrive from anything, that could be a sales requirement, it could come from the customer, it could just come in my mind or in someone else's mind, in in the product manager's mind or something like this. that could just be nothing at that point. So taking that. And then then deriving the right questions and then finding out okay what answers we cannot we're not we cannot find at this point, then making some assumptions, clarifying those assumptions and thinking what is the minimum amount of work that I can deploy to then clarify those assumptions or provide value. we are very lazy as product engineers, we don't want to do big big work. We we just want to do smallest thing that actually gives gives the impact, right? So we we chunk down things, we reduce the scope as much as possible and and just do just enough to then clarify those assumptions or do enough and then wait for the feedback. And when when I talk about this wait for the feedback, we we talk we we already have some idea about what our metrics could look like. And we rely on both leading and lagging. Some leading metrics are something that instantly when you deploy something you see a change. Like for example, if you suddenly I I don't know, suddenly if you add like a discount feature on your website, suddenly you get you start getting more orders. That's almost instant, right? You don't have to wait for it. sometimes, for example, you could also say that hey, I scaled up my my order management system so now I can receive hundred X more orders. now getting feedback for that might take a little time because you don't have 100x orders right now. When you go into let's say the holiday season, when when there's Thanksgiving, when it's this Christmas, then you will see okay, more people are buying and your system can actually scale to that point. you can definitely run some load tests and do things on your end, but you wouldn't still see those product metrics at that point. Vishakha Motwani: Because production is production, right? Nobody can predict what happens in production. So Kshitij: Yeah. Exactly. Vishakha Motwani: one of the things that you talked about, like bleeding and lagging indicators and waiting for data. Thanks for clarifying that, because one of the things I wanted to ask you was like, doesn't it take time? And I've been on that end where it takes so much time to get your data, to be static, to be like understanding is this worth? But One of the things I'm also curious about is how is this work different from experimenting, right? Like a lot of it you're talking about building with numbers, but where would you draw the line between a feature and an experiment if you've had the experience with it? Kshitij: Yeah. essentially all of this is experimentation, right? from the beginning until the end, you start with experimenting with a s a small solution. Then you if the experiment is successful, then you finalize it and then you make it a little more beautiful and then you put it to for more users out there, right? You see how it's working, then a new idea comes, then there's there's another experiment. Many of these experiments also fail a lot of times, which is important for us, right? the most important thing for us is definitely that we fail as fast as possible. So, rather than building a six month feature and then f then fail, we would rather do a six hour work Deploy it to production, see it failing, and then change our strategy completely, right? and this is also a very interesting thing that using these small, small experiments that we do every day, we can also influence the product strategy altogether. because that is also a part of owning things, even though we still work in triads or the in trios, right? The product trio, as you call it, where we have the engineer, the product manager, and the product designer all together. even with this, you you sometimes need the the the experimentation or failing ideas or and and the good thing is in this triad, together by discussing, by doing these experiments all together, getting the ideas in in this, you get to influence the product strategy, the vision, the mission of your own product, right? that is also a very big part of this this ownership. Vishakha Motwani: It it points so much to this, like the whole curiosity aspect. Like the more you know, the more you get curious, the more you understand the problem, understand the user journey, and also get better at your work, right? Like every single day you're learning something new and then you can apply it to the next day, the next problem, or the next support ticket for that matter. the other thing you'd mentioned, like a lot of your time is spent reviewing the code where agents are writing. Now have you tell me like tell me some example where you've where you have understood what needs to be done, you've understood the problem, you know what needs to go in, but there has been like there was some learning, right? To get this across to your agent, to tell it like, I want this getting done. And do you have any examples where It kind of like didn't produce the output that you wanted it to or it produced a better output than you wanted it to. Kshitij: Yeah. it has gone both ways, quite quite quite frankly. when I've especially in the earlier days when when the agents were not that that strong, we could not rely too much on on these agents. This was a time when when the the the biggest feature of AI was just auto-complete right in your IDE while you're writing code as soon as you're writing it completes half of it. at that point it it it made a lot of mistakes at that point I I was actually frustrated quite quite sometimes I was like why why is it even guessing or why is it making such mistakes and everything and this was not very far ago I think it was like a year Ago, right? by that time, AI agents have have improved so much, and then the tooling behind it, and the the introduction of so many MCP servers with every tool, and then different kinds of different kinds of I don't know skills and tools have come into the market, they are becoming better and better, and that's that's what I I I take the benefit of, right? at this point, I think it's also very beneficial for them to to actually do a I still completely agree that AI makes a lot of mistakes a lot of times. It depends on how much of the context window you're working with or what kind of model that you're working with. even if it doesn't take a lot of time, it might cost quite a lot, right? I wouldn't solve every every problem that I have with a favorable model, for example. and then and then every feature that I build cannot be for five hundred dollars. right. So in that case there is still a lot of management. and quite frankly it has actually benefited as well. If if I if I by mistake run something overnight and there's like, okay, I want a solution for this, these are the findings that I have and ran it. Sometimes it has actually produced an end-to-end feature which just works, right? Without any problems. And and it actually built something which I would have taken some time to actually come to it because you you iterate over those things. and because I left the agent overnight to run and just keep improving itself. it did all those iterations for me and provided a f a final solution. Now that could have gone in either way, right? Because AI makes assumptions, right? but this this one time actually that I remember it it was quite quite good. Vishakha Motwani: How would you just extending this topic a little bit, how do you prompt your agent in a way that you can give it the most information? Because sometimes like there is so much context in our heads that when we start implementing back when you were writing the code, actually, like you would know that this if a user comes from this workflow, this could be a problem. but how do you give think about it from that board's eye view and give it that context. Like when you're sitting down to write that prompt, what is the one thing that you have learned to do it more and more for it to give you the output that you need? Kshitij: So quite frankly, I'm also learning this as as we go, right? I'm not the perfect it perfect at it. I do use a lot of skills which are in the market. One of my favorite ones is something called the superpowers. it's a very famous skill almost everyone is is using at this point. the this this set of skills in superpowers actually do help me a lot. And this has this whole flow of when you're building your features, you you initially write a spec, then you write a plan, then you go for the multiple agent implementation and then then you keep checking and reviewing each and every agent's work and then finally your orchestrator gives you a a final output. I find that this kind of a flow actually makes sense for me. Sometimes I also document a lot of these in sometimes Jira tickets, sometimes in simple MD files or things like this, so that I don't overfill the context with a lot of information and then pop polluted. but essentially going with such a flow, and I've also learned that that kind of when you have two different models reviewing each other's code, then it's actually much more beneficial. beneficial. and then you can achieve things like this. other than that, I think it's just the agents are smart enough to to understand what you know what you don't and they can always ask questions to clarify things to clarify assumptions I try to give it as much as information as I have in the initial prompt. I also like using XML tags sometimes to tag the data separately. this is something that I actually learned from Anthropic In their prompt engineering documentation, I think. Their XML tags are are very friendly. so you just if you want to provide some links, you provide them as as tags inside the XML tags. If you wanna provide some pointers or feedback or things like this, this works. yeah, I'm thinking about the learnings that I have day by day, but that's that's what coming to my mind. Vishakha Motwani: I love that. Thank you for dropping a few tips here and there. I gotta go and check them out. these are the things that make you better every day with AI and still get the result that you want. the one thing if we were to shift gears, we've talked about fixing bugs or we talked about a feature in the smaller way, like having a phone field. But if you had to describe like How would you go from an idea to being shipped and what's like the hardest part of owning a feature? Kshitij: So from an idea to getting it shipped, the lifecycle kind of looks like okay, you have an idea. you draft some problem statements around that. That okay, what what is the problem that you're trying to solve, or if it's multiple problems that you're trying to solve, trying to drill it down to some easy questions that that can be answered or where you can have some assumptions, right? Essentially, once those assumptions are there, then you talk to your customer, you talk to the product support sales. Whoever that you can in the business around it. you look at some compet competition, you look at some other tools who are who are doing similar kind of work, maybe in your industry, maybe not in your industry, and then apparently you you get get some ideas. then you essentially use or or at least what I do is I use AI to do some proof of concepts that what thing works or what thing doesn't, and this proof of concept doesn't have Have to be it doesn't have to involve customers all the time. This could just be to prove yourself that this kind of thing can work. especially essentially for bigger features, I think it's important for you to do quick Of concept quick and dirty. It could it it could be something that is absolutely not ready as production code. maybe your support team can can give you some feedback on it because the customers can't see the the the the shitty feature that you've built at this point, right? so those those proof of concepts kind of help. and then you kind of validate two or three approaches that that want to forward with and then you see what kind of trade-offs that you have right once you finalize one approach and then you're happy with the trade-offs and then you've clarified that okay these trade-offs make sense for me in the long term or at least in in the medium to short term at that point you start then building and then after the building part is is the time then then that that I don't know the antenna goes up. It's like, okay, now I'm excited about the users to get introduced to my feature. So it it involves everything. It could be how do you introduce your feature to them? What kind of marketing do you need? Need some kind of release notes for the users? Do you want to send them an email that a new feature has arrived? Something like this. Everything is kind of in you are in the loop with what whatever is happening at this point. after the feature is shipped, you track it right as much as you can. You look at the logs, you look at the data, you look at what kind of orders you're getting, submissions you're getting, wha how many people are you clicking the button, it could be absolutely anything, right? And then you observe patterns. You observe where and what can can actually be improved. And this I think is the hardest part to answer your question. When once you've deployed and then you looked at some patterns, then basing basing those patterns or looking at that patterns and coming up with the next iteration of ideas or talking to the customer and and seeing okay what because then essentially you have that mental thing of that now you're starting from scratch again because it's now iterating and your f the feature that you ship for the first time was not complete, which you know was never never complete because you did the smallest thing, but it was not complete. So now it needs to be something better, something improved, or synthetic. So and then again, prioritizing is definitely one thing, which is which which we have been struggling with ac across industry, I think. That what get what gets built and I think AI has helped quite a lot, because we can now multitask or do things like this quite a lot. but I think still priority is is still something that we're struggling with. Vishakha Motwani: Absolutely. I I like that big overview, Kshitij: Mm-hmm. Vishakha Motwani: but there's something that I picked up and helped me understand the difference between like this is a lot of work going in upfront, right? Like when you're even before you've shipped something, shipped something, like you're speaking with people or you're getting data and you're basing your experiment or the feature on that data. So how do you I guess like the question essentially is you want to build the smallest thing. There is a lot of going slow initially and getting all these pieces, but also not letting it impact your like the big picture view. That's a lot to be patient about, right? And I'm just trying to understand, like, between from the role that you've taken, how did you come about learning? learning this part, like, okay, this is this is it, like this is how much time I'm gonna spend. It should take this much time because at some point you do have to give a timeline to the stakeholders saying that, okay, Kshitij: Definitely. Vishakha Motwani: this is when it's going to happen. So walk me through a little bit about how do you pace all this information, especially with AI, like changing, things changing, the estimates change and like almost everything apart from you is changing around you, what the customers want, what the data wants. how do you deal with this incis inconsistency, which has always been there by the way, like I agree with that, but how have you learnt or improved in your career with this aspect? Kshitij: Yeah. actually that's that's that that is a great question because starting with I had to learn it the hard way. which is which is that I burnt my hands multiple times doing the wrong things or building the wrong features a lot of times. since I've started started with this career, which I'm not professionally trained at, because so I had to learn a lot thing, a lot of things on the job, right? and then I have burnt my hands enough time building the wrong thing and then b being stuck with it for for quite a while, right? So if when you see that if you build the wrong thing, the rework Kind of takes much more than spending a little bit of time beforehand and then being patient about what you're going to build. Right? essentially if you ship the wrong features, your customer might get used to it. Once they get used to it, they won't you they don't want to give it up. Once they don't want to give it up, they won't also migrate to a different solution. Then the competitor who has actually did some research will come up with a better solution and show it to them when you don't have the child, even even A chance to to do this, right? So I think this is something that that is kind of like a muscle that you train with time. I'm still training it, I'm not perfect at perfect at it. I I've seen a lot of people who who instinctly instinctively can do it. they have an intuition about things a lot of times. I'm still learning. how to do this but but I've I I've been much more careful with with than just jump into building even though that's the that's the best part of the whole thing right as builders we seek to understand the problem and then just dive into s solutions after that right so it's it's the the you you kind of have to to wait until you understand the problem until you can jump into solutions because jumping the solutions might cause problems. Vishakha Motwani: Yeah, I love that. very recently I did a podcast with one of my friends and we were talking about influence over authority. and his point of view was also very similar. Like listen to the problem, listen to your customer's problem and wait and just let them let them finish, like let them explain it to you in the best way that you can because our tendency as humans is to jump to solutions and it will give you so much more like you wouldn't need authority like you would already have the influence because you understood their problem and when you're proposing a solution you're giving them the best solution that you have in with with your product and you will be able to cater to almost all of their problems if not like some of them. So I love that that your yours is also kind of hinting on that idea that just be patient. which I could tell really, like from all the things that you've described, I was like, my God, you're so patient about this. But I think this leads me to another question and I think I would know the answer. But again, not preempting. what do engineers coming from a traditional ticket driven role like get wrong when they move into product engineering. And I can sense like from all that you've said, I probably know, but I want to hear it from you. what do you think has been different? Especially you also came from, I think a ticket driven role, right? So Kshitij: Yeah, yeah. I think the first thing that I did learn when I moved from from being like a very what what to build software engineer kind of role, was that the focus on on the output. is that I the the more features I build, the more I deliver, the better it is, right? the the more tickets I close is better, right? And this is also in a lot of places where you are tracked. Where your performance is measured in this way, right? It's like the more tickets, the more the more features that you build, the more tickets that you close, the better that you are, and the faster you are you are. It's kind of like like like a support role in in in a lot of places, right? Getting away from something like this and then understanding that hey, it matters more when you make an impact and you are the owner of things and no one's actually tracking the number of tickets or the lines of code that you for you write, it makes more sense that they track how much impact that you made on the product or how much you changed the business, the changed the product for the better, right? Or how much experimentation did you do? I also really like tracking how many times did someone fail. that's that's in in in the last company that I worked for we actually had some some time in the week or time in the month where we all got together and we showed how we failed altogether. and this this this failure was actually celebrated because it always comes with a learning, right? A lot of times when we used to demo our features to the company to sales and to support and other people we did say that hey we reached here but we failed multiple times to actually reach here and these are the learnings that we have had so to also then equip them with with much more information about why this this feature is built in a certain way which makes them much more confident in front of the customer in front of their their whoever is is is there Stakeholder, right? Vishakha Motwani: this is such a wildly refreshing perspective in a way that you don't talk about your failures, you talk about learnings. It's almost never a failure, right? If you get something out of it, the only thing that I feel you have to do is stop, wait, acknowledge, and get the retrospective or get that reflection in so you can realize that it wasn't really a failure and your perspective also on like your sharing this because so that they are more equipped, right? So whoever around you is more and I can think of it in real life is if you had more engineers, junior engineers joining your team or newer engineers joining your team, there is a tendency that, why can't we do this, why can't we do that? But now they have this information that yeah we did do this, it failed and for the reasons that I can tell you that it failed now you You have well, you will still make mistakes, but hopefully you'll make newer mistakes to learn from it, right? So I absolutely love this perspective. I did want to give a minute on one of the articles that I read from you, which was about the product engineering, and you said you already hinted at it, which was ask the why, but you had added one more question, and if you can give us a brief insight into Like it's such a small thing, but how did you come up with it and what's your perspective on it? Kshitij: you're thinking you're talking about the article that I wrote. Vishakha Motwani: Yes, the why and the why now. Kshitij: yeah, it's it's it's been yeah, yeah, it's it's been quite quite a while. but yeah, actually Vishakha Motwani: Yeah, but Kshitij: that has been one of one of the best learnings as well because sometimes and this comes back to the prioritization question, right? I think the prioritization is something that that is very hard to completely solve and you continuously have to find solutions to how to prioritize and what to prioritize and what to not, right? And essentially that is also something that I wanted to to then give out to the to to the the product engineer community is with this age where building is easy where you are building as fast as anyone could or historically you're shipping more than anyone could and this point it's very important to understand why do you want to do it now Right, what makes the feature very important to to be built now, not just not just the why, but also the why now. Right. and the and everything behind this is is essentially understanding or learning that sometimes some features, some products are very ahead of their time, and sometimes they they are already outdated, right? Understanding the right time in the market, understanding if if actually your customers are ready for some. Something like this makes a lot of sense. Like a lot of times, especially with this AI thing, everyone wants to integrate AI into every part of their platform. Every SaaS platform wants to become AI native and things like this. It might not make sense if you're building software for a post office, right? Because people who are working in a post office are already dealing with papers, they're printing, they're sending letters every day. They are not the Most tech savvy people, you have to understand who your customer, who your user is. They will not be the ones who would be very happy if you have like the biggest AI feature in your platform. if they don't trust it, if they don't if they if they intuitively don't know how to use it, or sometimes they're also especially because I live in Germany, there's also darken shoots, which is data privacy or data security problems, right. understanding what what could be a problem and what and not every state of the art solution needs to exist in the platform unless it's absolutely important for your customer is important. That's why there are a lot of ideas, but just understanding what to build now and what not to build now is is something that is very important. Vishakha Motwani: this is so good. Like, there is so much perspective shifts that I've received today. talk about your mistakes and failures, celebrate them, the outcome versus output. Like it's not that sometimes people are aware of it, it's just that bringing that awareness into the forefront and making that like making that your daily part of life is what I find that it's it's a little difficult. when you're thinking about like five to ten different things and bringing them all together to do this one thing that is serving your customers, right? Serving your organization eventually. Thank you, Shatar. Today so now we are at the part of the show where I ask the same three questions to every guest and that's, if someone remembers just one thing from this conversation, what would you like that to be? Kshitij: I mean one thing that I remember is is going down the memory lane. and thank you for that. Your questions are so so I don't know, intriguing that I I actually went through in my mind through all those years that I've been learning and the mistakes that I've been doing and then all those things. and all the features that I built throughout the years and I had to think about all of that. I think that was a very good experience and a good trip down the memory lane. Vishakha Motwani: So what would you hope that that your you that the people listening to you would remember about product engineering? Kshitij: I would I would say even if you're a product engineer or not, whatever kind of career that that you have chosen, do this thing of thinking about the impact, this outcome versus the output that will definitely benefit them in every field, I think, everywhere. you don't always have to do the most amount of work. you just have to do it smartly. Vishakha Motwani: I love that. and I like that you kind of also mentioned that it's not necessarily just for product engineers, right? Anybody in any career could think about impact in a different way or the outcomes in a different way. The second thing that I have for you is is there a show, a book, a podcast, or anything that you recommend that you consume yourself and find it very helpful? Kshitij: Yeah. books I I do read a lot, but those are mostly fictional books or or things like this. it's been quite quite a lot. Vishakha Motwani: Go for it, like if you have a favourite. Kshitij: yeah, I mean right now the one that I'm reading is called The Vegetarian by Han Kang. and it's it's a story about a Korean woman who suddenly gives up meat. and and and there is no clear reason why, but there are three different perspectives of different people on why they think. something like this has happened and it's a very eye-opening or very intriguing story, which I really like. podcasts I I do listen to quite a lot of them. Andrew Huberman is actually one of my favorite ones, I think. that I have been following Andrew Huberman for quite a l quite a long of time. I wish I could just implement everything that he teaches, but unfortunately not. but but yeah, I really like listening to that kind of things. yeah. Vishakha Motwani: you talked about the perspective about that the book, The Vegetarian, and I feel like that's so fitting for this episode itself when you close your laptop, what's the next best thing that you like to do? Kshitij: this is something that I do struggle with still still quite quite a lot because I'm more of a morning person than an evening person. So I do have like my morning things. So before I actually start work I do a lot of things. I I'm my workout, my morning routine. That that my breakfast, I think that's more important. In the evening I do struggle with closing my laptop at the right time, because some especially with these agents who are becoming stronger and stronger and smarter and smarter. I think I just want to play with them quite a lot. but I still like going out a lot of times. I recently got a new bike, so biking is one of the one of the good things, especially in Munich. It's a great biking city. a lot of nature to bike around and So that's that's quite good. I do go swimming sometimes. I go meet up go meet my friends, watch a movie. I'm a big fan of books and movies. so all kinds of stories, those those kind of help. yeah, that's that's pretty much it. Vishakha Motwani: Awesome. Thank you so much, Shatad. It has been a pleasure having you on this episode. And I hope you enjoyed the conversation. And I'm so glad to have you here. I'm so sure that so many people listening would benefit from this perspective shift. And I've taken so much today from this episode. but that's about it for today. Thank you so much for being here, taking the time out of your evening, and we'll talk to you soon. Bye. Kshitij: Yeah, thank you very much.