Subscribe
Share
Share
Embed
Become an Epic Product Engineer is Kent C. Dodds's interview podcast about skills that stay valuable as AI takes on more implementation: product engineering - blending technical depth with product judgment, user empathy, and problem clarity.
Each episode is a long-form conversation with a guest who has shipped real software and cares about building the right thing before making it right. You get full audio, transcripts, structured show notes, homework (one concrete action to try), and links from the conversation.
Canonical home for the show and every episode page: https://www.epicproduct.engineer/become-an-epic-product-engineer-podcast
New episodes publish on Wednesdays (America/Denver). Video is added on Transistor for supported podcast apps when available.
Complements Better with Kent - Kent's solo series on durable skills for people who ship software.
Kent C. Dodds (00:01.176)
Hey everybody, it's Kent C. Dodds talking about product engineering with my friend Ruben Casas. How are you doing Ruben?
Ruben Casas (@infoxicador) (00:07.019)
I'm doing great. Thanks for having me. I'm really looking forward to this chat.
Kent C. Dodds (00:11.948)
Yeah, likewise. I absolutely love chatting with you anytime. We go way back. It's been many years that we've known each other. Probably my favorite thing to do with you, Ruben, is go to shows in London. Back to the Future musical, that was pretty awesome. Harry Potter, the six hour edition, The Cursed Child, it's so good. So I just love hanging out with you. And thank you for joining me to talk about product engineering today.
Ruben Casas (@infoxicador) (00:25.134)
Yes.
Ruben Casas (@infoxicador) (00:30.947)
Ha ha.
Ruben Casas (@infoxicador) (00:38.061)
Awesome. Likewise, yeah, I love going out in London. If anyone is in London, let me know if any tips or anything. London is doing really well right now, so come visit.
Kent C. Dodds (00:48.694)
Awesome, yeah, I need to get back out there. So Ruben, why don't you give us, like fill our context window on who you are and what you're involved in and then we can start talking about your history and experience in product engineering.
Ruben Casas (@infoxicador) (00:56.045)
haha
Ruben Casas (@infoxicador) (01:04.195)
Yes, so I have been in the industry pretty much 10 to 12 years, depends on when I started. After university, I did a few projects, but professionally about 12 years. And I hope it's been moving between building products and solutions and involving the whole product experience, even selling. I remember selling software at my first company, which is something that many people have experience with, but I had to sell software as well. And then moving towards the years
Apart from building things at American Express, I also moved to working with platforms and now developer tooling at Postman. And most recently, I got into MCP and AI. And this is something that we have very much in common because we've been looking at MCP and the AI section of the industry in the last year or so. And I'm really excited of the things that are happening there. I started to build products again.
So which is very exciting. So my career has always been fluctuating between building tooling and building platforms. And now I'm really excited, like everybody else, to be building products again. And I don't know how you feel, but it just gives you a different sense of achievement when you can just build something and then just touch it and give it to people and show it to people. yeah.
Kent C. Dodds (02:26.316)
That is actually really interesting. Can you dig a little bit deeper into what you mean by everybody's building products again? Like has something changed recently that made it, like what did we used to do if we weren't building products before?
Ruben Casas (@infoxicador) (02:38.081)
Well, in my experience, what happened, and I don't know if this is happening to a lot of people, especially managers, but in my experience was, you know, I've been building and I've been climbing the ladder in the industry, getting more involved into the higher levels. But there was always that part of me that started leaving behind the actual building and getting very close to the building or the product.
Kent C. Dodds (03:05.55)
Mmm.
Ruben Casas (@infoxicador) (03:05.647)
So for me, was going back to actually developing software that people use that is not just a day-to-day, as you said earlier, like a ticket moving or just these ceremonies that used to have where we just talk about the work rather than doing the work. And it's very exciting. So I know a lot of managers and people with the new AI tooling are coming back to actually shipping code.
Kent C. Dodds (03:26.477)
Mm-hmm.
Ruben Casas (@infoxicador) (03:35.115)
And I realized how much or how little code I was shipping, like actual production code I was shipping in the last three, four years until last year when I started shipping product again. I wasn't doing any of the plumbing or the internal stuff, but actually putting things into the user's hands, which is very exciting. And I gave like really good motivation just to get back to building product.
Kent C. Dodds (04:01.282)
Yeah, so this sounds like it's a little bit more than you like going up and talking about more high level things and then going back to being an individual contributor, right? Like this isn't just, this is something has changed in the industry that has allowed you to both be high level but also build actually doing the building. Is that right?
Ruben Casas (@infoxicador) (04:21.997)
That's right. And it's not like I am leaving all the high level things behind. with LLMs and agents, I'm able to do both. So I'm still looking at the bigger picture when we talk about products and getting requirements, talking to people, talking to customers, which has been really interesting for me as well. But also keeping all the things I used to do before. So it's allowed me to go back again as an individual contributor to push code and to get
Kent C. Dodds (04:26.702)
Mmm.
Kent C. Dodds (04:32.963)
Mm-hmm.
Ruben Casas (@infoxicador) (04:50.861)
not just the architecture right, but actual getting hands on again, which has been really exciting in the past year.
Kent C. Dodds (04:59.746)
Yeah, that's interesting. It seems like because the people who have gone up to the higher level thing are now able to continue doing that and also do implementation, everybody who used to be just in the implementation space needs to find a way to get back, to get up to there quickly so that they can both implement and do proactive product work thinking.
Ruben Casas (@infoxicador) (05:24.771)
That's correct. And it is important to have both skills. Like it's important to be close to the customer, be close to the product and what things are happening at higher level, making decisions. But when you're close to the code as well, not to the code, but just to the product itself, when you're building it, you get that sense of how it feels, how it works. It is not just an abstract understanding of the product in your head when you're just looking from the top.
Kent C. Dodds (05:30.99)
Mm-hmm.
Ruben Casas (@infoxicador) (05:52.995)
when you go to the implementation details of how things work, you can get a bit more of a sense of how the product behaves, et cetera. So that's very important as well.
Kent C. Dodds (06:03.18)
Yeah, so we're not just product managers now. There's a technical aspect of the job that is still really valuable and the past experience that we have as software engineers is increasingly valuable in the amount that we can leverage these AI coding agents and directing them the right way to build the right thing.
Ruben Casas (@infoxicador) (06:25.539)
That's right. I think this is unfair. And I feel this is unfair for people that have experience because you can't see how valuable it is. Because you know that when you're building something, it is not just the product sense of how we should behave or how it should work, but also, back in my mind, it's always, what's the maintainability of this? Is it going to wake me up at 3 AM with an on-call when something goes wrong?
Kent C. Dodds (06:36.59)
Mm.
Ruben Casas (@infoxicador) (06:54.287)
It was a long-term vision for the product, not just how does it work and does it fulfill the process that it's meant to do, but also how is it made up? How is it assembled together? And I know people want everybody to start shipping code, and that's great. People are able to do that. But there is also still the need for engineers to keep things together.
So what I call it is like, yes, you can give the ability to product managers to a ship code, but there is always someone who needs to assemble the little pieces together and ensure that they don't fall apart in the future. So I think for now, I mean, I don't know, we don't know how long this is going to last, but for now, there is still a need for engineers who keep things together that enable other engineers and other people who are non-engineers to ship product and to...
Kent C. Dodds (07:36.27)
Hmm.
Ruben Casas (@infoxicador) (07:52.399)
continue building the product on top of what is already there before.
Kent C. Dodds (07:57.238)
Yeah, I completely agree. And I do see AI coding assistants slowly eating the implementation requirements that we have. But again, like today, I certainly couldn't give these tools over to my non-technical sister and expect her to build a product. She could probably build a personal software, like a piece of personal software that would work reasonably well. And I think...
in the coming months that it will work more than reasonably well. But for a product, you have to have a lot more than just an input box as a prompt. So that's interesting. Now, as we're talking about these, having these engineering chops and like this experience as an engineer, I've seen in the past, and maybe you can resonate, this resonates with you, you have an example of this, but I've seen in the past where
engineering decisions end up driving the product direction for a variety of reasons rather than the product being driving those engineering decisions. Have you seen that tension before or do you have an example of that?
Ruben Casas (@infoxicador) (09:05.871)
That's right, and this is happening everywhere. So it used to be that the constraints were the technology. So you sometimes had to make trade-offs. And I used to say, and still say, that everything is a trade-off. So you are balancing the trade-offs in engineering and the technical issues that we have with having a good product and giving that product to the users. And before that divide was even bigger, you have to, you know, we didn't have...
enough capacity or time or engineering resources to do everything. And we had to make a lot of decisions on what we prioritized. And also there were other constraints that were technical constraints that there were not just time, but also complexity. And I've been in these discussions or I used to be in these discussions a lot where the product manager or the people building the product asking why cannot we do this? And then the answer would be, well,
Kent C. Dodds (09:52.013)
Mm-hmm.
Ruben Casas (@infoxicador) (10:04.491)
it is this too complicated, we will have to do a rewrite or architecture. And we could come up with a lot of these constraints in the technical side that we used to have to put that and balance it to. Now, those are still there. The difference is now it's easier or we can have more raw power to get these constraints out of the way. So I have seen that shift where the things that we used to do or plan before,
Kent C. Dodds (10:27.726)
Hmm.
Ruben Casas (@infoxicador) (10:34.703)
I just moved. Like we don't have, okay, yeah, we need to refactor this because there is a new format that is coming. Well, let's just do it. And the product section will be like, okay, just let me when it's done. But we would keep pushing the other side of the product as well. So those are still there. It's just now the balance is more like, yes, we don't have to make as many trade-offs anymore. We still have to make some trade-offs.
Kent C. Dodds (10:44.693)
in.
Ruben Casas (@infoxicador) (11:04.783)
And I think that during the podcast, you have been mentioning about what to build and what not to build. That's a different problem. But now the difference is like the things that you decide not to build are not because you have a technical limitation that's stopping you from doing it. It is basically a decision that now we have to make because that technical limitation might not be there anymore.
Kent C. Dodds (11:09.902)
Okay.
Kent C. Dodds (11:18.638)
Hmm.
Kent C. Dodds (11:26.892)
Yeah, that makes sense. I think currently you can kind of build the track as the train, like sitting on the front of the train. maybe that metaphor kind of falls over a little bit in this context because the track that you laid may actually be slop. And you have to go and clean it up for future trains or something.
Ruben Casas (@infoxicador) (11:50.223)
You
Kent C. Dodds (11:54.484)
I do believe that as time progresses, these agents are going to continue to get better and that implementation will be cleaner and cleaner as we go. And so we can still move relatively quickly. And so that's why I think that deciding what to build and learning how to do that is so valuable because it's a durable skill that isn't going to change. Even as agents get better, you're still going to need a human who can be accountable for decisions.
can weigh trade-offs and make a decision on the direction for the product to go.
Ruben Casas (@infoxicador) (12:31.671)
Yeah, so in terms of what to build, that's a good question. And I can speak from my experience in my career. Like if you ask me, how do you know as an engineer what to build or what a good product is? And that's a very difficult question because if you look at traditional engineering, you're given a task and you're just given instructions on this is what you need to build. But then flipping that script into, hey, I need to think
what needs to be built and then move into the execution is a part that is difficult. And what I have done since I was doing my first jobs, is being curious. During my experience, I have seen that even if it was not part of my job to do something, I was not just focused on doing the coding. I was also interested in what is the business doing?
just being curious about not just the technology or the technical part, but what is the business? How does the business work? How do we make money? That's a good one to start with because that will give you ideas on what is the product doing for us and what else we can add. I remember working with some interns at the very beginning of my career at American Express and they had so many ideas. And I was like,
These guys, fresh from college, they come and they have so many ideas. And that's a good thing. And that's something that is valuable. Now, how do you take those ideas and apply them to something that solves a business problem? That's a different one. I had a lot of prototypes and failed ideas internally at that company where there were really weird, wacky ideas as well that
Kent C. Dodds (14:10.477)
Mm-hmm.
Kent C. Dodds (14:17.272)
Mm.
Ruben Casas (@infoxicador) (14:28.855)
maybe would not make it to the customers, but some of them did. I remember one of the guys I was working with came up with this idea on how to improve conversions in terms of their onboarding. And that was an idea that none of the product managers had. They just had like a hackathon sort of project. They built a prototype and then they solve a problem and then they push it upwards to the decision makers just to make sure that it makes it to the product.
Deciding what to build, I think I'll summarize it as just being curious in terms of see what problems are there and just trying things out. It's underrated. I mentioned hackathons. I don't know if hackathons are still popular, but just prototyping and building things so you can feel what they do and also do they actually solve the problem for the users. And when you find that,
that it solves the problem for your user, then you will know, OK, there is something here worth pursuing in terms of building something and moving on from there.
Kent C. Dodds (15:37.666)
I like that a lot. You said be curious and that's exactly what Don Norman said on his podcast episode a couple episodes ago that that is a hallmark of the greatest idea havers is just that they never stop. Even if an idea doesn't pound out, they'll continue to be curious and I really appreciate the tie in to the business. I can say.
Like it was, it was kind of a meme at 10 years ago that like developers would just spend so much time perfecting their workstation and choosing what theme their editor was in and their font. And like, it's this whole thing. And honestly, like I couldn't live stream without somebody asking me what theme and what font and like all of this, this meta work stuff, frankly, that's not even meta work. That's like, I don't know what to call that. But, but all the work around the work, that sometimes we can.
Ruben Casas (@infoxicador) (16:27.385)
You
haha
Kent C. Dodds (16:35.278)
make an excuse and say, no, I'm sharpening the saw. But no, no, like now I think you really need to justify the things that you're doing from the business perspective so that you can actually push the mission of the business forward. And if you're sitting here and you're like, Kent, I frankly don't care about the mission of the business and I just wanna like collect my paycheck and go home, that's fine.
For now, I think that the engineers who really do care about the mission of the business and can come up with these product ideas are the ones that are going to be resilient in the future when the skills of traditional software engineers become rapidly less scarce.
Ruben Casas (@infoxicador) (17:24.291)
Yeah. And I think, don't know if I heard this somewhere, but we are paid to solve problems. think as software engineers, the problem is we always saw that we were paid to type code and to make, you know, programs or whatever. Actually, I think if you ask someone from the business, they will be like, I pay you to solve a problem. You decide to solve that problem with code or with infrastructure or with architecture or with anything, but you're solving the problem. So.
Kent C. Dodds (17:44.994)
Mm-hmm.
Kent C. Dodds (17:49.358)
Mm-hmm.
Ruben Casas (@infoxicador) (17:52.867)
That is the shift right now. That's becoming way more evident because we are not typing the code anymore. Well, most of us are not typing the code anymore. So we are not getting paid for that. We are getting paid to move the business forward and also to produce products. mean, if you're building products, if your company builds products and has customers, it's your customers, it's the product and the solution that you're providing to those customers. And it's difficult because
People are not used to that. People are, even if you are just going and getting your paycheck, I'm just getting paid to, I don't care about the business. I care about the craft or the code. Well, you still, there is still a goal. There's still a problem that you're meant to be solving. You're not just typing code for the sake of it. Now the difference is we need to move from that layer and moving.
Kent C. Dodds (18:43.617)
No.
Ruben Casas (@infoxicador) (18:50.211)
higher up into the layer of abstraction that you're still solving the problem and hopefully solve more problems because ideally, allegedly, agents and LLMs are meant to give us more productivity and then move into focusing on actually how to solve the problem and how to solve even more problems for the customers.
Kent C. Dodds (19:10.282)
Absolutely. So you mentioned earlier hackathons. I remember doing hackathons when I worked at a company and I loved it. Honestly, I don't know if I'd love it as much now because I just want to get home. But maybe there's a few hackathons during the workday, not like late into night. But I wonder if you can give us some like, let's get to practical, actionable things that people can do. What are ways that you find products to build? Because
Ruben Casas (@infoxicador) (19:21.998)
You
Kent C. Dodds (19:38.286)
We're not just products, but maybe product features. Like we're not just here talking to people building startups necessarily. Maybe you're at a company like an American Express, or maybe you are at American Express. Like in that kind of an environment, how do you find products to build rather than just, oh yeah, I'll just be curious and I'm gonna blindfold myself and throw darts at a dartboard and hopefully I hit the target. Like what do you do to identify true customer?
pain points and then determine solutions for them.
Ruben Casas (@infoxicador) (20:10.467)
So I think the hackathon thing I mentioned earlier, everybody's doing hackathons in a different way now. Because we saw that at the end of last year when everybody had time off during Christmas, and they started building projects and building things. That was like mini global hackathon where everybody's just trying to build something. And that's great because it means that you can, if you are curious, now there is nothing stopping you from turning that very quickly into a reality.
Kent C. Dodds (20:27.459)
Yeah.
Ruben Casas (@infoxicador) (20:38.703)
and making something that works. In my experience, in terms of how to find features, I think you need to start with a pain point. The example is, well, I was a postman, actually, was last year. We were building this agent and one of the pain points was, okay, this is just a lot of text and I want to see some UI. And then I started looking into it and I found your post on the MCP issues saying, hey, we need some UI.
I was like, huh, I think this is a pain point here that a lot of people are having. I think there's something worth building here, something worth solving for people here. So that's when I started to get involved into the MCP UI, MCP apps spec and talking to Liyad and Ido. And when I started doing the prototypes and checking how does this work, making a few demos. Demos are underrated, in my opinion.
I think demos are way more valuable today. Like if you can't just show a problem, but just straight away showing a demo on how your application solves that problem is the best way of even marketing is the best way of showing value is, hey, here's your problem. But by the way, here's the solution and here how it works. I think there is a method, I don't remember, I'm probably butchering about the how.
Kent C. Dodds (21:36.238)
Mmm.
Kent C. Dodds (21:47.406)
Hmm.
Ruben Casas (@infoxicador) (22:05.197)
then and then so then, probably I know which one I mean, but starting with the problem, then here's the solution and so then you can do this and that. So you can solve the problem. So hackathons in terms of what you can build now with AI easy in your own time without having to spend so much time away from home and having pizza on 3 a.m. I didn't like that part of the hackathons.
Kent C. Dodds (22:10.33)
Yeah.
Kent C. Dodds (22:32.409)
huh.
Ruben Casas (@infoxicador) (22:33.945)
But you can still stay at home and build something very quickly. And then you can create a demo where you can show the problem and then the solution that you built. And then put it in front of people for feedback, put it in front of customers and asking them, hey, is this something that you're looking for? Can you try it out? I built the prototype. I built the demo. I get some feedback. So yeah, guess demos are really underrated. We probably need to do more demos.
Kent C. Dodds (23:04.002)
Yeah, that actually is fascinating too, because at least right now there's a lot of talk in prototypes being the prompt. So like you work with the agent, you build out some sort of prototype, you learn a lot and then you fold those learnings back into the actual implementation, which I think makes a lot of sense. It's a lot of what I have been doing recently too. I'm curious, so like you mentioned building demos is a good way for marketing.
And I just wanted to pull on that thread just a little bit more. How would that apply to a consumer or a B2B application? Can you build a demo that inspires your consumer users to use your product in a way that they might not have considered? Or do you have any examples of that sort of thing?
Ruben Casas (@infoxicador) (23:55.253)
It's mainly on how to show that your product solves the problem. So the demo is more like if you go to someone and you try to sell it, and this is bringing back memories when I used to sell software. I remember I used to, so I found a problem where this point of sale system needed an e-commerce shop. So I created an integration with e-commerce. I built it myself. And then my job was also try to sell it.
Kent C. Dodds (24:07.895)
huh, yeah, I'd love to hear about it.
Ruben Casas (@infoxicador) (24:25.401)
But if you look at these point of sales people, they'll be like, well, I have a point of sale. Why do I need a website? But back then, like 10, 12 years ago, that was not something that people were like, yes, of course, I need to sell online on really, really old school type of businesses where they were used to, know, like super old software. but if you go with, hey, here is the store, the shop that I built for your point of sale system is already integrated.
I just had a template, I integrated it, and I gave the demo and say, hey, here's what you can do. Here are all your products that you already have. You can now, with one click, put them on here. We customize your shop with your branding, and then you can sell online. That way, for them, was more, OK, I didn't know that this was an option. You are showing me that there is an opportunity here, and you're giving me this already made template or demo that I can see.
and I can't just buy. So it was an easier sale where you have this template and then you can show the problem or in this case, the opportunity and then the solution at the same time. So that's why I said that marketing-wise of showing the demos, showing the working product is way more effective than a hypothetical, hey, you have a problem. We might be able to help you with this. So yeah.
Kent C. Dodds (25:47.01)
Yeah, I actually that, I don't know if it's quite this way anymore, but back years and years ago, Apple was really good at inserting their products, like in their advertisements, they would insert their products in the everyday life. So it wasn't about look at the specs that this thing has, but look at this experience that these people are having. And the iPhone is a really important part of that experience.
So yeah, without getting, I guess, too far into the weeds of the marketing side of things, though I do think that is important, I think to wrap up that idea, it seems like it would be a good idea to make it so that it's easy for you to build demos and prototypes with your software stack. so finding ways to...
automate that process or just make it so like when you have an idea, you can just go prompt an agent to spin up like a little example of this idea and then iterate on that a little bit. Then you can throw that away and bring in the new learnings. And additionally, if you can somehow close that loop and get it deployed somewhere, then you can start getting early user feedback and things like that as well.
Ruben Casas (@infoxicador) (27:02.927)
Yeah, the user feedback is what closes the loop, as you said, because the quicker you get it to your users, the quicker they know, yes, this solves my problem, or this is not worth pursuing. I'm building something in the MCP space right now, and I was like, OK, is this an actual problem? I was like, OK, let's create a prototype. And I created a prototype. didn't take long. How to design tools for MCP. And I gave it to a few people.
And it was not complete by any means. It was more like, this is what it looks like. Do you think it will help you design tools, like descriptions and connect it to LLM? And that took me half a day. But now we are, okay, yeah, that's very helpful. But I think it will be more helpful to do this or that. So if I spent three days, well, it used to take longer, like a week or two building this before having all this polish thing. And then I give it to the...
Kent C. Dodds (27:52.302)
Hmm.
Ruben Casas (@infoxicador) (28:01.039)
consumers and they'll like, yes, it's somewhat helpful, but this is what I want instead, or this prompt us to look at it at a different angle, a different way. So that's what closes the loop. Having feedback early, give it to your users for them to validate the idea very, very early. I think it's one of the most important things that we can do to build great products, really.
Kent C. Dodds (28:06.552)
Hmm.
Kent C. Dodds (28:25.378)
Yeah, that made me think of a question I wanted to ask you and then I realized it's the wrong question. But the question is, how do you get people to care about your ideas? Because you said you went to some people, you showed them your demo and said, like, what do you think about this? And that works really well with MCP because you are one of the customers in that case. Like, you know the problems and you're experiencing them yourself. And so you're just finding other people who like you have this problem.
Ruben Casas (@infoxicador) (28:31.695)
haha
Ruben Casas (@infoxicador) (28:39.97)
Yes.
Kent C. Dodds (28:53.6)
If you're at a company, you're building something that is not necessarily, like you're not necessarily the target market or you're not the only one who's gonna need to use this thing. Like you can't support it yourself, so like clearly you need to make sure that other users care about this. I think the question of like how do you get people to care about these ideas is the wrong question because rather you should be asking, I don't know, I haven't really formed this idea, but like you should be asking the user what.
their problems or their pain points are, as you mentioned, like you start with the pain point. so when you have us, like if you've identified a good enough problem, a good enough pain point, when you have something to show them, if it's so painful, they will be begging you to like, to build that and to test it out and all of that.
Ruben Casas (@infoxicador) (29:36.611)
Yeah, I won this year.
There is something though worth mentioning in this question is how do you convince people? Not convince, but... And the reason I'm mentioning this is because the people side of engineering or the relationship side and talking to people side of engineering is something that it doesn't come natural. I think it was mentioned in previous episodes and that is a skill that has to be improved and learned because...
Kent C. Dodds (30:05.454)
Mm.
Ruben Casas (@infoxicador) (30:10.849)
In the past, if you just had to interface with the business and what was happening with a gerotic or with a meeting when you're being told what to do versus now, you need to be more willing to talk to people, talk to your peers, talk to your customers and to be able to first understand the problem, propose the solution and communicate that solution and going back and forth and getting the feedback.
So there is definitely more involvement in the people side of things in engineering. And that might be bad news for some people might not like that. But unfortunately, that's a skill. And with AI, think if everything, we don't know what's going to happen. But if one thing is going to remain is human connection and human interaction and understanding other humans. I don't know. I don't believe the LLMs and the AI is going to be so good at understanding.
Kent C. Dodds (30:48.916)
Mm-hmm, yeah.
Kent C. Dodds (31:05.07)
Hmm.
Ruben Casas (@infoxicador) (31:09.225)
a human emotion or human connection. So there is still something that it cannot be explained unless you talk to another human, another person, and you together come to the conclusion of this is a problem. We have the same understanding of the problem and here's the solution. So that's another skill that unfortunately is now required. It was not required before as much, but now convincing people and showing their solutions is...
is something that is required.
Kent C. Dodds (31:41.506)
Yeah, it's like, this sort of thing has been happening forever. There could be the, like, the carriage driver who just really, really loves the process of getting people from point A to point B, but they also love taking care of the horses and all of that. And then eventually the car shows up and now the horses are gone and they, maybe they miss the horse, but as long as you were one who just like cared a lot about
the solution, which was getting people from point A to point B, then you can still be happy and there's new challenges and new things. yeah, as long as you're a problem solver, like there are still problems to be solved. And it gets me excited because I can solve more problems faster and hopefully with fewer problems that come out of those solutions. But when we're talking about the problems in these solutions,
How do you identify and prioritize the different problems that are in the product that you have? Do you have any experiences, whether it's at MX or Postman, where you built a solution, you deployed it, you thought it was going to be great, and then a whole bunch of support requests start coming in for that solution or whatever, and you realize, okay, there are a lot more problems here. Like, what do you do in that scenario, and how do you prioritize the problems that show up?
Ruben Casas (@infoxicador) (33:04.461)
This one is hard. I don't think I have figured this one out. I think it's not just you. I think you will have to work with the business. the thing is, and even before, engineers just wanted to get their work done, or they just wanted to, let's imagine, they wanted to do a re-architecture because it's going to make their lives easier. But that was not a business priority. It's still not a business priority today.
Kent C. Dodds (33:15.64)
Hmm.
Kent C. Dodds (33:27.682)
Mm-hmm.
Ruben Casas (@infoxicador) (33:32.803)
But now you need to make sure that you prioritize the right things. these things, the good news is potentially you can now prioritize these things because you have more time. So you can prioritize the things that you couldn't before. But on the other hand, if you are building too many things and trying to try multiple things at the same time, you might lose sight of what is actually important. And I've seen lately that people are
shaping a lot of features from the software that I use. And sometimes it's just very hard for me to catch up. And everybody's trying to play catch up on the features that are coming up with the code editors, for example, or the agents. And as a consumer of those tools, those features are great. But if those features are like 99 % of them are just
mildly useful, are not that groundbreaking. That's a distraction. Product quality might decrease. And also, as a consumer, I might not even have that problem. They may be just trying so many things that they're just not inventing problems, coming up with things that are cool, but actually, I could live without them. And that's a question probably you have to ask.
If you, this is the main test that you can have for a customer that you can ask. I think I asked this question to customers is, hey, if we remove this feature tomorrow, what would your workflow look like? If they say, it will completely break my, why are you talking about? This is absolutely no way. Then you know that this is something that's worth investing because it's a pain point and the customers really value this feature. But if they say, well, you know, it's fine. Then you know those features are potentially, they haven't found product market fit.
Kent C. Dodds (35:09.08)
Hmm.
Kent C. Dodds (35:18.702)
Hmm.
Ruben Casas (@infoxicador) (35:26.523)
And this is a phrase that one of my previous managers used to say, that features have product market fit as well, not just the product in general, but has this feature achieved product market fit? And I had an issue recently with one feature that is very cool to build, because we are working with a few LLMs and providers and things, but it's not getting a lot of adoption. So that's a very hard question that we have to discuss with the business in terms of, well, this is not getting adoption.
Kent C. Dodds (35:26.862)
Mmm.
Ruben Casas (@infoxicador) (35:55.117)
Maybe we are solving the wrong problem. But as an engineer, I'm like, I want to work on this. This is fun. But as a business, well, maybe it doesn't make sense because we are not solving the right problem or because it doesn't have product market fit. That particular feature doesn't have product market fit.
Kent C. Dodds (36:12.876)
Yeah, it's a never ending thing. like when you're starting a company, you think about product market fit all the time, but you just kind of have to do that again and again and again. even if your product stays stagnant, man, you nailed it and it has such good product market fit and it's a very niche thing. Like it doesn't really need a lot of features, whatever. The ecosystem around you, like the environment changes. And so.
you have to continue to adapt your product to the changing environment in which it resides. I resonate so much too with getting lost in the amount of features that are being shipped by some of the companies that I'm actively using their products. And that sometimes all I want is better reliability, better performance, better UX from the existing features. I don't necessarily need or want new features.
Ruben Casas (@infoxicador) (37:06.169)
You
Kent C. Dodds (37:10.03)
And so like, put it interestingly, sometimes I actually do just want a faster horse.
Ruben Casas (@infoxicador) (37:17.391)
Yeah, I think we've been seeing this, and people are coming up with slowdown. It's not just about breaking things, because breaking things is never the idea. If you are shipping too many features that are breaking your product, you are doing something wrong. You should just keep the stability. But even if you're not breaking anything, having all of these things that are coming up that are overwhelming your users,
and distracting them from the main core feature of your product might not be a good idea either because it means that they are potentially not using your product in the best way or they are getting distracted by all the things and not finding the right value in your product. But who knows? A lot of people are trying a lot of things, which is great. agents and LLMs have given us that opportunity to try more things, which is great.
Kent C. Dodds (38:04.494)
Mm-hmm.
Ruben Casas (@infoxicador) (38:16.624)
But we have to be careful on, again, going back to what to build and the why we are building these things.
Kent C. Dodds (38:25.196)
Yeah, absolutely. Well, Ruben, as we're winding down our time, is there anything that you were really hoping we would talk about that we haven't touched on yet?
Ruben Casas (@infoxicador) (38:32.911)
No, think you made me think a lot when you said that we don't know when it's going to stop in terms of how far of the implementation AI is going to take. because if you ask me today, I still think there is a lot of craft in terms of making systems behave the way we want them to behave. But maybe LLMs will become so powerful that they will build good.
Kent C. Dodds (38:43.982)
Hmm.
Kent C. Dodds (38:54.594)
Mm-hmm.
Ruben Casas (@infoxicador) (38:59.831)
modular architectures that don't need human involvement, for example. Because we definitely do need them today. Like, if companies are asking product managers to pipe code, yes, fine. But just know that someone behind the scenes needs to create the right environment for LLMs to be productive and to be safe to do that sort of thing. Now, the question is, that going to be the same in a few years? Who knows? But today, we still need that.
Kent C. Dodds (39:03.879)
Mm. Yeah.
Ruben Casas (@infoxicador) (39:29.347)
boundary, good products and platform architecture and taste and safeguards and testing, all of the things that you've been advocating for for so many years, know, best practices. All of that is very important, even more important, I would say today than before, because now people who are not engineers are touching the code base and are shipping products. So if you don't have the right testing and the guide rails, it's just going to become a big issue.
very, very soon. Yes, I just wanted to go back to that.
Kent C. Dodds (40:01.047)
Hmm.
Yeah, yeah, that's something that Matt Pocock has been really pushing forward as well. Like the old things of just like good architecture, good practices, that sort of thing is more important because when you've got a, at least now, when you've got a team full of interns that are just kind of getting into this industry, I'm talking about agents.
having good guardrails for them to make them as successful as possible is good. It's not an adversarial thing or whatever. It's just making sure that they can be successful in your code base. So yeah, those things matter a lot. And maybe in the future, the product managers will be the ones implementing everything and it will be the product engineers that will just be like gardening the code base to make sure that those product managers can be successful.
in the implementation, right? Like, I don't know, I could see that actually being a reasonable way to structure a product in the future. who knows, but at the end of it all, it's knowing what is worthwhile building that's gonna separate the successful products from the ones that fail.
Ruben Casas (@infoxicador) (41:05.529)
Yeah.
Ruben Casas (@infoxicador) (41:16.375)
Absolutely. I think that's the main question that we've been discussing, you know, what to build. It's a hard one, but it's something that we need to figure out and practice and learn.
Kent C. Dodds (41:25.87)
Mm-hmm.
Cool, well, hey, Ruben, thank you so much for giving some of your time today. As we wrap up, the takeaway for everybody is an actual action item, something that they can proactively do as a result of this conversation. So do you have some homework for our listeners?
Ruben Casas (@infoxicador) (41:46.071)
Okay, the homework is this. Find a problem, something that is bothering you. Go on, build it. If you have never used agents, some engineers haven't even tried this before because they think they don't work. But trust me, people who tried, and people who tried like in December, during all these hackathons at home, try them and they realize that you can build things, good things very quickly. So find a problem, create a prototype and record a demo. That's the task.
Like, record a demo, send it to someone, ask for feedback, and just show it. And if nobody, if it's only solving your problem, that's great as well. At least you get practice in terms of how to design a product. And if you give it to someone and that someone says, hey, actually, I want this, this is actually cool, then you can start getting some feedback from people and practicing what it's like to have customers, like what it's like to try to sell software to someone.
That's the takeaway.
Kent C. Dodds (42:46.75)
Awesome. Hey, thank you so much, Ruben. And if people want to follow up with you or keep up with what you're doing, what's the best way for them to do that?
Ruben Casas (@infoxicador) (42:54.607)
For me, X is probably the best one. I'm really active in the London community now. London is getting a lot of meetups and things, so I'm going to those events more often now in the AI community in London. So if you're around, let me know. I love to chat about all these things as well.
Kent C. Dodds (43:12.108)
Awesome, thank you so much. Thanks everybody for listening and we'll see you in the next one.