# Sketch the user journey and review systems - product-minded engineering with Drew Hoskins

An episode of [Become an Epic Product Engineer](https://invisiblenetwork.ai/podcast/1896782497), 28 Oct 2026, 47 min.

Audio: https://media.transistor.fm/7f5e9c41/549a7c9f.mp3

If you jump straight to implementation before you can explain the user journey, this episode is for you. Kent talks with Drew Hoskins - author of The Product-Minded Engineer, Senior Staff engineer at Stripe - about the otter metaphor, avoiding the Cthulhu effect in user interviews, and reviewing systems instead of diffs. They cover Facebook product-hybrid archetypes, Temporal and Stripe loops, the rule of three for generalization, and homework: sketch one feature's journey and hunt for plot holes. • (00:00) - Meet Drew Hoskins • (00:33) - The Product-Minded Engineer • (03:21) - Stripe and developer products • (06:11) - From compilers to product hybrid • (08:34) - Facebook archetypes and career turn • (10:57) - Temporal PM, then back to Stripe • (13:51) - Sketch the user journey • (16:13) - Balancing systems and users • (21:05) - Fire-and-forget codegen risks • (25:00) - Avoiding the Cthulhu effect • (30:43) - Puzzle approach to empathy • (33:28) - Rule of three • (39:43) - Review systems, not only diffs • (46:03) - Homework: sketch one journey Drew Hoskins (he also goes by Andrew) is the author of The Product-Minded Engineer. He started as a compiler engineer at Microsoft, built deep systems at Facebook and Oculus, founded Workflow Engine at Stripe, spent two years as a PM at Temporal, then returned to Stripe engineering after the book shipped - living the product-hybrid path he writes about. The through-line is product-minded engineering as a career shape, not a side hobby. At Facebook, Kent Beck's staff archetypes named "product hybrid" as a real mode. Drew doubled down instead of managing. The otter metaphor from the book frames engineers who play across product and systems. User interviews go wrong when you summon the Cthulhu effect - leading people into agreeing with your idea. Sketching the journey (discovery, understanding, usability, safe usability) exposes plot holes before you ship. They talk balancing systems thinking with user empathy, reviewing systems not diffs as agents write more code, deferred trust and conditional approvals, and the rule of three for when to generalize. Homework: take a feature you are working on, sketch its user journey in detail, and look for plot holes - how users find it, how they understand what it means, where the story breaks. Homework • Pick a feature you are working on. • Sketch the user journey in detail (discovery, understanding, usability / safe usability). • Look for plot holes: how does the user find it, understand what it means, and get through without getting stuck? Resources • The Product-Minded Engineer (O'Reilly) • The Product-Minded Engineer (Substack) • Drew on LinkedIn • Temporal • Stripe Guest: Drew Hoskins • Company: Stripe Host: Kent C. Dodds • Website: kentcdodds.com • 𝕏: @kentcdodds • GitHub: @kentcdodds • YouTube: kentcdodds-plus • Podcast: epicproduct.engineer See on Epic Product Engineer

## Chapters

- 0:00 Meet Drew Hoskins
- 0:33 The Product-Minded Engineer
- 3:21 Stripe and developer products
- 6:11 From compilers to product hybrid
- 8:34 Facebook archetypes and career turn
- 10:57 Temporal PM, then back to Stripe
- 13:51 Sketch the user journey
- 16:13 Balancing systems and users
- 21:05 Fire-and-forget codegen risks
- 25:00 Avoiding the Cthulhu effect
- 30:43 Puzzle approach to empathy
- 33:28 Rule of three
- 39:43 Review systems, not only diffs
- 46:03 Homework: sketch one journey

## Transcript

Kent C. Dodds (00:00.972)
Hey everybody, it's Kent C Dodds again with Become an Epic Product Engineer, and I'm joined by new my new friend, Drew Hoskins. How are you, Drew Drew?
Drew Hoskins (00:10.37)
Hey, I'm good. Thanks.
Kent C. Dodds (00:11.926)
Thank you so much for joining. so you reached out to me a little bit ago because you're interested in in product-minded engineers. And I also am likewise interested in this. And so I'd love for people to get to know you and why you care about this, and something like a little bit of your background, so you can give could you give us an intro to yourself, please?
Drew Hoskins (00:33.752)
Sure. so Andrew, I am the author of the book The Product Minded Engineer, which came out a few months ago with O'Reilly, and I am a software engineer who had a brief stint as a product manager. So I let's see, I started early in my career, I was a compiler engineer at Microsoft. I was very like hardcore. I loved algorithms and deep deep tech. And and then
Over my career, as I went from Microsoft to Facebook to Oculus to Stripe, I became more and more of a product engineer. or a I I I would say a product engineering hybrid. And that's really that journey is what led me to write the book. It was just like I had a before and after in my career where before I was sort of spinning my wheels and not really getting that far. And then once I
built some product skills, my career took off and I s wanted to get the word out about that and sort of what I learned along the way.
Kent C. Dodds (01:40.319)
Yeah, and having exposure to all of those different companies. I mean, Facebook and Oculus, I imagine were like relatively similar, but but it this probably helped you kind of frame the way that you think about engineering products. and in in particular at Microsoft, okay, you're a compiler engineer, you're you're like building things for other software engineers. and in st at Stripe, it's also kind of like.
building things for other software engineers as well. But Facebook and Oculus are like very much end user sort of things, I I imagine. I'm not sure n necessarily specifics of what you you built there, but I'm I'm curious if you found that product engineering is very different depending on the audience that you're building for.
Drew Hoskins (02:15.56)
Yeah.
Drew Hoskins (02:27.999)
so I've actually had developers as my customers like my whole career basically. And so I that's that's what I live and breathe. That's maybe the through the one through line in my career is always for developers. And funny that you mentioned that about Facebook and Oculus, because that's that ends up being why I left those companies, is because they were like the platform teams always felt a bit neglected. my best work at at Facebook was actually in developer productivity team do building tools for
For engineers within the company. in that role you could get tons of funding and they really deeply cared about developers being productive at the company, but for external developers it just wasn't really their thing. And so I'm like, I'm gonna go to Stripe where literally we're gonna get paid on every API call. And like, and then the company indeed cares a lot more about developers and I really feel like I found my people at Stripe.
Kent C. Dodds (02:58.891)
Hmm.
Kent C. Dodds (03:13.999)
Yeah.
Kent C. Dodds (03:21.97)
Mm-hmm. Yeah, tell me more about that. I I think Stripe has can kind of been the poster child for caring about the their customers, the developers, for a long time. I I worked at PayPal and the thing that I kept hearing about and this was a while ago, so maybe things have changed now, but the thing I kept hearing from people when I talked about working at PayPal was they would say, man, the docs for PayPal are the worst. Like the
The developer experience is awful, but Stripe, man, Stripe is amazing. I love it so much. and so what would you say like led to that level of care and and interest in the customer over at Stripe?
Drew Hoskins (04:01.985)
Yeah, that's a good question. so the founders, first of all, are just very like you users first is like our company tagline or something, like or it's like a big tenet of our culture. I think one of our principles is like build with craft and beauty. And the beauty there is more of a design angle, but the craft is really about like thinking through the edge cases and the interoperability. one of my
One of my for for maybe two years at at Stripe I was on this board called API Review, which is a sort of centralized review where you like somebody from API review will become a buddy for somebody who's trying to get an API shipped. And that API reviewer brings with them a lot of context, a lot of like how to do how to design an API, how to think through your user scenarios, and sort of shepherds it through so that you
You can disseminate that kind of knowledge about how to do this across the the org. So it comes from a combination of leadership, cultural practices like API review, interviewing, like the interview loops do touch on this kind of stuff. yeah.
Kent C. Dodds (05:17.088)
Yeah, it it sounds like it's like a whole culture that you have to build around activities that encourage caring about or doing things actively to care about that end user, which
Drew Hoskins (05:29.825)
Which is not to say that you can't make progress on it without your whole company being behind you, but certainly it helps if the company is is aligned.
Kent C. Dodds (05:39.285)
Yeah. Yeah. Yeah, that makes a lot of sense. now I think it's fascinating to me that in in a lot of people's minds, they would see that engineering, like compiler work deep into the bowels of engineering, would be about as far as you can get away from the product side of you know, the tent. and so it sounds like you moved from engineering all the way to product and then kind of found yourself somewhere in the middle at this point. tell me a little bit about that journey and and
Drew Hoskins (06:08.888)
Sure.
Kent C. Dodds (06:09.394)
W what are your thoughts on that idea?
Drew Hoskins (06:11.918)
So, as I mentioned, I started out as a compiler engineer and then in the C community, which was nobody's idea of like the most developer-friendly environment to be in. And but we started building a compiler framework. So, like an API. If you if you know what LLVM is, sort of a some similar to that. And it had not a very good API, but the C sharp community was doing a lot of
forward-looking work about scenario-driven design and design patterns and usability. And they were trying to beat Java, right? So it was like they needed to be more usable than Java. So so that community was doing a lot of good thinking. And I kind of tapped into that and tried to bring some of that over. So that's really how I got started was like I got obsessed with API design. And I really liked the like user empathy of it and thinking through user scenarios. And
I started finding API teams that I could join. I went over to Facebook and worked on their platform. The thing that I wasn't doing at the time was like using like I I I guess what I'd say is I was developing product skills in a further sort of narrow way of like, let's think about these interfaces and make them really good. But I wasn't yet applying that to like prioritization or other things that you would use product engine product skills for.
But at the same time, it was training. I was doing these design puzzles, and that was helping me empathize with users in a sort of structured fashion. And, you know, okay, so the what's what are the elements of the user journey, right? You've got discovery. Do I even know your feature exists and does what I want? Understanding, like, can I interpret your feature, understand how to use it, and then use it safely without doing things that I don't intend to do. And that that user journey, as I became familiar with that, I was able to start using that to like.
prioritize and think about and and make sure we were building everything we needed to build. And and so I I realized that I needed to not be so narrowly obsessed with design, interface design, but broad like, but use those skills more broadly to make sure we were building the right thing, align my motivation with the ma motivation of my manager and my company. And so almost by accident I realized that I had these like
Drew Hoskins (08:34.752)
Skills that could be used for more strategic purposes. So then, and that's really like it was really at Facebook where my career kind of took a turn where it suddenly hockey sticked, once I sort of like brought together these skills. You know, at the time, Kent Beck, who I'm sure you've heard of, and a bunch of others at Facebook, developed the system of archetypes. And they were basically like five kind of mo
Modes for staff engineers that they had seen be successful at Facebook. And the archetypes were coding machine, generalist, specialist, product hybrid, and fixer. And I had a chat with my manager, and he's like, Hey, I really think you're a product hybrid. Like you're very good at figuring out like what to do and why, and and so
You know, based on that chat, we found roles. I was already in a role that was good for that. We just like doubled down on that. I decided not to go become a manager. And and that was just like that was the magic for me. yeah, so then fast forward, I went to Stripe, as I mentioned, and then I left Stripe actually to write the book, the product which funnily enough, in a sort of a mirror of my career, it was gonna be a book on API design. And
I shipped it to I shipped an outline to O'Reilly, and they're like, that's kind of narrow. Like we we love your the main theme of your book, which is like user empathy and product thinking, but like this topic is a bit narrow. And I was like, you know what? You're right. And this is exactly the lesson I had to learn earlier in my career about how to apply my product skills. And so I wrote another outline, which became the product-minded engineer, and they loved that. And so to do a better job of writing the book.
I decided to become a PM. And so I went to Temporal Technologies, which is a durable execution platform. Again, still developers as my customer, but now I'm a PM. And I spent two years doing that and I really enjoyed it. But once the book came out, I realized, hey, I wrote this book called The Product Minded Engineer. I should probably go do the thing which my like book says to go do. And so now I've boomeranged back to Stripe and back to engineering.
Kent C. Dodds (10:57.194)
Nice. there are a whole lot of things that I want to ask you about some of that journey. so let's see. You you talked about the the user journey and you mentioned discovery and understanding. Are those can can you tell us more about that metaphor? And are those the only two parts of the user journey or or what is involved in that?
Drew Hoskins (11:00.89)
Ha ha.
Drew Hoskins (11:18.018)
Discovery, understanding, and usage. Yeah.
Kent C. Dodds (11:21.312)
Yeah, okay. So tell us a little bit like why does it matter or why does that framing matter and why should engineers care about the user journey?
Drew Hoskins (11:28.898)
Yeah. So it's so the like it's a sh it's basically a mental shortcut that you can use to make sure you're thinking of all the things you need to think about when you're building and shipping a product. And so and any one of those elements, if it's missing, your product isn't gonna work. And so it's a way to guide your attention towards the things that matter. Okay, so so stepping back, there's basically two I would call
indices indexes of like how should we engineers think about the world. And the one that I think most engineers are are familiar with is like the boxes and lines or like the system diagram. Here's the modules, here's the interfaces, here's the you know the databases. But the other index is actually based on time and people. It's like okay, a user is using my product and they do this and then they do this and then they do this and then maybe simultaneously a million others users are also doing X. And
And so effectively this time and user index, it's really just stories, right? I'm just making it sound fancy, but it's it's it's the combination of those two ways of looking at the world that need to be combined into when building products, right? We're not doing research, we're not doing and and we're not PMs. We can't just think about the user journeys. We are engineers, and so we have to think about the system as well. And thinking about both of those representations will help us.
Both address system problems that we can foresee and also address user problems that we can foresee. And so why is the scenario? So what I'm describing, I call a scenario in my book. And it's basically sort of like user does X, then the software responds with this, and then the user does Y. It's these user stories. So if you're ordering coffee, then it's going to take you through the steps of ordering a coffee. And what it's really doing is
Is directing your attention to what matters. You tell a story, and then each element of that story brings up an interesting point. So it's like, okay, the user is in a car commuting to work and they want coffee. Right. So now we have to think about okay, do we have voice commands in the car? can those voice commands actually be authorized to make a purchase? Right? Like, and then
Kent C. Dodds (13:32.554)
Mm-hmm.
Drew Hoskins (13:51.651)
we move on and it's like, okay, so they order it and then it has to be fulfilled and there's a workflow there. There has to be a payment element. And so this we tell these richer and richer stories and they're basically like a magnet for our our attention.
Kent C. Dodds (14:04.096)
Hmm. That's super interesting. It makes me think of jobs theory and the idea of like describing the situation in which you want users to to hire your product. it makes me wonder also, how do you avoid over indexing on these scenarios that are not real?
Drew Hoskins (14:25.836)
Right. That's where the system that's where the system view comes in, right? So if you if you just focus on these narrow scenarios, right, then that's not generalized. the scenarios end up being a really good way to communicate about things because we all learn stories growing up, right? Like we're just wired to think about stories. And so they're a really good great way of getting everybody in the same page. But at the same time, they aren't the only thing you need. You also need like, okay, how does this generalize into components, right? And what are the
the edge cases that we need think about. And so you kind of need the stories I I f I do early and I think they're they're pretty load bearing, but they're not the only thing. the other stuff though is stuff that engineers tend to already be trained about. Like let's abstract things, let's generalize things. Like one thing that I one one like common heuristic I use to decide whether to build a general version of something is the rule of three.
Probably heard of it. It's like basically I could build a very narrow thing, like, okay, I can order coffee, but if I have like three different drinks, if I can think of three different drinks I might want to order, maybe I want to order matcha or a ri a cooler, then okay, now I need a menu. I need this more general purpose, and I might change these drinks over time. So I need this like abstraction which generalizes it. And so the rule three is basically saying if I can think of three distinct use cases.
For some abstraction I'm thinking of building, there's probably more where that came from. And so I'm gonna build the general thing that like does all of them. But instead, if I'm just like, hey, actually this one coffee is really 90% of what we do, it's just like we just sell coffee, then we don't have to generalize.
Kent C. Dodds (16:01.983)
Hmm.
Kent C. Dodds (16:13.194)
Yeah, that makes sense. I and I think that it's good to be intentional about like making sure that you're not overbuilding, because it's easy to to look at something like the rule of three and think, well I can think of three use cases for literally everything. yeah, yeah, yeah. So that that seems like a really good rule when used judiciously.
Drew Hoskins (16:31.726)
Three high priority use cases, I should have said. Yeah.
Kent C. Dodds (16:41.104)
And that's exactly the sort of thing that I think a product engineer does a good job of is taking that systems design, systems thinking and marries it with like human issues, like the actual things that that people are dealing with. And I I appreciated when you said that your career hockey sticked when you started developing these skills in product engineering while you were still a pro like an engineer. So you didn't go into
being a a product person until temporal. And so that sorry, what
Drew Hoskins (17:12.578)
I did read Don Norman though. I d I did read the design of everyday things though. That was helpful.
Kent C. Dodds (17:17.332)
Yeah, yeah. That's good. And and if you're listening to this and you haven't listened to that episode with Don yet, you gotta go listen to it. It's good. but I wanna ask you like what were the specific things about starting to developing like develop a product mind as an engineer that caused your career to hockey stick it like that?
Drew Hoskins (17:40.451)
Yeah. so one thing I wanna like highlight maybe before slightly before we get to that point is I feel like when you say things like user empathy, it sounds to engineers like I have to go join human resources or something. Like I have to be some sort of empath who's like very weepy and I for me that that that that wasn't my entry point. I I came through it as a like, hey, these are puzzles.
Like I have an engine I have a user who's trying to use my stuff and like they're kind of like navigating a maze and I have to help them get to the end of it, you know. and so I I was able to kind of turn my puzzly brain toward that, and that opened up new vistas for me of like, hey, here's this entire class of things that I just wasn't thinking about before. And when when my career hockey sticked,
Basically, I had spent some time as an engineer at Facebook. And I moved down and I I built a a popular framework there called End Schema. It's still it's it's used by everybody today. And it it really kind of gave a step change in like productivity. It's sort of an ORM, if you know what that is. it was really a step change in productivity. And what I was able to do was take my experience as a
having been an engineer there for a couple years, and distill that into a few principles of like, okay, here's what users really want. Here are the scenarios that they're they're really having pain pain with. And really make about six decisions, six or seven decisions that ended up all being correct. And and then the the project just went like like grew like wildfire. So that was the
Kent C. Dodds (19:36.428)
And these were like technical decisions that impacted the product.
Drew Hoskins (19:40.227)
Yeah, so for example, like how do you do code generation? Right. So we were building a framework that was like so effectively the problem in front of us was we have a bunch of people are doing a when people want to build a new model, we call it the graph at Facebook, and it's like I want to build a user model or an event model or a group model or a newsfeed post model. there was tons of like toil and boilerplate about that. And
for example, I had to write the like the object wrapper around the database. I had to deploy the database configuration. I had to write the like mutation wrappers. I had to do documentation. I had to do it like all kinds of things. And it was just very toilsome. And so we we combined that into one schema that you wrote, and that schema would kind of generate all the other stuff for you. And that ended up being a general purpose platform for people to sort of reflect on our graph and do cool stuff.
later they built data migration framework on it and a bunch of other things. And so one of the controversial things was code gen. And everybody has feels about cogen, right? Like, code gen is bad, cogen is good, you should do com you could do should do code gen at build time and not check it in. You should do it when at development time when I'm like iterating on the schema. And like so, anyway, there's just like all these, there's also people who do.
Kent C. Dodds (20:41.611)
Hmm.
Drew Hoskins (21:05.432)
Cogen, what I call fire and forget cogin, where you just cogen at once. And then it's sort of like people start editing it and it diverges from like it may not even work, right? Because it's just like you ha you may have to make some changes to it before
Kent C. Dodds (21:18.09)
Right. Yeah. like scaffolding.
Drew Hoskins (21:21.238)
And so like we just thought about code gen, we thought about what people wanted. We made a few decisions. We made it that the code gen was signed and like had to be kept up to date. And we built something called partial code gen, which is like 99% code gen, but then you could actually go into methods and like fill out the implementation of these methods. And so for example, if you this this saved you a lot of boilerplate of like, I let's say I'm creating an email address as a field on an object, then I like
generate all the goo, but maybe it's a custom, it's got some custom logic in it. So I don't have to regenerate all that other stuff. I just have to like change one line. And so these sorts of scenarios of like, okay, it's really common for people to have like things that are like almost perfectly normal, except for this one little thing. And so then we give them this way to like do that without completely going out of cogin. You know what I mean? So it's like, and so that kind of like we saw that that was a really common scenario.
We handled it really gracefully and people loved it.
Kent C. Dodds (22:24.49)
Yeah, so it it's these six or seven product decisions that were actually technical decisions that you made that impacted the product that were driven by thinking through the the common scenarios, like exercising the like the the user journey and like thinking about things through that lens. Very cool. So s you you have this hockey stick growth experience, you leave Facebook in Oculus, you go over to
Drew Hoskins (22:30.028)
Yes.
Kent C. Dodds (22:53.984)
stripe and you learn more about what it means to make a really excellent product. And then you decide you you write your book, you decide, okay, I should or or you're in the process of that. and you decide to to be a PM to improve the the book. So I'm curious, since you've been across enemy lines, no just kidding. But no, but since you've been over there on that side of the fence and and have come back, what were the things
Drew Hoskins (23:07.64)
Yeah.
Drew Hoskins (23:13.966)
Ha ha.
Kent C. Dodds (23:21.44)
the and skills that you learned over there that have been really valuable to you as an engineer now.
Drew Hoskins (23:26.658)
Yeah. so let's see.
I think so I mentioned
That I spent a couple years as a Facebook engineer before founding in schema. That's a little bit cheating, right? Because you don't, when you're designing a product, like you don't usually get two years to just sort of like hang out and like figure out what it's like to be a user before you start building it. you need to fast forward that. And and so one of the things I learned, you know, at my time at Stripe as well as as a PM at Temporal, is like,
Okay, let's fast forward the like user discovery piece. Like, how do I actually learn the things, get the gain the intuitions from users very quickly that I had the luxury of like kind of learning over a couple years previously. So now I'm able to sort of accelerate my time to sort of user empathy versus what I could do back back then. and I mean I think user interviews is a big one. It's like how to get
The information that you need out of users. And one of the ways that I found most effective that like I feel engineers pretty much always do wrong is usually an engineer will lead a conversation with like, hey, we have this product idea. Like, what do you think? but you you're kind of I call this the Cthulhu effect because you're corrupting their brain with like your product ideas. And
Kent C. Dodds (24:58.858)
Yeah, yeah.
Drew Hoskins (25:00.024)
First of all, people love to be like, yeah, that sounds cool. Like people love to be agreeable. And so you're you're probab you're not getting so then what happens is like you've got some startup and you like ask a bunch of users about your startup and say, yeah, that's cool. I I would try that. And then you actually ship your your beta and then they don't try it. because you didn't actually like learn what their problems were and what really was their problem. What what was it?
Kent C. Dodds (25:19.402)
Yeah.
Kent C. Dodds (25:25.771)
Yeah.
Drew Hoskins (25:28.91)
problematic for you. And so like instead what you want to do is you want to like start in their their world. Like what are your problems? What are you facing? And the more they volunteer it without prompting, the higher the signal is. And then as you go through the interview, you can start to drop more comments of like, hey, like, okay, what about like, let's say you're you're trying to solve the problem that coffee is too hot when you people order it. You know, they don't bring it up
coff th their coffee is too hot. So then you're like, hey, what do you think about the like feel of your coffee when you like, do you ever, you know, you the temperature of your coffee, you start to lead them a little bit more. And then finally you like say, hey, we're thinking about like a coffee temperature monitoring device or something. Which obviously is ridiculous, but like the point is you the earlier in that interview that they bring it up, the more high signal it is. And then the more you had to prompt them to like talk about it, the the less the like
You can almost throw that signal away. and so yeah, that that was one thing was just like learning how to discover stuff from users more quickly. Another big one is like how do you how do you set up support so that you can be learning about your product as you give support to people? Right? Like how do you collect how do you collect feedback from your beta users? How do you
make it really easy to collect that f feedback so that they will give you the the feedback. and then like on a support rotation, like making sure that the team is understanding not just what the user's saying they want, but like why. Like if a user is like, hey, I want such and such a feature, or like this didn't work, digging into like, okay, what's really, what's the ground truth? What are they really hitting? What's their real concern about it?
Because their idea they're not a product designer, their idea for what to do is probably not right. what you really need to know is the ground truth. How what are their motivations and and like what are the problems they're really facing.
Kent C. Dodds (27:36.905)
I I think both of those, I can definitely see mistakes in myself and in others who have presented ideas for me. And and this seems to come up in the podcast quite often as this idea that engineers fall in love with solutions instead of problems. and we get really excited about this this API that we've designed or this you know, this feature that we put together or whatever, when it actually doesn't move the needle for the user or for the business.
And instead we should be focused on trying to solve user problems. Now what how how I I wanna ask, how do we avoid this problem? Because I I'm I'm facing this myself with a product that I'm working on and I do love my solution. And and this is actually particularly hard for solutions that you built for yourself and you're like, I am my own customer and I love my solution.
because it it actually solves a problem that I have. So I love the problem. I love the solution as well. and so now I'm trying to find customers or potential customers who share that problem space. And so how do you find those people without just leading them into your solution? because ultimately if if if they don't bring up the problem, then they're they're not your customer, and maybe that's fine, and you just need to find your customer. so anyway, this is a problem that I'm actively experiencing right now.
like I I guess I could sum it up as saying, how do you find your customers when your customers don't know they have a problem yet? Like it's not a problem that they feel, but once they experience the solution, they can't imagine living without it.
Drew Hoskins (29:00.749)
Yeah.
Drew Hoskins (29:15.714)
Yeah, that's a great question. I mean, that is that's like hard mode PM stuff, but I think one you know, one way is like looking at the data and slicing and dicing it in different ways. So if like you were in a coffee shop and like you have certain engagement metrics, you could maybe you've got a lot of churn, right? And people are like try once and then they go out, but they don't become habitual. you can slice and dice the data in different ways and then look for that.
signal in the noise of like, hey, like here's this problem that we've got churn. Now that's gonna like now maybe I'm gonna interview the users who have churned, right? And or or or or maybe I'm interviewing users who are in in week one, like right before they might churn, while I still have their attention. And I'm like, hey, how are you feeling about this? Are you gonna be a churner or not? And then I can figure out like how if if if my solution will keep them.
So it is it's hard if you're starting from scratch and you don't have like a captive audience. I haven't been to like a all my stuff that's been pre-product market fit has been like in in broadly has been stuff internal tools. So it's been much easier to kind of like interview people internally. It's it's so much easier, right? I haven't gone to like a startup and like bootstrapped it from nothing. But yeah, like looking through
Kent C. Dodds (30:21.182)
Right.
Kent C. Dodds (30:32.214)
Hmm.
Drew Hoskins (30:43.308)
Looking through like your your top of funnel, like you're like, hey, I've got a bunch of emails. Let me interview these people, entice them with something, you know, you might have to pay them or or whatever. but that data is super valuable, so it's worth kind of obsessing over and not skipping that step.
Kent C. Dodds (30:59.926)
Yeah, yep, that makes sense. so you do have a book. I wanna ask you about the book. it's the the product minded engineer. And I I'm just curious, let's define the title. what what does it mean to be a product engineer or product minded engineer and why should we care as software engineers?
Drew Hoskins (31:18.166)
Yeah. The mascot of the book and of my kind of online persona is the otter. And the otter is a very cool creature because it has both paws and flippers. And it's both it breathed it's a mammal that breathes, but then it dives underwater. And it also uses tools to like crack open shells and stuff. And so I think it's a very good metaphor for a product minded engineer because like under the water you can think of as like the system.
And like above the water is like the users and the the world, right? And they have they are adapted to that sort of in between environment of like right on the border of those two worlds. And I think a product minded engineer is somebody who who can go into product or into system but lives in that border.
Kent C. Dodds (32:09.576)
That makes a lot of sense. I I and I appreciate that too because a lot of people will are are worried that, well, like, are AI coding agents just turning me into a a product manager? I don't want to be a product manager. I would have done that if that's what I wanted to do. but having that capability to be kind of straddle both worlds, I think is really valuable. What would you say is the like the defining skills that separate a a PM from a PE? Like r like
Drew Hoskins (32:22.028)
Ha ha.
Kent C. Dodds (32:39.558)
What what is the distinction between the product manager and a product engineer?
Drew Hoskins (32:45.068)
Yeah, a product manager doesn't have the the system in index. They don't have the the boxes and lines in their head. And therefore they can't anticipate what are the important edge cases to think about. what are the risk areas, what should we build first, and like spend extra care on what should we build versus buy. they just don't have that representation in their head to be able to do that. I think an engineer tends to
be a little bit more focused on like needs to spend some more time deep diving into the into the system than a PM. And so focus is a big one. And let's see.
Kent C. Dodds (33:28.216)
Would you say that the like there are a lot of frameworks and and models for thinking about user requests and and user needs and and we talked about the user journey and and those scenarios. would you think that there or would you say that there are more frameworks and models for product managers to to use and and work on?
Drew Hoskins (33:28.246)
Kent C. Dodds (33:54.561)
Than what a product engineer should have to worry about as much. Like how much can we delegate that sort of strategic thinking over to the product manager? and and how like what are the tools that we have as at our disposal in like diagnosing problems and bringing clarity to that problem space as product engineers?
Drew Hoskins (34:17.058)
Yeah. so I think it is the more innovative and the more external facing your product is, the more likely it is that you're going to need a product manager to help. Because there's often like, or if not a product manager, like a user researcher, right? The more you're solving problems where the solution isn't known.
And the more you're dealing with people that like again, like it's it's just gonna take a lot of effort just to get the people to interview at the first place, then you're gonna need these more specialized roles. but I think for for engineers, there's a vast numbers of o of opportunities or even like smaller features that don't need all of that overhead and where engineers can really be in control of their own destinies. And
Kent C. Dodds (35:13.684)
Hmm.
Drew Hoskins (35:15.916)
Maybe you get the overall business, maybe you get the pricing or something from PM, but like you can do and the the very high-level sketch of of of what is done, but then you can fill out all the details. And so I think like the way I see the world moving is sort of like there's gonna be this software generalist role that's sort of the center of gravity, and they can do some engineering, they can do some product, and they can do all the medium difficulty problems solo, right? And
Kent C. Dodds (35:20.716)
Mm.
Drew Hoskins (35:45.539)
There will be problems, maybe like there'll be maybe one interesting thing where maybe they need a security specialist or an AI specialist or a product specialist or something to help with one piece of it. But the center of gravity is like the that software generalist. And so there's just so many things of that nature where it's i innovative, mildly innovative, or it's well well scoped, or I'm dealing with internal engineers, or there's just so many opportunities where the the engineer can just do all the things and
Kent C. Dodds (35:51.712)
Hmm.
Drew Hoskins (36:14.328)
totally be in control of their own destiny.
Kent C. Dodds (36:16.916)
Yeah, that that kind of goes back to Kent Beck Kent Beck's five modes of engineers. the I think the coding machine is kind of now that's the agent. Like and I I don't think that there's much room for the coding machine anymore. and e
Drew Hoskins (36:29.664)
In fact, one of the coding machine archetypes at Facebook, he said recently, Coding Machine is dead. He was like stabbing himself in the process of saying that, you know. And I felt a little sad but
Kent C. Dodds (36:37.708)
no.
Kent C. Dodds (36:44.308)
Yeah. Yeah. and then you also mentioned the fixer. I think that that actually could probably be just somebody running an agent as well. the I think like generalist specialist I think does stay.
Drew Hoskins (36:59.182)
I actually don't agree on the fixer. I mean, I think like the thing that a fixer can do at staff level is they can look over a broad area and find the things that are the most acute and then go fix those things. Right. So it's like that really that killer instinct, almost like a bloodhound, of like, hey, like this is broken and nobody's fixing it. I'm gonna go fix that thing. And for that, you really do need a lot of context to make those choices.
Kent C. Dodds (37:12.193)
Hmm.
Kent C. Dodds (37:20.012)
Mm.
Kent C. Dodds (37:24.672)
Yeah, I see. And and so maybe they're not actively doing the fixing themselves. Like they they're they're sending agents to go do the fixing, but they are th they're seeing the system as a whole and saying, you know what, we've got three primitives for this, but we sh really just need one. And let's combine those primitives and and get them talking to each other. So yeah, that makes sense. yeah, I I think it makes a lot of sense that things kind of do coalesce around to this kind of product hybrid
Drew Hoskins (37:40.376)
Sure. Yeah.
Kent C. Dodds (37:52.735)
Software generalist kind of kind of position. and this is the first time I've actually thought about the product manager's role is also becoming less scarce and and what they can do. And I I like you you can see this in smaller companies, especially where everybody at the company is wearing multiple hats, and as the company
company grows, eventually you realize, okay, I need somebody who's who can kind of specialize in one or the other. Like, okay, engineer over here, manager over here. And I think that just the the level of help that an AI assistant can give you, whether it be on the coding side or even even on like the the product management side, means that you can scale your business much further before you need to split those disciplines.
Drew Hoskins (38:25.688)
Absolutely.
Drew Hoskins (38:49.026)
Yeah, my my my company Stripe has been publishing they have a sub stack and they've been talking about the rise of the solopreneur. and and the Stripe data is showing there's this massive uptick tick of of people who are just like running a company by themselves, which is pretty amazing. What we're what we've basically done is we're lowering the minimum viable size of a company by leveraging AI. And I'm
Kent C. Dodds (39:03.916)
Mm.
Drew Hoskins (39:14.636)
I'm really excited about that. And it but to do that you would need to have a a mix of skills o of of the type that we're talking about, plus maybe a few others.
Kent C. Dodds (39:22.538)
Yeah. Yeah. Yeah. you can learn those on the job. Have fun. Yeah. well hey Drew, this has been a lot of fun to chat with you. Is is there anything that we didn't bring up that you were really hoping we would talk about today?
Drew Hoskins (39:36.676)
let's see.
Kent C. Dodds (39:40.756)
As Drew looks over at his index of his book.
Drew Hoskins (39:43.821)
I mean, I I think one thing people might be interested in is code review. I've been doing so I'm working on code review at Stripe right now, and I've been interviewing a bunch of people about like their code review experiences and how that's shifted in the AI age. And yeah, it's people are kind of it's become a like a new I'm I'm it's become a new bottleneck at Stripe and I think at many places. is that interesting?
Kent C. Dodds (40:09.514)
Yeah, yeah. I'll I'll I I'll briefly tell you kind of my my feeling on this, and then I'd love to hear your take. I actually just published a video on my YouTube channel about it's titled Stop Reviewing Diffs, Start Reviewing Systems. and instead of looking at the actual code, you have the agent generate what is effectively a diff of what the system looked like before and what it looks like now.
And for the vast majority of changes, it's actually the system doesn't change a whole lot. It's just piecing together different primitives to deliver on a particular feature. And for those, you actually don't need to review it terribly hard, especially as models get better. But then when we're changing primitives, is when you need to give it a closer eye. But in any case, you're mostly just reviewing systems. And maybe it's diagrams and maybe it's something else. But that's kind of my take on that. And that's the direction I think we're going.
Drew Hoskins (41:07.394)
Yeah, I I I I hope you're right. it does feel like and certainly that's in the air at Stripe as well as like, hey, should we be doing spec review? How to what extent does that replace code review? I think the to generalize that slightly, I think there's this sort of delegated tr or this sort of like referred trust. It's like, okay, I stamped this and then the agent went and did this.
And I'm sort of saying I trust them to do that. And this is coming up all the time. It's like, okay, with payments, I'm going to delegate the purchasing decision to an agent. I'm going to give them boundaries on like how much money they can spend. And I think this code review phenomenon is an example of that, where it's like, okay, what if I what if I approve somebody's diff or PR and I said, if you just do X, Y, X and Y, like this approval would carry forward.
like I'm I'm conditionally approving it if you do X and Y, and then I don't have to re-review it once you've done X and Y. And maybe an agent can like verify that you just did X and Y. And so there's all these sort of like deferred like like delegations that we want to be able to do for our agents, well without sh checking in tr untrustworthy code. another thing that's coming up is like test slop.
And a lot of engineers are not that used to reviewing tests very carefully.
Kent C. Dodds (42:41.117)
Because their engineers never made them in the first place.
Drew Hoskins (42:45.926)
and so now we have a lot of test slop and we have to like bring the code into we have to make sure that we're not just testing the code, but we're actually like asserting what the product should do. Right. And nobody's really watching the agent do that. Like no one's like the agent doesn't necessarily have all the product context. you may, depending on how well you conveyed it, they may or may not be able to do that. And so
Kent C. Dodds (42:58.953)
Mm-hmm. Yeah. Yep.
Kent C. Dodds (43:07.467)
Right.
Drew Hoskins (43:12.278)
If you see a lot of low-level unit tests that have like all these mocks and like are testing random crap, you know, spending more time reviewing the tests. And I'm really interested to see how like code review of tests evolves almost like as a separate, a little bit of a separate problem from code reviewing the implementation. Do we s do we stop in reviewing the implementations before we stop reviewing the tests? Like these are some of the questions that I'm currently asking myself, and I don't have the answers, but pretty interesting.
Kent C. Dodds (43:39.275)
Yeah. Yeah, I I don't I don't think I've published this video yet, but I I soon have a video coming out about how I delete tests every night. I ha I just have a automation that goes through and it says, Okay, here's our our testing principles and like go make sure that we're following those through everything. And the the thought is like, well, why don't you just make the agent do it the right way the first time? And the interesting unique thing about agents is that
Drew Hoskins (44:00.179)
that's cool.
Kent C. Dodds (44:08.938)
While they do have computer use and they can kind of simulate being an engineer and do like manual verification and stuff, it's actually better both for humans and for the agent to to like build out an automated test and that fails and then go and build the implementation and you get that feedback really quickly. but lots of times you don't want to keep that test around. like a a good example of this is like, well, we're removing this button from this page. Well, the agent is gonna write a test of
verify that button button doesn't appear on the t page anymore. But you don't want to keep that test around, because that it's just like a bunch of negative assertions everywhere. and so like I don't want to tell the agent to not do that because it's actually really useful in the development, but I'll have a cleanup agent come out after the fact. And that works pretty well.
Drew Hoskins (44:52.29)
Right. Yeah, absolutely.
You're I recently reviewed a PR where the the test I asked effectively I asked somebody to remove a feature and they removed a feature and then the agent decided to test it by asserting that the code the line of code that they removed was not in the file. I was just like, my god. so it yeah.
Kent C. Dodds (45:12.498)
Unbelievable.
Kent C. Dodds (45:17.556)
I I mean it passes, right? It's green.
Drew Hoskins (45:19.382)
I think the test was I think the agent was browbeaten into testing everything and it went a little too far.
Kent C. Dodds (45:24.698)
that's so funny. Yeah. Well, hey Drew, this has been super fun to chat with you. Thank you for spending some of your time today. what is the best way for people to learn more about you, learn about your book and and follow you and and keep up with what you're doing and and ask any questions if they've got them.
Drew Hoskins (45:36.578)
Yeah.
Drew Hoskins (45:39.97)
Yeah, sure. So depending on like your attention span or sort of what you like, we've got LinkedIn. I'm also on Substack, also called the Product Minded Engineer, and then my book is the Product Minded Engineer. Yeah.
Kent C. Dodds (45:56.094)
Awesome. Well, thank you so much, Drew. And thanks everybody. So before we leave, what is the homework assignment for everybody, Drew?
Drew Hoskins (46:03.308)
Yeah, so I think, you know, we talked about the user journey earlier, discovery, understanding, and usability and s and you know, safe usability. take take a feature that you're working on and just like sketch that user journey for that feature. and get into some detail about it, right? Like if there's a pl look for plot holes, like how does the user find it, or like how how did the user understand that
Foo meant what I meant, you know, what I was telling them that meant you so it's like, yeah, just like be skeptical of it and look for plot holes.
Kent C. Dodds (46:39.954)
I love that. Yeah, I think that's very easy for somebody to write down and know that they did it. So you all have no excuse. I can go and and get that done and that will make you more of a product minded engineer. And I think that makes our products better.
Well, thank you, Drew, and thanks everybody for listening. We'll see you all in the next one. Goodbye.
Drew Hoskins (47:00.825)
Thanks, Kent. This is great.

Shows are listed from Apple Podcasts' charts and directory, and Podcast Index where it is used. Every show and episode belongs to its publisher and plays from the publisher's own feed; this site hosts none of them.