#250 - Why Coding Alone Is No Longer Enough: Become A Product-Minded Engineer - Drew Hoskins

[00:02:02] Introduction

Henry Suryawirawan: Hello. Welcome back to another new episode of the Tech Lead Journal podcast. I have with me Drew Hoskins. He recently published a book titled Product-Minded Engineer. I think this topic is gonna be quite relevant in this AI age era. People are talking a lot now about being a product engineer, product-minded engineer. They’re kind of like similar. So welcome, Drew, to the podcast. I’m really looking forward to discuss about this so that we can help people to become much more product engineer mindset.

Drew Hoskins: Thanks for having me, Henry. This is gonna be really fun.

[00:02:35] What Is a Product-Minded Engineer?

Henry Suryawirawan: Yeah. So Drew, maybe let’s level set in the very beginning, right? Because this term has been coined for quite some time now, product engineer. I think even a long time ago when there used to be like a lot of scaleups, people started talking about product-minded engineer or product engineer in short. So in your definition, what do you think is product engineer?

Drew Hoskins: Yeah, my definition would be an engineer who cares at least as much about the what and the how as. Or sorry, the what and the why as the how. So what are they doing and who are they doing it for? And of course, they’re an engineer, so they need to figure, they have to, they need to understand the how, what, how they’re gonna accomplish it. But, you know, one way you can tell a product-minded engineer is when you ask them about their history of their career and they tell you what they built rather than say what technology do they use to build it? That’s a pretty good litmus test for who might be considered product-minded. It’s not an exclusive club. It’s not like you need some rare skills to be a product-minded engineer.

And it, and also I do wanna underscore the idea that infrastructure engineers can be product-minded engineers, right? Because everything is a product. Anything that you check into your code base, any function or class can be viewed as a product, right? It has an interface. It has users who are other engineers in this case. And those people have like usability problems. They have requirements. So anything really from the big to the small can be considered a miniature product. So you can bring these skills no matter where you are in the stack.

Henry Suryawirawan: I love how you define it very succinctly, right? So an engineer who cares about the why and the what versus just the how, right? Because I think techies sometimes we love our languages, our frameworks, and now it’s like AI tools that we use. But also cares so much about the why and the what that they build, right? So I think that’s a pretty nice definition.

So you mentioned a lot about, you know, the build itself, right? So the product, does it mean that if I work in a consulting or if I work in non-product, you know, companies, can I still be a product engineer?

Drew Hoskins: Well, in consulting, I mean, you’re actually even more of beholden to the needs of the people that you’re consulting for. So you have to have a lot of awareness of your users in that case. I certainly, like personally, I enjoy the challenge of trying to build a product for many different users. That’s one of the fun parts for me. So I probably wouldn’t be a good consultant. But yeah, absolutely. I mean, you know, just a few users or millions of users, like in all of those cases, product skills come into bear.

Henry Suryawirawan: Right. So this term, I think we, we should clarify. It’s not just specifically for engineers who work in a product companies, right? So no matter where you are, I think you can still, the mindset, the what and why, right? Coming back to what you said, I think is important in what you do.

[00:05:37] What Did Drew Learn Working at Microsoft, Meta, and Stripe?

Henry Suryawirawan: So I think for, you have been around for quite some time. You know, you have been in a different companies. And actually when I look at your history, I think you are kind of like perfectly suitable to write this book. So you have worked in Microsoft, you know, Meta, Stripe as, last is like a senior staff engineer or something like that, right? So purely IC. And then recently you moved into product management which is like becoming a product manager. So tell us a little bit more from learnings, from your learnings in these great companies. And then what actually you meant by, you know, switching to product manager now. Are you still doing some kind of engineering thing or are you just purely a product manager now?

Drew Hoskins: Yeah, sure. I’ll start from the beginning. So I started at Microsoft on a compiler team. I was like “hardcore”, you know, I double majored in math. I loved algorithms. You know, I was very much into the how. And I ended up working on this kind of compiler framework that was ill fated. It didn’t make an impact. But the chief architect’s vision for the framework was to be the Assembly language for people who wanted to build compilers or jitters or other tools. And my thought was who wants to code in Assembly language? Like I don’t, like I didn’t like the vision. I thought like all of our APIs were really hard to use. But the C# community was doing really great work on API usability at the time. And so I started doing some work on my team to kind of bring like a us- like an API usability mindset over to, we were actually at C++ code base. And so like, hey, let’s like import some of the good work and thinking that’s like being done in the C# community over to C++. And that’s how I kind of, that’s how I got the API usability bug.

I wanted to write APIs that made other people really productive. And then I switched teams over to Windows and I worked on this another API team were like, I’m gonna date myself here, but tablet PC. It was like an inking interface, you know, APIs for people who wanted to build like tablet applications. And I did a usability study. And back in those days, it was actually like a one-way mirror, like where I sat on one side and they couldn’t see me. And I watched them code. And it was like the most humbling experience I’ve ever had in my life because they struggled to use my prototypes. I mean, it was painful and it was a big lesson, but also, like I’m very attracted to difficult things. So I thought, oh, well this is a really, this is way more interesting than I thought, like this whole design thing. And so that was a humbling experience and really taught me that I needed to connect with my users more. And even though I was interested in usability and in product thinking, I wasn’t there yet.

So then at Facebook, I think the thing I learned at Facebook was to be more entrepreneurial and to prioritize my time better. Because I was used to being given more tight like, hey, here’s what you should go do. But at Facebook, Facebook was very much about this. This is, I joined in 2009, it was very much like distributed autonomy, not a lot of consensus building. You just go do a thing, you know? And you have to be very good at prioritizing your time or you’re not gonna get… And my first couple years, frankly, I kind of struggled with that. My projects were hit or miss because like I didn’t necessarily have a really good understanding of what the impact would be. And so this started to teach me that, hey, like product thinking is not just about usability, it’s also about like what do users actually want in the first place? And like what’s the best way to, like what are the things that are gonna make the most impact?

My biggest claim to fame at Facebook was I founded this company called, or this, this project called Ent schema, which was like a really powerful ORM and sort of development platform for modeling our data. Like our graph like users and groups and status updates and photos and all those things. And it was like a huge step change in productivity for the company. And in that journey, I was a former, like I was, I moved down the stack, so to speak. Like I was a developer at Facebook and then I became somebody serving developers at Facebook. And so I had a lot of empathy for that role because of my couple years of experience.

And so then around this time as I’m working on this project, they developed this system of archetypes which were five kind of staff level roles that they’ve seen engineers be successful with at the company. And the archetypes were a generalist, a specialist, a fixer, a coding machine which is somebody who’s just very, very productive at churning out code, and - which I guess Claude, Claude Code is like a coding machine archetype frankly - and a product engineering hybrid. And I was considering going into management, ‘cause like, you know, I was senior now, and of course at some point you’re supposed to figure out whether you’re like gonna go to management.

And my manager was like, no, look like there’s this archetype which you seem to be, which is a product engineering hybrid. And if you just keep doing what you’re doing, like you, you’re gonna go far. So he helped me understand like sort of what my niche was at a company where, you know, in the early days, it felt like you had to be a coding machine. Like that was the, like all the most wanted engineers were coding machines. And that was never me. Like I wasn’t somebody who just churned out a lot of code. And so like learning about these archetypes and finding that there was a role for me really accelerated my career. And also just my impact of just understanding who I was and how I fit into the scheme of things.

And then when I moved to Stripe, I think the thing I learned at Stripe was being more collaborative. As I mentioned earlier, Facebook is a very like distributed autonomy kind of company. Not a lot of consensus building, at least back, back then, and lots of experimentation. But whereas at Stripe, it’s more, it’s a like… Stripe builds developer APIs for moving money, which have to be pretty rock solid. And so there needs to be a lot of concensus building. There’s a lot of document writing and so you get a lot of people who are at Stripe, who are very producty, first of all. Like Stripe has done a great job of hiring product-minded engineers. And secondly a lot of people were very collaborative. And so I became a much better collaborator at Stripe.

And then, you know, finally, I moved to Temporal Technologies, which is like a durable execution platform or you could think of it as a workflow engine. And I was, at the time, I was, I was writing the outline for the Product-Minded Engineer, the book that just came out with O’Reilly. And I thought, well, and I had been a customer of Temporal and they reached out to me and I was expecting them to reach out and ask me to come be an engineer. But they reached out and asked me to come be a PM. And they needed somebody who like was a former developer who really understood their customers, who are pretty technical folks by and large. And I thought, you know what? This would be a fantastic way to like deepen my product chops so that I can then do a better job writing the book. But I didn’t know whether I was gonna get the book deal at the time. So it was a little bit of a leap of faith, but then the deal came through. So, so yeah, so I’ve been a product engineer for a couple years now. I mean a product manager for a couple years now.

Henry Suryawirawan: Right. Wow. I think, I can see the kind of like learnings that you had in all these companies, right, that brought you to your current role now. So I think the, a few theme that I like to call out. Like for example in the beginning you learn about, you know, product thinking, usability of the users, right, using your product. And then at Facebook, you learn about entrepreneurial thing and, you know, autonomy and impact, right? I think that’s kind of like also important as a product engineer. And being collaborative at Stripe, which is, now you’re doing a the product management itself, right?

[00:14:13] What Are the Biggest Challenges When Switching from Engineering to Product Management?

Henry Suryawirawan: So I think when you did the switch, what was your biggest struggle, maybe should I say? Is it like not being able to produce code more or like what kind of things that you struggle in the beginning when you switch to product manager?

Drew Hoskins: Oh, in this last couple years, you mean at Temporal? Yeah. Well, I mean, okay, so I did take a downlevel to become a product manager which I was happy to do. I mean, I think I was recently interviewing a bunch of people who’ve transitioned to the product manager and, you know, the advice is like, look five to 10 years out. Don’t like think of a down level as like a career setback. ‘Cause you’ll get back, you know, to the level that you were. And so yeah, look, five 10 years out when making these transitions. And so that was fine. I was okay with that.

I think like as far as the actual behaviors I struggled with, I mean, I, one thing is when you’re a product-minded engineer among engineers, there’s a default, there’s an amount of clout that you get because you’re an engineer on the engineering team, like you’re a tech lead. And so people, I found it easier to lead from that position. As a product manager, I’m in a different org from the engineers. They don’t necessarily know who’s this guy who’s like asking them to do things. I’m not the one who’s gonna have to be on the hook to build the thing that I’m advocating for.

And so I find that I need to show my work more. Like I have to actually like show the user quotes of like the people who are asking for things and like be more detailed on like the scenarios that I write and just, you know, really provide more supporting evidence for what I’m saying because there’s a little less default built-in trust. And also I’m not just influencing engineers, but I’m also influencing the go-to-market teams and other folks around the company. And so just the stakes are higher. And so yeah, showing my work is like the biggest thing that I’ve had to, you know, being more rigorous about that. And even if I already kind of know the answer like of what we need to do, I go ask users and then like, and maybe I’m wrong and maybe they’re correct and they show me something that I missed which often happens. Or even if I was right all along, I still have that data that I can show how the product should work.

[00:16:33] What Skill Gaps Hold Engineers Back from Product Thinking?

Henry Suryawirawan: Right. I think from my experience as well, looking at these type of engineer, right, product engineer, I think I can see, you mentioned a couple of things, right? Like being able to influence, I think, that’s kind of like very important because not just influencing within the engineering team but also to the users, the stakeholders, the partners and all that. The second thing is, I think they’re always around in meetings. You know, people ask them to join just because they have a breadth of knowledge and, you know, not just the technical skills, but also the non-technical aspects as well. And they care about the users, right? So maybe sometimes we can see it when they draft, you know, the ticket, right? The issue that they’re working on, they will put more things beyond what the PM has written, maybe or beyond just what the engineer has written, which is typically just one or two lines. So these are some of the traits that I see. So maybe from your observation as well for people in the industry, at your side, what are the skill gap that are still kind of like missing, you know, for an engineer, a pure engineer, a techies who want to become a product engineer more?

Drew Hoskins: Yeah, I think for me the, I would call it the fundamental primitive of product thinking is the user scenario. And so what is that? I mean, it’s basically a story about, you know, the way that engineers are gonna interact. Or sorry, the way that users are gonna interact with your product. And so, if you’re just like in a conversation with like a staff level engineer, you’re gonna hear them talk about, well, what if this happens and then this happens, right? And they’re going to tell little stories in the conversation that are gonna ground the conversation in something interesting. And that’s something that product-minded engineers are like you have to be able to do that. A story would consist of a persona or a person who’s doing the thing and then they have to have a motivation for why they’re using your product. And then a sequence of steps that they go through as they use it.

And so, you know, maybe a pure engineer, infrastructure engineer or like some other level engineer is gonna start with just thinking like, let’s say, you’re working on a coffee ordering app, right? And they’re gonna think about the like click the pay now button or something, right? And then they’re gonna design what’s inside of that, what happens when you click the button. But that’s just one very narrow window in the story, right? So what happens first? Well, first they had to like select the item and they had this whole ordering flow that they went through. How do they even get to the, to that in the first place? And then you start to think in terms of the conversion rate of that flow. Like how much, how well are users proceeding along that journey to get to the actual purchase button, which is what you want them to do? Maybe you should be catching state from previous interactions to speed up, speed it up. And so you start thinking about this these like, you start simulating out what the sequence of steps that users are doing. And that’s the simulation aspect of the story.

But then also tell me more about the user. Like are they repeat customer? Have they ordered this before? Well then maybe you’ve got some sort of favorite system that you’re providing, that help them reorder things that they’ve reordered in the past and cut out a lot of those checkout steps. And then, you know, you start thinking more about the customer’s situation and empathizing with the customer more deeply. Like maybe that customer is actually on their commute and they’re gonna pick up their coffee on the way to work. They’re in the car and like they’re trying to interact with your multi-step checkout flow while driving, which is not safe.

And so, you know, as you kind of become more and more product-minded, you start flushing out these stories and making them bigger and bigger. And then by the end, you’re thinking, okay, well actually what about voice commands? Like what maybe we integrate with, voice. And we, now you’re looking up the Siri Kit SDK, and like trying to figure out if you can integrate like cheaply integrate voice commands into your app. And so, so that’s the sort of like in just getting out, like zooming out and getting more context, using the story as a way to guide you through that journey of like, okay, I’ve got a tiny little story, what happened before, or what’s happening next? And then who is this person and why are they doing it? And so you’re just kind of like adding more fluff to the story until you’ve like covered what you need to cover to make a good product.

[00:20:56] How Do You Bridge the Communication Gap Between Engineers and PMs?

Henry Suryawirawan: Yeah, to me that kind of like sounds doable, right, for an engineer who wants to have more product-minded engineer mindset, right? So it’s like understanding the user stories, the user journey. Some people also say that, right? Understanding the persona, the impact, how they’re using your products. But for some engineers, they will think this is the job of product manager, right? So, what they expect is like, okay, they do the this kind of a story, you know, scenario and all that. Then they will write a ticket for me and I’ll just, I just try to understand from the ticket and implement that. So what do you think the challenge of this, because I can see so many, how should I say conflict or misunderstanding between product and engineer simply because of this. So do you have any experience on how to handle or navigate this kind of conflict?

Drew Hoskins: Yeah, no, you’re absolutely right. I mean, there’s those of us. So I’ve been in a bunch of teams where I didn’t have a PM because I was doing like developer infrastructure, right? And so it’s like, okay, you’ve got to be a product-minded engineer because like or someone in your team needs to be, ‘cause there’s no PMs in that. And then when I have had a PMs, they’re often very busy and they don’t think in the level of detail that is like there’s a lot of product decisions to be made that are kind of underneath the level at which they understand and that a lot of that comes from your knowledge of the system that they don’t have. And then the communication is very painful between like a product manager who’s only thinking in terms of the product.

Imagine like, it’s almost like speaking a different language because the engineer, their brain is indexed around the system, right? They’ve got like the system diagram in their head. They have the UI mockups and the relationships between the different UI screens. And then you’ve got the product manager who’s only thinking in terms of like the user stories and the timelines of like, okay, the user does this and then this and this and this. How do you communicate with somebody whose brain is indexed entirely differently than yours is? It’s very painful.

And so having a person who has both indexes in their head, even if they may be the, not the, you know, you may not be the deepest database expert, but you maybe know enough about the database to know that like, oh, indexing is a thing that I need to do. Then you can identify that non indexed, you know, reads are gonna be a risk, right, based on the scenarios that the PM has brought or the ones that you figured out. And so the PM may not know to focus on like the scenarios that are gonna be scalability problems, whereas, you know that. So it’s really this combination of skills that’s like incredibly powerful. Even product managers that I talk to who are formerly engineers are like, oh, I use my technical skills all the time in my new role because they just understand that’s it’s that combination of like two indexes in your brain that’s so powerful.

I think like an early way to develop these skills is to write scenario tests. And so maybe you’re used to writing unit tests which are like, I’m gonna exercise some tiny little piece of functionality about my product. But a scenario test would be a test where you are actually like writing down a user scenario and then going through those steps. Or maybe you’re writing a test that’s just very, very likely to occur in production because that’s what users, you know. Like if your homepage has a default query of your database, like maybe your Netflix, and there’s like the homepage query is the thing that’s gonna happen all the time. Then you write a test for that scenario, right? And so upleveling yourself from writing unit tests to writing scenario tests is a really good way to practice your product skills. And if you don’t know what the scenario is to write, then go talk to your PM and say, hey, like I’m writing tests and I’m not sure. I’m writing scenario tests, I’m not sure exactly which ones are the most important. And start asking them why or start asking them like for more context. And then you’ll build that muscle.

Henry Suryawirawan: Yeah. So I like your analogy just now about two different indexes, in, you know, the people’s mind, right? So one is indexed more for, from like architectural, maybe system level while the PM is indexing more on the, you know, user journey, the impact and all that, right? So I think that’s kind of like a good analogy that I haven’t heard before. So I think for engineers who are still struggling, like what do you mean by, you know, different mindset so this is one analogy that I think we can use. So I think writing scenarios is…

Drew Hoskins: Oh, sorry. I was just, in my book, I call it the great re-indexing because basically like when you’re developing a product, you start with the user journey and then you go to the system and it’s like a kind of a bit of a process to get from one to the other. You know, it’s actually, that’s the great art of software engineering really is basically just re-indexing.

Henry Suryawirawan: Yeah. So I think this is also something that we can use practically, right? So whenever we are in the, like for example in the non-engineering discussion, we have to remind ourselves, switch our index. Use the other brain, probably, the other parts of the index to actually, you know, talk more rather than, you know, still at the architectural system level.

[00:26:07] What Are The Four Pillars (Double Diamond Framework)?

Henry Suryawirawan: So, yeah, writing scenarios is definitely something very easy, practical for engineers to step up, right, in terms of having product engineering mindset. But in your book, you also kind of like cover like four different pillars, right? You mentioned about Develop, Deliver, Discover, and Define. I think this framework is, I feel is very, you know, strong, so that people know what is the roadmap for them to improve or increase their product-minded, product mindset, right? So tell us about this framework. How do we actually use it and what do they entail, actually?

Drew Hoskins: Yeah. So this is called the Double Diamond Framework. And it’s a process framework. So it’s not a process, it’s like a way of thinking about process, right? And the four stages are Discover, Define, Develop, and Deliver, as you said. And it’s called double diamond. Picture two diamonds like side by side, right? And so like, you’ve got your first stage is Discover, and that’s a very like opening up phase, right? You’re looking all over the place to figure out what the heck you’re gonna do. And then you are talking to customers, figuring out what the problems they have. And then you go to the Define phase, which is like defining the product you’re gonna build that will solve their problems. And that’s like a convergent phase because you’re trying to like figure out exactly what you’re gonna do based on the things. And then you get to the how stage, which is like the Develop stage, which is like, okay, now let’s explore a bunch of different ways to solve, to build that product that we did. And that’s when we’re refactoring, starting to play with different database, architectures and, or depending on your domain, you know, whatever technical challenges that you have. And then it’s finally Deliver, which is again, a narrowing phase where you’re starting to polish and test and get it out to production and experiment. Or and like do, like to do your like, metrics and A/B tests and stuff like that.

And so what’s interesting about these, what’s most interesting about these phases is, first of all, like the thing I see engineers do the most often that’s a mistake, is they jump to the Develop phase, right? So they start building something. Is it the right something? Maybe, maybe not. They’ve kind of skipped over the Discover and Define stages and jump straight to the solution. And then they start deciding, you know, which… And sometimes they even skip all the way to the Deliver phase and they just have a solution and then they just like write that and then they ship it. And so I would say, first of all, like yeah, make sure you’re building the right thing because, you know, there’s a high cost to, you know, you’re wasting your time by building something that’s not gonna make an effect.

And then I think the second thing is, like I get into a, I see a lot of arguments where one person is like trying to just get the thing shipped and the other person is still trying to explore different solutions. And you get these arguments and people aren’t really saying that, but that’s what you can tell that they’re just sort of in different, mentally in different phases in the double diamond process. And so if you can, if you notice that you’re having an argument with a coworker about, of this nature, like you’re impatient or they’re impatient, check in on like, hey, I’m in the Develop phase. It sounds like you’re in the Define phase or whatever. And a good way of resolving this tension because then you can have an explicit conversation about where you are in the roadmap. Even if you don’t have some grand process built around these four phases, you can still kind of use it day-to-day.

[00:29:43] Why Should Engineers Care About the Deliver Phase?

Henry Suryawirawan: Right. So I totally understand when you mentioned developers or engineers tend to jump into Develop, right? So simply like from the industry, I, what I can say is like, they’re waiting for the PM to kind of like discover and define the thing, you know, the ticket for them to work on, they develop. And not only that, they stopped there. So the, what do you call it? The dis… sorry, the Deliver phase, right? So at the end, they also don’t care so much about whether, you know, the features they build are used, what kind of metrics. You know, what’s the user journey like after using the product. So tell us about the importance of this Deliver aspect as well, because I think sometimes it’s really missing from engineers.

Drew Hoskins: I agree. I agree 100%. And I think the biggest thing I see people miss is discoverability. And so there’s a sort of, you know, we mentioned scenarios earlier as like stories that you tell. And a very classic user scenario starts with discover and then understand and then use, right? So first of all, they have to discover your feature. They have to figure it out, and then they have to actually use it safely to accomplish their goals. And I see people make mistakes in all three of those pieces of the user journey. But one of the more classic ones is the discovery where it’s like, hey, I’ve got my feature, but like nobody knows it exists and they don’t find it. And the engineer isn’t necessarily thinking in terms of that kind of like growth hacking mindset of like, how do I get people using my feature? But the thing is, you can add a discoverability hack that’s just gonna 10x the usage of your feature at like a 10th of the cost of building it, right? And so it’s often an extremely high leverage thing to be doing to, you know, like okay, you’ve got an error message. And like the solution to your error message is to use your feature. So like tell them, tell the user about your feature in the error message as it’s a very simple discovery mechanism.

So that’s a classic. And yeah, a lot of those things get driven during the Deliver phase when you’ve kind of got the core thing built and now it’s about putting in the context of like the rest of your product and making sure people find it and then making sure that it’s safe and then having the metrics feedback to then understand whether it’s making the impact that you hoped. And also, like, you know, tracking metrics is huge for, you know, your career as well. Because if you can show the impact that you’ve made, it helps your manager understand what you’ve done.

Henry Suryawirawan: Right. So, yeah, definitely tracking metrics is very important, right? So, and especially because when you want to track those metrics, you kind of like need to put the instrumentation, the observability aspects into your solution as well, right? ‘Cause it’s not so easy to get a metrics if you just deploy it and put it out there, right? So I think, this also comes back to how you develop the stuff as well.

[00:32:40] How Should Engineers Apply the Double Diamond Framework Day-to-Day?

Henry Suryawirawan: So I think, what I think you are trying to say is like this framework exists but we are not asking engineers to be good in all of them, right? But at least know some aspects of them, be part of the discussion, you know, in order to shape the feature much better. How do you think the engineer should think about now you have these pillars now? Do I need to always be involved in all different phases when I build a feature? Or like tell us practically, how do you use this framework in our day-to-day life?

Drew Hoskins: Yeah. So if you are, if you don’t have access to a PM, then would need to be involved in all four phases. If you do have access to a PM then, I mean, I personally get involved in the Discovery phase anyway because I enjoy it. And I also think that you can help the PM narrow down the possible solutions. Like there’s no point in the PM going and asking users if like, would you like a trip to Mars if you can’t get them to Mars, right? And so like helping narrow down the options and helping the PM focus their efforts on what matters is a role for an engineer early in the Discovery phase. And then starting with the Define phase and on to Develop and Deliver, the engineer’s gonna get much more involved. I personally, have things I enjoy about all four areas, so.

Henry Suryawirawan: Yeah, so thanks for that addition, right? So I think narrowing options itself, knowing what is the possibility to build. Because for example also if you work on legacy product, right? You know, the challenges, the constraints, you know, with the current architecture, the current system. So you kind of like know what options that the PM has, so that you don’t fight in the end.

Drew Hoskins: One of the ways that I will get involved in the Discovery phase as an engineer is I’ll like ask the PM or the sales person or the like solutions architect or, you know, the forward deployed engineer or these sorts of people. Like, hey, can I tag along in your meetings or can I read the, can I watch the trans, video transcript or whatever? And really I’m just kind of immersing myself in what the humans are, that are using my product are doing, which is gonna help me make decisions later in the project when the PM underspecifies things, right? Or when I have insights based on my knowledge of the system that I can combine with that information. And so there’s some pretty high leverage ways. You could have an AI now go and find out all the user context for you. Like, hey, would anybody like this feature that I’m thinking about building? And then just have like a LLM go and search for anybody that they think would be interested. And then now you’ve got some leads to reach out to, right?

And so like it’s actually pretty easy to, and relatively low work to just tag along with some of these other roles as an engineer. Sometimes you can provide some insight to like, especially if you’re working on a technical product, right? Where you can provide a deeper understanding to your customers for the hard questions. And then even if you don’t, even if you don’t think you’re going to provide value, that’s okay. It’s okay to tag along or to watch the video transcript, right? ‘Cause you’re gonna be learning. So don’t just assume that because you’re not gonna be providing value mean that, this doesn’t mean that you shouldn’t at least understand what’s going on there.

[00:36:15] How Is AI Reshaping the Role of Product Engineers?

Henry Suryawirawan: I think that’s a very good tip, right? So, I think even though you don’t have something to sort of contribute, you can still learn from those experiences. So you mentioned something very, interesting, right? Engineers now themselves can also use LLM to kind of like learn from all those things, like transcript conversations. And now I think it’s a good segue to talk about a AI impact to, you know, engineering, product engineering and all that. Because I think one aspect that people kept talking about is like the impact of AI. Now that we can produce code much faster, engineers now have more time presumably to start thinking about, you know, the product aspect. So what do you think personally for your situation, right? What is the impact of AI with maybe your role or maybe the way you see it for product engineer?

Drew Hoskins: Yeah. Yeah, I’m absolutely trying to figure this along out, along with everybody else at this point. One thing I’ll say, a couple things here. One is at my company Temporal, product is a bottleneck right now. And I think it’s feeling like increasingly a bottleneck. One of the things that I started to see is a lot more prototypes coming out of engineering, is just completely awesome, right? Like I love seeing, you know, all these demos every, you know, in our sprint showcase every couple weeks. And then like what I’m feeling is like, you know, everybody looks at me and they’re like, okay, we have this demo, like, help us get this out, right? And I’m just like, oh God, okay. I’ve got so much work to do. And so more product skills threaded throughout the organization I think will really help engineers be more empowered to get their own prototypes out to production. And make those, you know, like every prototype comes with like a list of decisions that need to be made about it, right? And so it’s like, how do we drive the decision making that it takes to get it out?

And, so yeah, I would say, you know, what Kent Beck was saying recently about my book was that, you know, Drew was helping to heal the rift between product and engineering. And I think that’s an interesting way of phrasing it because if you think about it, these are two very tightly related disciplines, right? The product and the engineering side. And there has been this artificial divide and the sides haven’t been talking to each other. Like if you, one of the reasons I wrote the book was because there was no engineering literature about some of these topics. And it’s like the topics are well known in like the design community, the product community. But like nobody bothered to tell engineers about it. It was as if we were like in different silos and we never talked to each other.

And so I think there’s gonna be a combination like more people who are, what Else van der Berg calls M-shaped people, right, who’ve got like spikes in engineering skills as well as spikes in product skills. And ‘cause it’s such a leveraged combination, especially in the age of AI and especially when, you know, engineer’s coding skills are maybe a little bit less leveraged than they were two years ago. And so, you know, I think some folks will shift over to product but that’s sort of… but I thought, I also think that there’s an enormous potential in just getting more people who are hybrids. And you don’t have to go all the way over to product to like add value.

And I might go back, I might, I’m actually kind of jealous of like the engineers right now ‘cause they have all these amazing new tools that they’re getting to use. And I’m like, I’m kind of missing out on it. Like I’m using Claude Code and some, and I’m writing some samples and stuff. But like, it’s not really, it’s not really the same. And I’m missing out on some of the fun, so maybe I’ll go back and be a hybrid engineer again.

[00:40:06] Should Product Managers Learn to Code in the AI Era?

Henry Suryawirawan: Right. So I think that’s a very good experience that you’re experiencing, right? So, but because we talk a lot about engineer having more product mindset, is there such thing as a PM being more technical, right? PM, you know, who could write code? Is this something that is also happening? Because again, with the introduction of these AI tools, now presumably, you know, PM can do vibe coding, you know, all these, you know, Lovable, Bolt, Replit kind of tools to actually build prototypes themselves as well. So what is your thought on this like PM becoming more technical as well? Is this something that is also happening that people should do as well in the industry?

Drew Hoskins: I think that I would characterize it differently. Like okay, vibe coding as a PM. One of the things that it gets me is, for example, I don’t need to go to knock, need to go knock on a designer’s door to like mock up a UI, right? Like I can vibe code that. And that lets me show off like ideas more rapidly without all that back and forth with design. Just to, again, not to like say that this is gonna be shipping product design, but just to like have something to show people. And similar with the code, like if I wanna underst- if I wanna show off some specific interaction that I’m focusing on, I can vibe code that. But it’s not, I wouldn’t call that being more technical as a PM. And I don’t think that that’s a way to gain technical skills as a PM. Like I still think you need the fundamentals of like computer science or, you know, system critical thinking. Maybe it helps with a little bit. But at the end of the day, like the PM isn’t writing production code, you know. And I, without those technical skills, I don’t see that happening. But that said, I do think that for PMs who do have technical skills, it is, it remains a very high leverage skillset. And like I said, like with the PMs I’ve been talking to who have technical skills, they say it’s indispensable. And it’s one of the reasons that they have been able to stand out among some of their peers.

Henry Suryawirawan: Yeah, so I think in the end, it’s like two different disciplines, right? So some people have a good spectrum of skills from both disciplines. I think definitely those people will be highly valuable. And that’s why people keep talking about this product engineer because now that the engineers, maybe part of their work has been, you know, automated by AI, you know, churning code and, you know, doing all this, you know, fancy stuff, right? Now actually to increase, improve on the other discipline, right, which is the product mindset. Similarly, I think it could also happen with the PM learning more technical stuff. But I think still these are probably too hard to expect one person to be good at at the same time, right? So, which brings me to…

Drew Hoskins: Well, let me just like say one thing, which is like you can… Like I said, like if you have a technical background, you can definitely do both. And, you know, a lot of founders are this way, right? Like a lot of founders don’t have, they don’t hire a PM until they’re, you know, their 10th hire or something. And, there’s just, you know, like, so they have to be the PM at first. And so I do think that there’s a lot of people that can do both, but I don’t think vibe coding is your way to gain, you know, like vibe coding is not the route to that technical skillset.

Henry Suryawirawan: Yeah.

Drew Hoskins: As far as I can tell.

Henry Suryawirawan: So I think there’s a danger of, you know, missed expectation, right? So people now think with AI you can replace engineers, you know, do vibe coding. So I think like what you mentioned earlier is like production, great quality. I think this is something that probably sometimes it’s a hit and miss using all these AI tools. We can still hear so many security issues or maybe bugs happening. But I think one challenge as well, like how do you evolve the system? Because I think AI now is kind of like not good in refactoring its own solution. Maybe they can give you hints of what the system is all about, but still you need a technical ability to actually shape the system.

[00:43:56] What Is the Right PM-to-Engineer Ratio in the AI Era?

Henry Suryawirawan: So people talk about, you know, maybe ratio of a product engineer. Sorry, ratio of product manager and, you know, engineering, right? So I think this tends to change as well after the introduction of AI. So what do you think is a good ratio now? Because if you’re saying now you are also kind of like still the bottleneck and engineers now churning more code. So what do you think is a typical good ratio or how should people shape their team structure?

Drew Hoskins: Yeah, that’s a good question. I don’t have a ratio for you and it’ll depend on the company. I feel like there needs to be more product, total. Product thinking total in the orgs than there is today either ratio. Now whether that comes in more engineers becoming hybrids or more PMs being hired? I don’t know the answer. But, yeah, it’s gonna be a profound shift, like. And the good news is like, you know, in a lot of these companies, like the product manager role is one of the few roles that’s paid on the same pay ladder as the engineering role. And so, it’s like, it also has, involves rare skills that are hard to acquire. And so yeah, I would say that’s a good sign for engineers who are… You know, I think there’s like three skill sets, right? There’s like people skills, there’s system skills, and then there’s product skills. And like you probably are going to need all three of those, but then you can kind of pick like maybe two of them to… like it’s gonna be harder and harder to get by with just one of the three that you’re spiked on as you become more senior. So looking to pick two of them is probably a good idea.

[00:45:48] How Should Engineering Leaders Respond to AI Productivity Pressure?

Henry Suryawirawan: Yeah, so I think that’s very good tips, right? So people, system and product. So I think now if AI can help a lot in terms of, you know, churning out code, but we all know, right, as engineer also we know like writing code is not the only thing that matters. You know, you have still all this collaboration, defining what the right thing to build, right? And also the other aspects like for example, communication, influencing and all that. So do you think there’s a good tips that you can give to engineering leaders or maybe stakeholders? You know, because the expectation they have now is like using AI we can improve, you know, the productivity of engineering by a lot, right? Even they’re thinking about laying off engineers and all that. So what tips that you can give maybe to, you know, engineering leaders or maybe these executives to maybe correct their mindset in a way. Is there some something that you can chip in here as well?

Drew Hoskins: Yeah, sure. I mean, if you’re not already doing it, you know, asking why a lot is, is a good practice of just making sure you’re bringing in more and more context about what you’re really trying to do. Switching your viewpoint constantly between the system and the users, going back between those two indexes we talked about, that’s not an easy thing to do and you can easily kind of get stuck in one or the other. And so just switching, realizing when you need information from the other index is an important skill. More writing down the stories and scenarios and then sharing those with your team and using that as a mechanism to get alignment, right?

So one of the powerful aspects of stories that we didn’t talk about yet is everybody understands stories. And so not only are they a good way to discover potential problems that you might need to overcome in your product, but they’re also a good way to communicate to other people whose brains all work differently than yours. But the story is that sort of medium of communication or that, you know, we, a lot of us, you know, grew up hearing bedtime stories or reading children’s books. And so we’ve all read stories from an early age. And so a good way to communicate to people, and it’s a good way to get alignment across a lot of people if you’re a leader of like, hey, we all agree that these are the scenarios that we care most about. And then you share those stories and people nitpick them. And then you’ve got your like compendium of stories or your like document full of stories that are like, these are the ones we’re going for, for this milestone. It’s a great leadership technique.

And then finally, I mean, you know, finding ways for yourself and for your team to engage with the users. Customer support is one way. One of the things that I see commonly missed is, especially on consumer facing businesses, is the walls go up because there’s so many users and they’ve got so much feedback and it’s just so much noise, right? And people have their hot takes. And you can’t get work done as an engineer if you’re constantly dealing with like customer input. You know, it’s a little bit easier on a, on like a business-to-business kind of B2B thing, but still. And even on an internal tools team, it can be distracting. And so a lot of engineers instinctively put up walls. What that means is they lose sight of what the users actually want. And then that causes problems.

Like there was this, recently, I drive a Lucid Air, Lucid the car brand, electric car brand. And I drive a Lucid Air. And the company was having a lot of quality issues, right? Just with their software, like the hardware, the, everything about the drive was great, but the software, there were software problems. It was hard to give them feedback. Like it was like… and so they set up this email that you could just, email address you could, that users could just send feedback to it. And then they had an AI sift through all of the feedback and figure out what the most important and most frequent things were, and then present that to the engineering team. And they made this, they just made this big like quality release and everybody’s really excited about it and really happy about it ‘cause it’s fixing so many problems. And they had just, frankly like the trick was just to like not lose the connection with, I mean I’m probably minimizing some of the engineering stuff that happened, but like, ‘cause I’m not at the company, but they just found a way to reconnect with their users.

And so that was, that would be my top advice is just like, make sure you’re staying connected with the users and then finding a way to balance the randomness of it from the, the feedback. And it could be like getting reports from your support team, to make sure that you’re, they’re passing things through to you. It could be lots of things, but just find a creative way to, to stay connected.

Henry Suryawirawan: Yeah, I think those are very good tips, right? I would say maybe if I can just, mention some of them. Like thinking more about whys, start writing more scenarios based kind, write more documents, you know, documenting all this user journey and scenario. Because I think that’s a good way to actually collaborate and align your expectations with stakeholders, product and engineers. And yeah, engage with the users more. I think this is quite straightforward, but I think sometimes we neglect doing it.

[00:51:04] What Advice Would You Give Junior Engineers Entering the Industry Today?

Henry Suryawirawan: So maybe now the advice for junior engineers, because I know that you have been around in the industry, you understand the impact of AI. You also see the kind of product mindset needed. Some juniors, you know, may have difficulty now to find a job simply because of, you know, this AI thing happening. So what will be your good advice for juniors now because they’re new to in the industry, they’re not strong enough yet at the engineering level, but at the same time people now expect them to have more product thinking. Is there such practical tips for them that you can give them as well?

Drew Hoskins: Yeah, this is a great question. So I’ll do my best being not a junior engineer anymore. So like hopefully this doesn’t come across as tone deaf. One of the things, okay, so imagine you’re doing a quiz, and on the one hand, let’s say you’re doing a multiple choice quiz. And on the other hand, it’s a freeform quiz where you have to like type the answer, right? You’re gonna learn better in the freeform quiz because in the multiple choice quiz, you can just look over the answers and you can see, oh, well it’s gotta be this one ‘cause it can’t be those other three. And so a lot of that work of generating an answer was done for you by the author of the quiz. And generative AI is effectively doing that for you. It’s basically like reducing something that was previously, like something you had to work hard at to like a multiple choice quiz. But you are also a generative intelligence. And so, and that’s an important, I still feel like that’s a very important way to train and force yourself to do. And so even if you’ve got something that could give you the answers, you know, sometimes not using it or thinking critically of at least thinking critically and editing what it did, I think it’s gonna continue to be important and it’s gonna differentiate the people who have a like steadier growth to their career and like ramp up to the level of getting a new job versus people who kind of stay stuck at this sort of like intro level, entry level skillset.

And then I think the second thing is like you could do two things with your extra time. So, okay, you’re, you can ship more code now, right? You can write more, or if you haven’t gotten a job yet, you can write more apps. And that’s a good thing to do, you know, just like doing more of that. But also consider some of the time that that’s freed up to improve your skillset. You know, like don’t just do more code with the extra tools that you have, but develop some of these higher level skills such as product skills, collaboration skills. Ownership skills is another one that we haven’t talked about, but just skills of like getting things done and seeing them through end-to-end. Those are all good ways to upskill. And then be ready for somebody to hire you. So yeah, see things through, don’t just write the first prototype and then move on to something else.

Henry Suryawirawan: Yeah. Again, another analogy I haven’t heard before about, you know, using quiz versus the freeform kind of like quiz, right, to kind of like explain about this. ‘Cause, yeah, I believe if you use a lot more of these AI tools, yes, you’re just giving given options. Sometimes it’s just one option, right? Until you criticize it, and ask it differently in the different prompts, maybe ask them to tweak something. So if you don’t train that muscles, definitely maybe we don’t even have a multiple choice quiz. It’s like one way quiz that you just, you know, clicking on and on, right? Like a wizard. But also I think the other thing is like shipping is definitely important, but also don’t forget about the other aspects, right? I think the good thing now for me at least personally with AI, I can ask all random questions that I’m interested in when working on something that kind of like forces you to also learn something new, right? And if you’re interested, you can dig deeper, you know, through other materials, resources, and all that, including your book, which I find there are a lot of practical tips for engineers to start having this product thinking mindset. It’s not like a theory thing, but more practical steps that people can find as well.

[00:55:17] What Other Topics Does the Product-Minded Engineer Book Cover?

Henry Suryawirawan: So speaking about that, as we move towards our, you know, end of conversation, is there anything important in your book that we haven’t really covered today?

Drew Hoskins: Well, I hope so. Yeah, I mean, it’s, so the book is like, really, it’s framed around these four pillars that you asked me about earlier to, you know, Discover, Define. And it’s showing how product skills are used at all four like stages in the journey. And so it covers, you know, topics from product architecture to error messages, which is one of my favorite topics of like writing good error messages and that are actionable and help, actually help users. And prioritization. Yeah, there’s lots of good stuff. Dogfooding so like using your own product and just how to write scenarios better. So there’s a bunch of different topics. It’s sort of a, somebody called, one of my readers called it the speedrun your product thinking. So it’s supposed to be very practical of like, you know, much more applied to the engineering role than something you would read from like the design or the product community. So yeah, there’s a bunch of stuff, but I don’t know that there’s any one thing that stands out as, critical to talk about now.

Henry Suryawirawan: Yeah, so I think, yeah, dogfooding, thanks for sharing that because I think some engineers don’t actually use the products. For example, so sometimes if you build B2B, right, sometimes it’s also difficult for you to get access to. But always don’t forget if you have a chance, dogfood your product. Use your product because you can empathize with the users experience, which is you, yourself, and try to improve your product thinking as well.

[00:57:03] 3 Tech Lead Wisdom

Henry Suryawirawan: So Drew, thank you so much for sharing all this. I hope people check out your book, especially engineers who are now trying to become much more product-minded, because it’s very important skill in this AI age. I have one last question for you which is like a tradition in my podcast. I call this a three technical leadership wisdom. Think of it just like an advice you wanna give to the listeners to, you know, close this. Is there any version that you can share with us today?

Drew Hoskins: Yeah. So I guess number one would be to have metacognitive skills, which by that, I would mean thinking about thinking. Like stepping back and thinking, what am I good at? What am I not good at? What do I need to improve? What do I need to, what is like my, what are my superpowers and where is it that I am the most leveraged as an employee? I think it’s just so critical to just be stepping back sometimes and thinking about how you think. And this can, if reflect by being, having a conversation with your manager. Like, hey, like this is the kind of or like somebody you’re thinking of like going to workforce. Like, Hey, here’s my skillset. Like what do you think of this? Like this is what I’m good at, this is what I don’t love as much. And then also using that to decide, like there’s times in your career where you wanna double down on your strengths and there’s times in your career where you wanna show up your weaknesses. And just thinking strategically about that can go a long way towards making sure that you’re happy and productive. So that would be one.

I think two is building ownership skills. And by that I mean like I said earlier, seeing things through and being accountable to the outcomes is just always critical. And it’s the thing that is the least, is the thing that the like LLMs are like the furthest away for being able to do. One of the fun things about ownership skills is that you been, can be more in control of your own destiny, right? Like you can work on fewer failed products and things like that because you’re the one who can see them through. And so that would be my second one.

And the third one is just take the time, take some percentage of your time to getting better, right? Like at being curious. It could be learning more. It could be learning about this whole new AI thing. It could be going and figuring out what this Moltbot thing is, Moltbook thing is, you know, whatever, whatever. Just being curious. It could be about practicing. It could be reading a book or a blog. But allocate a percentage of your, don’t let the company that you work for take away your time to becoming better in your career. You don’t let them overload you to the extent that you’re not still learning and not getting better.

Henry Suryawirawan: Yeah, so I think that’s the last tip there always, very important, right? Sometimes also this is also my perspective, right? So don’t also let the company you work at kind of like drive where you should be, right? What you should learn, right? So for example, if you’re working, I dunno, in financial industry, you always learn about financial, but also like maybe spend time to actually, you know, learn other aspects of other jobs as well. Because one day it might come handy for your next career.

So Drew, thank you so much for your time today. If people want to connect with you, find you online, ask you more about, you know, product-minded engineering mindset, is there a place where they can find you online?

Drew Hoskins: Yeah. So I have a blog on Substack at drewhoskins.substack.com. You can connect with me there. You can also reach out on LinkedIn. I understand that LinkedIn doesn’t always let you include a message depending on the tier of account that you have, but I will try to connect with you and see if you want to chat or have feedback about the book or looking for advice. You know, I’m pretty open on that platform.

Henry Suryawirawan: Right. So thank you so much for writing this book. I think this is one of the rare materials that engineers can do to upskill themselves. You know, coming back to your theme, you know, improving yourself, time to learn something outside of just the engineering aspects. I know that we all talk about AI these days, but I think product mindset is definitely very critical in this era. And yeah, and I hope people check out the book. So thank you so much again, Drew, for this conversation.

Drew Hoskins: Thanks Henry. I loved your questions. They’re really thoughtful.

– End –