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.123)
Hello again, everybody. It's Ken C. Dodds talking about product engineering and with me today is Sean Roberts. Hi, Sean.
Sean Roberts (00:08.47)
Hey, Kent, thanks for having me on.
Kent C. Dodds (00:10.031)
Yeah, thank you. You're a returning guest. You were on the Chats with Kent podcast, which by the way, anybody can call in and ask any questions. Just go to kcd.im slash chats. That will take you there. But yeah, Sean, this is, it's been a couple of years since then. And now you're here to talk with us about your experience as a product engineer and kind of, I think one interesting thing is that you mentioned that you're just kind of naturally falling into this role.
And, well, I do think that the term product engineer has been around for a long time. And it's certainly those skills have been valuable for decades. It's only recently started getting a lot of attention as like a defined role. And yeah, so one thing that you mentioned is that like, as you've been listening to this podcast, you're like, I'm kind of like doing some of that stuff already. And I think that resonates with a lot of people that they realize like, these are skills that I've kind of naturally developed.
even if they weren't very well defined or intentional. So with that little mini introduction, I think it would be useful for people to get some context on who you are and what you do, and then we can get into specifics about what product engineering is for you.
Sean Roberts (01:26.432)
Awesome. Yeah. So I am a engineer at a company called PhotoShelter. We're a digital asset management tool. I joined PhotoShelter through an acquisition. I was the CTO and I'll put giant air quotes around that because we were four people. So I don't want to give the impression that I was leading a giant organization. I was the tech head tech guy at a small, small startup that did content distribution, mostly to sports teams and leagues. We were acquired in 2023.
Kent C. Dodds (01:40.93)
Yeah
Sean Roberts (01:54.318)
Prior to that, I worked agency for about 10 years straight out of school. And so I've had a lot of experience working in small companies, working directly with customers and doing what I've sort of come to learn is a discipline called product engineering.
Kent C. Dodds (02:11.011)
Yeah, that's a common thing that I'm hearing from folks is that being a consultant or being in an agency, you find yourself interfacing with customers and other key stakeholders more frequently than I remember interfacing with my customers when I was at PayPal, for example, because you're just working on this one project for an extended period of time and you kind of get into this little routine.
Whereas at an agency or in consulting, you find yourself maybe not pivoting. Sometimes you can be a consultant on a single project for quite a while. But your work is directly what is being paid for. And so you end up interfacing with those stakeholders a lot. Are there any experiences that you had when you were at the agency where you remember being in a room with...
key stakeholders and having to exercise some of these skills that you now have as a product engineer.
Sean Roberts (03:15.714)
Absolutely, yeah, I think I really learned a lot of this and it kind of it's a bit of a funny story the way that I fell into this which is that the owner of the agency, my boss did not drive and I had a car, I had access to a car. I was hired young so it was my mom's car for a little while and then eventually it was my own car and so I would end up being his driver to these sales calls and I would go in with him and I would start to realize that.
Kent C. Dodds (03:31.171)
Hmm.
Sean Roberts (03:41.618)
could ask questions in these calls and I could get a better idea of sort of what it like, what it is that these people really need. And I could also sort of translate on the fly into, okay, well, how can we solve that with software? And after a few of these, I was starting to able to offer solutions in the call and, know, say, well, would it work if we did this? Or they would say, no, it wouldn't. And you could sort of work through directly with the customer and this would save so much time and so much effort, versus.
Kent C. Dodds (04:08.214)
Hmm
Sean Roberts (04:10.306)
the sort of flow of getting the specs from the customers through an intermediary, maybe laundered through designs that you would get as a PSD file from the design side. Having somebody technical in the room right from the start to sort of catch these things early and really sort of narrow in on like, do we actually need is something that I learned pretty early on in my career could save a lot of headaches and a lot of money for a lot of people.
Kent C. Dodds (04:20.514)
Uh-huh.
Kent C. Dodds (04:36.621)
Yeah, yeah. That what's interesting or one thing that stood out for me is like you mentioned that you were younger and we're driving your mom's car. How did you feel come, like how did you get to feel comfortable asking questions like that? Where, I think for me as an early or young developer being in meetings like that, I would just like, I'm going to sit back and just let the adults do the talking. Like how do you develop that sort of
confidence to be able to say, no, no, no, wait, like, I think that's the wrong approach. Maybe we should go like, how about we do the solution this way or whatever.
Sean Roberts (05:17.676)
It's a, yeah, that's a good question. I think another term that didn't exist until recently that, you know, I feel describes me as yapper. I've always been a bit of a yapper. and so I've always been pretty happy to talk to people. but I think part of it is if you're in a conversation and you can hear two people talking about something or multiple people talking about something, that maybe they're lacking some expertise or they're lacking some key context is being able to.
Kent C. Dodds (05:26.959)
Ha
Sean Roberts (05:46.978)
jump in at that point and say, not to step on anybody's toes or not to throw anything off course, but just here's a bit of information that I have that is material to this discussion. And I think if you do that, even if you're junior or even if you're not used to speaking up in meetings or things like that, if you're in a room, you're probably there for a reason, probably a better reason than that you have a car. And I think that you have some knowledge that people in that room might not have and that
Kent C. Dodds (06:09.674)
Hahaha
Sean Roberts (06:15.18)
you should not be afraid to share that information or to get the information that you need to come up with the sort of solutions that you're gonna be asked to come up with.
Kent C. Dodds (06:22.733)
Yeah, I think that's a great insight. Honestly, it's one of the reasons I started podcasting was because I heard other people talk, like I would listen to a podcast. I'd hear them talking and I'd really want to insert something. Like I want to provide my own feedback on that conversation. I think that might resonate with, I don't know, maybe somebody listening right now is feeling that way. But yeah, that kind of attitude of I have something to share, I want to share it. And for some people that might be easier.
than for others. I'm also a Yapper, so that comes a little bit easier for me as well. I remember there was a company that I worked at where we were talking about integrating with this third party and it was a really difficult integration and they were being a real pain. Of course, many integrations are. And I was new at the company, didn't really know anything and I just said, well, what if we just like...
acquired them and then we have all control. like they were really nice, but like this company turns out was like a hundred or a thousand times bigger than we are. And so it was very, very, I guess the reason I bring that up is just to temper things. Like you do still want to listen, but, in those meetings, when there are things that you don't know, I think that it's a good idea to write down.
the things that you don't know and ask somebody later and be like, you use this acronym or you're talking about this or I had this idea. I actually have another experience where I had an idea and I asked somebody about it later and they explained to me why it was a bad idea. And so like I could kind of save face and not do that in that meeting necessarily. But I think in general, the idea of like being the technical person in the room is valuable. And you mentioned that,
early on is that having someone technical from the start is a really valuable add to those kinds of conversations. And this brings me to another thing that has come up a lot in the podcast is as software developers are slowly moving in the direction of what is typically a product manager role, a lot of software developers are thinking, hey, like, I don't like the fact that the AI is eating my role and my responsibility that I've taken as an implementer.
Kent C. Dodds (08:47.259)
And is this industry or is this half of the industry gonna just be completely wiped away and am I going to have to be a product manager? And so I'd love your take on that. Like what is the valuable aspect that you bring as a technical product engineer in those types of meetings?
Sean Roberts (09:09.262)
I think planning now in a more product, like in a product company versus a consulting or an agency type company. think planning is a really big one. think almost maintaining that same feeling that you can maintain in a consulting role where budgets exist, the business is kind of your customer, and you're looking to achieve business goals using your technical expertise. think you can still...
have that same sort of impression on product, which is, OK, well, how do we plan this product out in a way that we can do the highest value things first? What are the parts of this product where solutions already exist, like this is well-trod ground, or an LLM can bang this out quickly, and we will all be comfortable with the code that it produces, versus what are the parts of this that are nebulous or scary? Where are we wandering into the dark forest on this project?
product or part of the project and helping plan those things out. Planning sort of resource allocation, things like that. That if you don't have a technical person in the room when you're say planning a set of revisions or planning a new product launch, can potentially, there will be, I've noticed a lot of times there's assumptions about what's difficult and what's easy or what's a straightforward solved problem and what's not.
Kent C. Dodds (10:07.854)
Hmm.
Sean Roberts (10:35.47)
And so again, being the technical person in the room to kind of help clarify those sorts of things. And then if you have expertise within the legacy systems that maybe you understand and control, then that's even another level beyond just being a tech person. It's you very specific, you know, your way around the dark forest in a lot of ways. And I think that can help too, rather than just, again, having specs or plans or a timeline dropped in your lap and reading it and going, well, this doesn't look right.
Kent C. Dodds (10:45.944)
Hmm.
Kent C. Dodds (11:04.071)
Yeah, yeah, yeah. You definitely want to be involved in those conversations early on. Like I have a whole bunch of thoughts about what you just said, but sometimes I will be talking with an AI assistant and like, okay, let's plan out this feature. How long do you think or how typically I'll say how hard would it be to do this? And sometimes it'll
say I expect that this is gonna be a three to six week project and I'm like, bro, you're gonna do this right now. You're finishing this in an hour. But the reason that I say that is being in the room, sometimes the non-technical people or even technical people who are just not familiar with the code base might not realize or might not be equipped to
Sean Roberts (11:33.646)
Hahaha
Kent C. Dodds (11:56.345)
provide some kind of estimate of the amount of work. And often a solution will be discussed that turns out if they knew how hard that was to accomplish, even with the AI assistants doing the implementing, if they knew how hard it was to accomplish, they wouldn't go that direction. They'd say, like that was just a whatever feature. We didn't really care that much about it. If it's really gonna be that big a deal, we can just go this other direction. And so being the technical person in the room,
who has the experience with the code base is really valuable. I actually have another example where I was talking with, this is a good example, a business owner who wanted to build an application. And I was kind of talking through some things with him. And he said, he was just really good about being clear about his level of expertise, which was effectively zero.
in this world and trusting me in all of the things that I was recommending with the experience that I have. And so for those software developers who've been implementing software solutions for decades, I think that those, and this, I should say with this person, this was a domain I never personally worked in or anything. I was just coming as like an external, like help give them some guidance.
And I was able to do that because of the experience that I had in the past. So the experience that you have as a software engineer is really still quite valuable in conversations like that. And I expect that that will continue to be the case.
Sean Roberts (13:33.743)
100%. Yeah, I agree completely. think that's interesting that you mentioned having not having the experience in that particular business domain as well. I think that especially early in my career, I kind of had this idea like, okay, because I'm smart with computers, I'm smart. And I think that can be really sort of detracting from providing the sort of best guidance possible.
I think a big part of being an effective product engineer, being effective on that side of the team is recognizing, like you said, where you don't know and meeting people in the middle, coming in and saying, okay, this is what I'm good at. This is what I understand. And then asking a lot of questions coming in as I know nothing about whatever it is that we're doing here. Even if you do know, it can be good to sort of bring that beginner's mind to it and make sure that your assumptions are not incorrect.
Um, I've seen a lot of software developers, um, who have not been in sort of the earlier conversations, maybe haven't met the customers, uh, and they will go off and build things, um, in just kind of, uh, an odd way and you'll talk to them and you'll realize that they didn't really fully grok, uh, the way the business works or the workflow that they wanted to apply or things like that. Um, and so, yeah, I think that's a great point you bring up about, um,
Kent C. Dodds (14:49.144)
Hmm.
Sean Roberts (14:55.808)
recognizing where you're not the expert as well.
Kent C. Dodds (14:59.043)
Yeah, it sounds like there's just a really important need for balance in this. Like I do have things to share, I might be missing context and just recognizing both sides of that. Earlier you mentioned that like sometimes you want to prioritize things so that you're doing the highest value things first. What are some strategies that you've found to determine what the highest value things are for?
for some project where you are not the key stakeholder, like you're building something for somebody else.
Sean Roberts (15:34.009)
That's a good question. think it really depends. To me at the end of the day, I love computers. We were talking about this a little bit before. I love tech, I love programming, but I do this for money. My money comes from my company. My company's money comes from our customers. I think that it can be easy to kind of get disconnected from that sort of straightforward flow of, well, how come I can pay my bills?
Kent C. Dodds (15:56.376)
Hmm
Sean Roberts (16:01.038)
And so priorities for me are often who are our biggest customers? What are their highest needs? And have they told us those needs? What are we doing that is upsetting to them? What are we lacking that our competitors are not lacking? What are the market signals telling us about these sorts of things? So for me, priority number one is typically keeping the customers happy or doing what we need to do to acquire bigger customers. Now this is much easier.
If you are sort of a B2B type company and you can have direct access to customers and your income is not spread out over a zillion $10, $12 a month transactions, at that point it's a little bit harder to get straight answers about what the most important things are. I would say that's probably the number one way that I tend to prioritize things.
Kent C. Dodds (16:54.645)
I actually really appreciate that. And it goes in line with something else that you said I wanted to dig into as well, which was the business is your customer as a software developer and your goal is to help the business achieve its goals. This actually, I wrote a blog post a few years ago titled, how to get whatever you want from the business or something like that, business and engineering alignment, how to get what you want or something like that.
kind of the trick is to understand what the business mission is and do everything, like change what you want to be what's best for the business effectively. Or like if you can't convince yourself that what you want is what's best for the business, then don't bother going down that path. And instead, if you do decide, what I want is actually best for the business, now you've got to show the people in charge
that what you're trying to do is what's in the best interest of the business. And assuming that everybody's playing on the same team, then you will get whatever you want. So it's kind of a trick. But my question for you is how do you determine business goals? Is it just like, okay, well the business wrote down their mission and here's our values or whatever, we're just gonna push that forward. In your experience, is there...
a more formal way to go about determining what the best direction for the business is.
Sean Roberts (18:30.936)
don't think that there's a very formal way. Maybe there is. I'm not a very formal person and I don't work in corporate. We're not a huge company.
So there's not a lot of levels to it. I would say that my way of making sure that sort of I understand where we're going is, this is gonna sound like a broken record, but I try to talk to people. So I like to talk to salespeople, I like to talk to customer support people, I like to talk to various product managers. When I have one-on-ones with my managers or my skip levels, I like to talk about what's going on with them. I don't really talk about what's going on with me all that much.
Kent C. Dodds (19:07.853)
Hmm.
Sean Roberts (19:08.846)
at all. and I find that that's, this is a really good way. especially love talking to salespeople because they really want to make sales. And again, that comes back to if they're making sales, then things are good. so I love to make myself highly available to salespeople if they have questions about tech, or if they want to chat about something that's going well or not going well. and I think this is a great way to sort of figure out, what's going on in the company. if you don't have salespeople in your company, again, if, if you have a different.
sort of rev gen model. Then talking to the people who are closest to the money is often the best way to get an idea of again what's best for the business because at the end of the day that's why we're all here.
Kent C. Dodds (19:50.069)
Yeah, yeah, I think that is a fantastic insight and I want to dig a little bit more into that conversation. So like if we were to simulate or kind of role play that conversation that you have with salespeople or maybe support or whoever's closest to the money, how does that conversation go? How do you strike that up? Like especially for maybe a more introverted person who's just starting to get into
being more product minded. How do you get that conversation rolling and keep that channel of communication open?
Sean Roberts (20:29.742)
I think if you're an introverted person, salespeople are great to start with because they are very good at keeping their side of the conversation going. They are experts in the field of chatting. So I think that's a great place to start. A lot of the times it'll start with either I'll see that they have a meeting on deck with a customer that I think is interesting or that they have recently had a meeting on deck with a customer that I think is interesting. Again, for me in my current role, it's kind of easy. We work in sports, so there's a lot.
Kent C. Dodds (20:36.057)
Hmm.
Sean Roberts (20:57.504)
that I think are interesting. There's a lot of like dream customers that I'm just hammering them like, please, please, please sign my favorite teams. And so that makes it kind of easier to open the door. But a lot of the time I'll just say, hey, I see you have a meeting coming up with this person or I see you had a meeting with that. Did you have any questions or did they have any questions about the product that I can help you answer? Or who are they cross shopping with and what did they find that's different or better about the competitors that were lacking?
Kent C. Dodds (20:59.396)
Mm.
Kent C. Dodds (21:04.781)
Hahaha
Sean Roberts (21:26.862)
Is there anything that we can change or do or add to the roadmap that can help pull this sale through? And you can really glean a lot of information from that, especially from good salespeople who take detailed notes and kind of are aware of the competitive landscape.
Kent C. Dodds (21:42.009)
Yeah, I like that a lot. It makes me wonder though, if that is not the role of a product manager. if not, or I'm very interested in your take on that, but also once you get those answers like, yeah, they're comparing us to this other product and they really like this particular feature, which we don't have. Okay, now you know, like, okay, here's a possible feature that we could add.
that could potentially win us a new client or whatever. What do you do with that information? How do you get that into the hands of the people who decide priorities of what is being implemented? And how do those meetings go?
Sean Roberts (22:25.368)
That's a good point as well. I like to talk to our product owner on our team and sometimes other product owners on other teams as well. I think that can really help with roadmap. find that again, being the technical person in the room, you can get some say in roadmap discussions because you're needed for resource allocation, estimation, things like that. And so I think that's also a good chance to say.
Kent C. Dodds (22:45.263)
Mm.
Sean Roberts (22:53.74)
You know, I've been hearing a lot of people talk about X or Y or whatever it is, that, that they're interested in. sometimes it's just as quick as a Slack message. Like, Hey, I was chatting with this person in sales and they mentioned this has, is that on your radar at all? do you have 15 minutes to talk about it? And you can also say things like, I think we could do this pretty easily. which is something that I think a lot of product owners or product managers love to hear is, is the idea of, Hey, we can do this pretty quick.
Kent C. Dodds (23:20.619)
Yeah. And what I love about that too, is that not only are you bringing your perspective in the meetings where the PMs come to you with the requests, but you're also like bringing that, like those feature requests or those notes needs to the attention of the product owner or the product manager. And I think that some people are like, well, that's not my job. And I would say that the people who do the very
the very best work or at least rather ascend on the corporate ladder or whatever, however you wanna put that, are the ones who are not doing their job. Like they do their job, but they also do the extra stuff. So when somebody hears this and they're like, well, talking to salespeople, talking to support people, like talking to people, that's not why I got into this business. And I guess I would just say to that, like, yeah, but the things that you did get into this business for are being eaten.
Sean Roberts (24:08.354)
Hahaha.
Kent C. Dodds (24:19.341)
by this emotionless software engineering tool that yes, right now it can't do everything you can, it certainly can't. And we have no idea how long we have to go into the future before it will be able to do everything you can. But I do think that it is trending in that direction. And so finding a way to distinguish yourself will protect you from.
potential layoffs or not only that, like I really like going back to what you said. You like, you do this for the money. I think most of us do this for the money. Like we have to support ourselves. And so you should, you shouldn't really care, you know, provided that everything's moral, but you shouldn't really care about how the business is making more money and what you can.
contribute to increase the amount of money that the business can make so that you can take care of your loved ones and your coworkers and maybe even grow the business or whatever. And so I just wanted to push home the fact that just because it doesn't seem like your traditional software developer role to go talk to salespeople or whatever doesn't mean that you should just sit back and wait for the next ticket to implement.
I think it's actually really critical for software developers to push our experience and our, yeah, like the boundaries of our experience forward, but also assert ourselves into those conversations by having those, like starting up those conversations.
Sean Roberts (26:00.302)
I think it's always been important, but I think you're right. It's never, ever been more important from a purely self-interested standpoint to be doing this, like starting right now. And I think as software engineers, we've always had to learn new skills. There's always been the next thing to keep up with. It's never been easy. And so for some people, this will be easier than others. But chatting, talking, being social in that way is a skill that you can learn like anything else.
and one that's well worth learning. think I agree also we don't know how long we have until the LLMs are superintelligence or whatever. But even if it can't do everything you can do, if someone is convinced that it can do everything you can do, then fundamentally that you're in the same situation. And there are a lot of people telling that story right now that it can do everything you can do, even regardless of how true or untrue that is.
Kent C. Dodds (26:48.493)
Yeah, that's a good point.
Kent C. Dodds (26:56.047)
Yeah, I'll say as of Tuesday, May 5th, 2026, I will go on record as saying it cannot do everything that we can do as software developers just to be totally clear that that's not what we're selling over here. it is. It's really good and it's getting better. And it's exciting because ultimately the goal should be to make the world better and hopefully
the company that you work for is invested in that goal as well, to make the world, whether that be like something for entertainment or, you know, it doesn't have to necessarily like save the whales or whatever, making, improving people's life experience. And so we should be thrilled about the amount of time that we now have available to us to work on some of these.
product things because our time is no longer limited by how long it takes to implement a thing. I'm curious about your take getting more into the technical side of things. are the limitations for you currently? Like when you mentioned earlier, kind of in these conversations, you're using your trade-offs to be like, that solution is gonna be really difficult. Now the implementation is just getting so much easier and so much faster.
What are the current limitations that you are experiencing and when you're in those meetings saying, we really shouldn't do that because we're using MySQL and it's just really not good at that particular, whatever the case may be. Do you have any examples of times where you had to push back because it still is difficult to implement a particular feature?
Sean Roberts (28:42.306)
Yeah, I can't go too into specifics on things like that. However, yes, I think especially working in a company that's been around for a while with a lot of legacy code, there are places where things are just difficult decisions were made many years ago to set things up a certain way to have certain entity relationships a certain way or database tables are set up a certain way. And it doesn't matter how much LLM power you throw at the problem, things are organized in a certain way.
Kent C. Dodds (29:04.911)
Yeah.
Sean Roberts (29:11.906)
the trade-offs that came with that decision are there. and, that can make things more difficult. I've also, I've always loved, I think it was Ryan Florence who talked about legacy code is code that made money. So I, you know, I think a lot of people go, the legacy code. it's like, again, that legacy code, built this business and, you know, paid for this office and things like that. So, I try not to get too upset about it, but it can be more difficult as an established player with many years of code. I think the other areas, where.
Kent C. Dodds (29:20.814)
Haha
Kent C. Dodds (29:28.312)
Yeah.
Sean Roberts (29:41.465)
Things are tricky with the LLMs and where it's not the software factory, which some people are saying is when I sit down and code, which I still do mostly through LLMs, but even sometimes a little bit by hand, I find that the LLMs will still build us into kind of unmaintainable structures. And I still have to provide a lot of guidance about setting things up correctly from the start, sort of public private API decisions, things like that.
Kent C. Dodds (29:53.379)
Ha ha!
Sean Roberts (30:11.064)
the LLMs are still just not getting right out of the gate. And I think that's also something that when you've worked somewhere for a long time, when you've sort of lived long enough to see the consequences of your past decisions, you start to get a better feel for and you sort of know better than to just release the first version of something.
Kent C. Dodds (30:31.149)
Yeah, I have found in one of the nice things about having projects that you for whom you are the only user is that you can just ship slop and it's fine because if it breaks, you just go in and fix it later, assuming that you can afford the tokens. And so something that one of the nice things about doing that is I can just say, okay, let's accelerate us into the future just a little bit. And let's just pretend that we can just
trust so much to the LLMs and what direction does that take us in? And something that I found is that I end up doing a lot of migrations and that just like is a constant thing. you know, I didn't review this closely enough and now I can see that it was structured in this way when that makes it hard for us to move in this direction. And I can see that that in a bigger context with actual customers and stuff.
those migrations can be very painful, not just from the technical standpoint, but also from like your users are learning how to use your software and they don't want to change their workflows every day. as you're actively trying to serve your users the very best that you can and move, you know, with the accelerated pace that agents can move, are you finding that
to be a difficult thing to balance where users have to adjust for the new features that you're shipping to them.
Sean Roberts (32:03.96)
Deliberately no, and I think that's for the reason that you said We don't want to be shipping UI updates constantly moving things around constantly Especially like we're a very sort of strong workflow tool We are like a real-time live event tool So not being able to find the button that you're used to in the middle of an event is very frustrating for a user but I agree I think like if you've been online for any amount of time, you know that one of the number one sort of
Kent C. Dodds (32:16.847)
You
Sean Roberts (32:32.632)
Complaints that you'll see is when a big app changes its layout, right? People hate that. And so you don't want to be doing that to your users. It's not worth it. I think being able to get, I think there's a range of speed ups that we're getting from LLMs, right? You said like, if you're working on side projects, can just like, you can go F1 speed slop and you can just ship and ship and ship and it's coming out quickly.
Kent C. Dodds (32:53.825)
Yeah.
Sean Roberts (32:59.726)
But that's not the only way to get benefits out of these tools. can ship twice as fast, 175 % as fast and focus on quality and focus on maintainability or use the extra time, like I said, to maybe have a chat with someone in sales and make sure we're building the right things entirely. And you're still, if you had told us how far into this are we, if you told me in 2019, you're going to be able to do this twice as fast in five years, I I would be amazed. the idea, you know, don't feel like
because you're not going 10 times as fast now, suddenly you're slow because running 10 times as fast in the wrong direction is not necessarily the right thing to do.
Kent C. Dodds (33:38.575)
That is so, I wanna clip that. That is so good. We don't, yeah, don't wanna run in the wrong direction. It doesn't matter how fast you can go. One thing that stood out to me from what you said is stability is a feature. Or like you didn't say those words, but that like, that is very clearly a, it's a feature, especially for an app like yours where the only...
And maybe I'm inferring some stuff, but like the only time people actually use at least this part of the UI is during a live event. They're not gonna go and review it before the live event. This is part of their workflow, they're used to it every day. And if they're in the middle of a live event and it's changed on them, that's like really not good for them and that experience. And we can think of many examples where that's the case. It can be very frustrating. That said,
Let's say that that workflow has some pieces in it that are suboptimal and you want to improve those. How do you go about improving those features while avoiding breaking the feature, which is stability?
Sean Roberts (34:43.512)
Sometimes you do have to make a tough choice that something has to change. I think there's a few ways that you can do that that can ideally avoid upsetting people. And again, it depends on the scale of your business and whether you are serving maybe somewhere in the hundreds of customers who are all paying you a fair bit, or you're maybe serving in the millions of customers who are paying you not at all with their data, for example. And then you have different approaches here.
Kent C. Dodds (35:10.563)
Yeah.
Sean Roberts (35:13.35)
if you are lucky enough to have personal relationships with some of your customers, then you can talk to them ahead of time and you can talk to them about, the plans that you have coming. and you can, even if you're lucky enough to embed with them or get a screen share of their workflows, and ideally then you can say. We move some things around. we are giving you a heads up that we're doing that. and these are the specific problems that we know that you've had that that gets solved here.
I like to use feature flags very heavily. love to be able to, if I get an email that says, or we get an email that says, why is this different? Go, I'm so sorry about that. We'll turn it off for you for now. And we can come and revisit it. I think on a larger scale, you can do the same thing with feature flags and you can roll things out to users in groups. You can turn it on for 2 % of users and see how the metrics look.
Kent C. Dodds (35:44.013)
Yeah.
Kent C. Dodds (35:54.679)
Mm-hmm.
Sean Roberts (36:08.344)
get your answers that way as well. again, always it's so nice when you can just call them up and say, hey, what do you think of my new work?
Kent C. Dodds (36:14.755)
Yeah, yeah. Well, and also if you're actively talking to your customers and a particular customer is the one who asked for an improvement in that workflow, then you can feature flag them into it and say, hey, so we implemented this, we're gonna turn that on for you at your next event, just let us know how it goes. And that way you can kind of ease people into it. And then, okay, once those early adopters have started using it and it's now part of their workflow and they love it, now you can, and you've solidified the feature.
Now you can start opening it up for others and email people ahead of time and whatever to depending on the size of the situation. We all get those emails from bigger companies that say we're changing this feature and whatever, yada yada. And so I do think sometimes you do have to break a workflow to achieve the greatness in pushing that.
company mission forward and improve workflows. But I appreciate that you intentionally or deliberately, well, rather that you are deliberate about it. And I think that that is valuable.
Sean Roberts (37:26.094)
Yeah, I mean, it's fun to change things. I think a lot of software developers love to just make changes to their software. And if we're in it, you know, eight hours, 10 hours, 12 hours a day, every single day, then it can get stale and you can, you come up with workarounds and things like that. But you have to remember that your users are not the same level of expertise in your software that you are. They have other things going on and it's a means to the end, to an ends for them. And so.
Yeah, it's important to sort of exercise a little bit of discretion in doing those things. I will also say one of the most satisfying things about this job is getting that positive feedback when you've solved a problem that someone's had and you get that email, you get that phone call and they say, thank you so much for doing that. You just made our latest event or whatever it is. You made my life easier. It's like one of my favorite things to hear as somebody in software because I think that's
You know, that's the cool thing about software is making people's lives easier. so saving somebody time, saving somebody tedium, I hate tedium. so being able to save other people tedium is such a satisfying feeling in this job.
Kent C. Dodds (38:37.395)
I love that. And you're only going to get that call if you have that relationship as well, right? So develop those relationships people, it's good. So Sean, what are the things that you are hoping to improve in your own experience as a product engineer? Like what are the gaps that you see either in yourself or in others in product engineering that you feel like need to be closed for you?
Sean Roberts (39:06.488)
So I think I've really, like, I look back on what we've talked about, I've had a lot of vibes-based answers for you. I would like to be more data-driven in my approaches as well. I want better tooling to look at how the software is being used. I want better analytics and aggregations about my users. I would really like to have just a lot more numbers to back up.
what I currently use, is talking to people and then having vibes about it.
Kent C. Dodds (39:41.367)
Yeah, yeah, I appreciate that. That self-awareness is good, Sean. So I think you'll make it. So that's awesome. So as we wrap up, Sean, was there anything that we didn't talk about that you were hoping that we would get to?
Sean Roberts (39:55.713)
No, I think that's pretty much it. Thanks again so much for having me on and honestly, thanks for the years of education as well. I've been a big fan of yours for years. I was so excited when you invited me on.
Kent C. Dodds (40:06.073)
Well, thank you very much. I'd love to hear that. See, that's exactly what you just said when you have a customer say thank you. That feels good. So thank you, Sean.
Sean Roberts (40:16.664)
All the way back to your egghead advanced react patterns course. I've been a fan.
Kent C. Dodds (40:21.645)
Boy, that's like circa 2017-ish or something like that. That's almost a decade ago. Holy smokes, man, we're getting old. Sean, at the end of each one of these episodes, I like to ask the guest for a particular piece of homework that we can leave people with, something that you could write down on a notepad and check it off when it's actually done. So is there a book that you could recommend or a particular activity? Like go talk to your salesperson.
Sean Roberts (40:26.018)
Something like that,
Kent C. Dodds (40:50.541)
What would be one thing that people could do to improve their product sense of their product?
Sean Roberts (40:57.41)
What you said is exactly what I was going to say. Go talk to somebody that you don't normally talk to. Say, can I have 15 minutes with you and just chat them up? Ask them about their job. Ask them about the challenges. Ask them about the customers. If it's a salesperson, get to know somebody that you don't normally know in your day to day work. Get yourself a little bit outside of your comfort zone. And if you don't want to do it at work, just go talk to somebody in your life. Go talk to a cashier at a store. Talk to a server at a restaurant. Just go work that muscle.
because a lot of really important and great information lies behind striking up a chat with somebody.
Kent C. Dodds (41:34.551)
like that a lot, Sean. This is not a well-known thing, but when I was at BYU, I was really bothered by the fact that I would be walking around campus with other of my peers, and they were all just looking at their phones, and we'd never make eye contact. We're all people. So I just started saying hi to people, just interrupting whatever they were doing on their phone. And I started a club called I Say Hi.
Sean Roberts (41:52.014)
Mm.
Kent C. Dodds (42:03.321)
We got these like wristbands and stuff. was super fun. So I appreciate that Sean, just striking up a conversation with people. Sure, in the business context, that's good. But I agree with you that the muscle of being able to just talk with people, it is a muscle. It is a skill that you can develop. And so that's a great piece of homework. Thank you so much for joining us.
Sean Roberts (42:23.928)
Thanks. actually, I would love to tell one quick little story before we go, just related to that. So the agency that I worked in, I met the owner of that agency because I was a cashier at a toy store and he had two young kids at the time. And he would come in and I would chat with him. And so this is an insane like old man version of how I got my first job that will sound.
completely divorced from reality for any of your younger viewers and listeners. But I started working for him because he needed tech help at his largely like print agency. And I was a tech nerd who chatted with him at work. And so all of that came from just sort of striking up a conversation when I could have just rung him up and said, you later.
Kent C. Dodds (43:05.574)
Yeah, I like that. I could talk about stuff like that for much longer, but it's time to wrap this up. Sean, what is the best way for people to reach out to you if they have follow-up questions or want to keep up with what you're working on?
Sean Roberts (43:19.27)
I am on Twitter at Sean underscore J underscore Roberts. I am on GitHub. think I'm just Sean Roberts there. But I think Twitter is probably the best way to find me. am unreasonably active on there.
Kent C. Dodds (43:32.751)
I can relate to that. Awesome. Thanks again, Sean. And thanks everybody for listening and we'll see you in the next one. Bye. See ya.
Sean Roberts (43:35.413)
Hahaha.
Sean Roberts (43:40.994)
Thanks so much, Ken. Have a good one.