1 00:00:00,020 --> 00:00:02,297 Engineer's coding skills are maybe a little bit less 2 00:00:02,297 --> 00:00:03,750 leveraged than they were a few years ago. 3 00:00:03,810 --> 00:00:06,486 Today's guest is Drew Hoskins, former senior staff engineer at 4 00:00:06,486 --> 00:00:09,596 Meta and Stripe, and the author of Product Minded Engineer, a 5 00:00:09,596 --> 00:00:12,216 book teaching engineers to think beyond code and build the 6 00:00:12,216 --> 00:00:14,430 product mindset that matters most in the AI era. 7 00:00:14,899 --> 00:00:16,560 So in your definition, what is product engineer? 8 00:00:16,620 --> 00:00:19,380 My definition would be an engineer who cares at least as 9 00:00:19,380 --> 00:00:21,405 much about the what and the why as the how. 10 00:00:21,740 --> 00:00:23,750 So what are they doing and who are they doing it for? 11 00:00:23,840 --> 00:00:26,128 One way you can tell a product might engineer is when you ask 12 00:00:26,128 --> 00:00:28,837 them about their history of their career and they tell you 13 00:00:28,837 --> 00:00:31,624 what they built rather than say what technologies they use to 14 00:00:31,624 --> 00:00:33,574 build it. What is the impact of AI with 15 00:00:33,574 --> 00:00:35,620 your role or the way you see it for product engineer? 16 00:00:35,629 --> 00:00:36,890 Product is a bottleneck right now. 17 00:00:37,040 --> 00:00:38,890 And it's feeling like increasingly a bottleneck. 18 00:00:39,019 --> 00:00:41,918 I started to see is a lot more prototypes coming out of 19 00:00:41,918 --> 00:00:43,069 engineering, which is completely awesome. 20 00:00:43,250 --> 00:00:45,995 And then what I'm feeling is like everybody looks at me and 21 00:00:45,995 --> 00:00:48,815 they're like, okay, we have this demo, like help us get this out. 22 00:00:48,815 --> 00:00:51,485 And I'm just like, oh God! As engineer also, we know like 23 00:00:51,485 --> 00:00:53,644 writing code is not the only thing that matters. 24 00:00:53,805 --> 00:00:55,963 There's like three skill sets. There's like people skills, 25 00:00:55,963 --> 00:00:58,019 there's system skills, and then there's product skills. 26 00:00:58,205 --> 00:01:00,815 And you probably are going to need all three of those. 27 00:01:00,815 --> 00:01:03,845 Don't just do more code, but develop some these higher level 28 00:01:03,845 --> 00:01:06,459 skills such as product skills, collaboration skills, ownership 29 00:01:06,459 --> 00:01:08,121 skills. So many conflict or 30 00:01:08,121 --> 00:01:10,707 misunderstanding between product and engineer, how to handle this 31 00:01:10,707 --> 00:01:12,392 kind of conflict? It's almost like speaking a 32 00:01:12,392 --> 00:01:14,170 different language. Because with the engineer, their 33 00:01:14,170 --> 00:01:15,789 brain is indexed around the system. 34 00:01:15,820 --> 00:01:18,284 The product manager who's only thinking in terms of like the 35 00:01:18,284 --> 00:01:20,352 user stories. But in my book, I call it the 36 00:01:20,352 --> 00:01:22,520 great re-indexing, because when you're developing a product, you 37 00:01:22,520 --> 00:01:25,090 start with the user journey and then you go to the system. 38 00:01:25,190 --> 00:01:27,160 That's the great art of software engineering really. 39 00:01:43,930 --> 00:01:46,376 Hey, quick pause. My goal with Tech Lead Journal 40 00:01:46,376 --> 00:01:48,960 is simple. Learn from the best in tech so 41 00:01:48,960 --> 00:01:52,330 we can all grow together. If this resonates with you, hit 42 00:01:52,330 --> 00:01:55,624 subscribe to follow the channel. It's the biggest way for you to 43 00:01:55,624 --> 00:01:58,195 support the show and help us keep bringing great guests and 44 00:01:58,195 --> 00:02:00,682 insights to you. Thanks for being here, and let's 45 00:02:00,682 --> 00:02:03,112 get back to it. Hello. 46 00:02:03,112 --> 00:02:06,137 Welcome back to another new episode of the Tech Lead Journal 47 00:02:06,137 --> 00:02:08,271 podcast. I have with me Drew Hoskins. 48 00:02:08,642 --> 00:02:11,872 He recently published a book titled Product-Minded Engineer. 49 00:02:12,382 --> 00:02:16,422 I think this topic is gonna be quite relevant in this AI age 50 00:02:16,422 --> 00:02:19,351 era. People are talking a lot now 51 00:02:19,351 --> 00:02:21,626 about being a product engineer, product-minded engineer. 52 00:02:21,676 --> 00:02:25,431 They're kind of like similar. So welcome, Drew, to the 53 00:02:25,431 --> 00:02:27,126 podcast. I'm really looking forward to 54 00:02:27,126 --> 00:02:30,036 discuss about this so that we can help people to become much 55 00:02:30,036 --> 00:02:33,397 more product engineer mindset. Thanks for having me, Henry. 56 00:02:33,397 --> 00:02:35,786 This is gonna be really fun. Yeah. 57 00:02:36,386 --> 00:02:40,316 So Drew, maybe let's level set in the very beginning, right? 58 00:02:40,766 --> 00:02:44,330 Because this term has been coined for quite some time now, 59 00:02:44,330 --> 00:02:46,971 product engineer. I think even a long time ago 60 00:02:46,971 --> 00:02:50,438 when there used to be like a lot of scaleups, people started 61 00:02:50,438 --> 00:02:53,174 talking about product-minded engineer or product engineer in 62 00:02:53,174 --> 00:02:55,509 short. So in your definition, what do 63 00:02:55,509 --> 00:03:00,097 you think is product engineer? Yeah, my definition would be an 64 00:03:00,097 --> 00:03:05,221 engineer who cares at least as much about the what and the how 65 00:03:05,221 --> 00:03:07,488 as. Or sorry, the what and the why 66 00:03:07,488 --> 00:03:09,344 as the how. So what are they doing and who 67 00:03:09,344 --> 00:03:11,912 are they doing it for? And of course, they're an 68 00:03:11,912 --> 00:03:14,146 engineer, so they need to figure, they have to, they need 69 00:03:14,146 --> 00:03:16,284 to understand the how, what, how they're gonna accomplish it. 70 00:03:16,284 --> 00:03:19,227 But, you know, one way you can tell a product-minded engineer 71 00:03:19,227 --> 00:03:23,011 is when you ask them about their history of their career and they 72 00:03:23,011 --> 00:03:27,747 tell you what they built rather than say what technology do they 73 00:03:27,747 --> 00:03:31,820 use to build it? That's a pretty good litmus test 74 00:03:31,820 --> 00:03:33,872 for who might be considered product-minded. 75 00:03:34,322 --> 00:03:37,329 It's not an exclusive club. It's not like you need some rare 76 00:03:37,329 --> 00:03:38,772 skills to be a product-minded engineer. 77 00:03:38,802 --> 00:03:44,226 And it, and also I do wanna underscore the idea that 78 00:03:44,226 --> 00:03:47,042 infrastructure engineers can be product-minded engineers, right? 79 00:03:47,102 --> 00:03:50,452 Because everything is a product. Anything that you check into 80 00:03:50,452 --> 00:03:53,947 your code base, any function or class can be viewed as a 81 00:03:53,947 --> 00:03:55,182 product, right? It has an interface. 82 00:03:55,182 --> 00:03:58,502 It has users who are other engineers in this case. 83 00:03:59,129 --> 00:04:02,159 And those people have like usability problems. 84 00:04:02,159 --> 00:04:05,779 They have requirements. So anything really from the big 85 00:04:05,779 --> 00:04:09,469 to the small can be considered a miniature product. 86 00:04:10,199 --> 00:04:12,679 So you can bring these skills no matter where you are in the 87 00:04:12,679 --> 00:04:16,293 stack. I love how you define it very 88 00:04:16,293 --> 00:04:18,588 succinctly, right? So an engineer who cares about 89 00:04:18,588 --> 00:04:21,370 the why and the what versus just the how, right? 90 00:04:21,370 --> 00:04:24,759 Because I think techies sometimes we love our languages, 91 00:04:24,759 --> 00:04:27,881 our frameworks, and now it's like AI tools that we use. 92 00:04:28,871 --> 00:04:32,017 But also cares so much about the why and the what that they 93 00:04:32,017 --> 00:04:34,024 build, right? So I think that's a pretty nice 94 00:04:34,024 --> 00:04:36,899 definition. So you mentioned a lot about, 95 00:04:36,899 --> 00:04:38,801 you know, the build itself, right? 96 00:04:38,801 --> 00:04:42,267 So the product, does it mean that if I work in a consulting 97 00:04:42,267 --> 00:04:46,310 or if I work in non-product, you know, companies, can I still be 98 00:04:46,310 --> 00:04:50,284 a product engineer? Well, in consulting, I mean, 99 00:04:50,284 --> 00:04:54,466 you're actually even more of beholden to the needs of the 100 00:04:54,466 --> 00:04:56,374 people that you're consulting for. 101 00:04:56,374 --> 00:04:59,202 So you have to have a lot of awareness of your users in that 102 00:04:59,202 --> 00:05:01,760 case. I certainly, like personally, I 103 00:05:01,760 --> 00:05:05,063 enjoy the challenge of trying to build a product for many 104 00:05:05,063 --> 00:05:07,653 different users. That's one of the fun parts for 105 00:05:07,653 --> 00:05:09,974 me. So I probably wouldn't be a good 106 00:05:09,974 --> 00:05:12,735 consultant. But yeah, absolutely. 107 00:05:12,760 --> 00:05:17,190 I mean, you know, just a few users or millions of users, like 108 00:05:17,190 --> 00:05:20,670 in all of those cases, product skills come into bear. 109 00:05:21,470 --> 00:05:23,885 Right. So this term, I think we, we 110 00:05:23,885 --> 00:05:26,265 should clarify. It's not just specifically for 111 00:05:26,265 --> 00:05:29,170 engineers who work in a product companies, right? 112 00:05:29,170 --> 00:05:31,910 So no matter where you are, I think you can still, the 113 00:05:31,950 --> 00:05:33,580 mindset, the what and why, right? 114 00:05:33,580 --> 00:05:36,682 Coming back to what you said, I think is important in what you 115 00:05:36,682 --> 00:05:40,147 do. So I think for, you have been 116 00:05:40,147 --> 00:05:44,050 around for quite some time. You know, you have been in a 117 00:05:44,050 --> 00:05:46,092 different companies. And actually when I look at your 118 00:05:46,092 --> 00:05:48,780 history, I think you are kind of like perfectly suitable to write 119 00:05:48,780 --> 00:05:52,168 this book. So you have worked in Microsoft, 120 00:05:52,168 --> 00:05:56,035 you know, Meta, Stripe as, last is like a senior staff engineer 121 00:05:56,035 --> 00:05:58,600 or something like that, right? So purely IC. 122 00:05:58,600 --> 00:06:01,900 And then recently you moved into product management which is like 123 00:06:01,900 --> 00:06:06,040 becoming a product manager. So tell us a little bit more 124 00:06:06,040 --> 00:06:09,000 from learnings, from your learnings in these great 125 00:06:09,000 --> 00:06:12,207 companies. And then what actually you meant 126 00:06:12,207 --> 00:06:15,221 by, you know, switching to product manager now. 127 00:06:15,221 --> 00:06:18,517 Are you still doing some kind of engineering thing or are you 128 00:06:18,517 --> 00:06:20,051 just purely a product manager now? 129 00:06:21,477 --> 00:06:23,032 Yeah, sure. I'll start from the beginning. 130 00:06:23,032 --> 00:06:26,362 So I started at Microsoft on a compiler team. 131 00:06:26,752 --> 00:06:32,762 I was like "hardcore", you know, I double majored in math. 132 00:06:32,782 --> 00:06:36,755 I loved algorithms. You know, I was very much into 133 00:06:36,755 --> 00:06:41,182 the how. And I ended up working on this 134 00:06:41,182 --> 00:06:44,777 kind of compiler framework that was ill fated. 135 00:06:44,777 --> 00:06:48,604 It didn't make an impact. But the chief architect's vision 136 00:06:48,604 --> 00:06:52,806 for the framework was to be the Assembly language for people who 137 00:06:52,806 --> 00:06:56,370 wanted to build compilers or jitters or other tools. 138 00:06:57,350 --> 00:07:01,510 And my thought was who wants to code in Assembly language? 139 00:07:01,540 --> 00:07:03,430 Like I don't, like I didn't like the vision. 140 00:07:03,430 --> 00:07:07,030 I thought like all of our APIs were really hard to use. 141 00:07:07,900 --> 00:07:11,310 But the C# community was doing really great work on API 142 00:07:11,310 --> 00:07:14,855 usability at the time. And so I started doing some work 143 00:07:14,855 --> 00:07:18,277 on my team to kind of bring like a us- like an API usability 144 00:07:18,277 --> 00:07:20,897 mindset over to, we were actually at C++ code base. 145 00:07:20,897 --> 00:07:23,947 And so like, hey, let's like import some of the good work and 146 00:07:23,947 --> 00:07:28,407 thinking that's like being done in the C# community over to C++. 147 00:07:29,561 --> 00:07:34,681 And that's how I kind of, that's how I got the API usability bug. 148 00:07:34,681 --> 00:07:38,411 I wanted to write APIs that made other people really productive. 149 00:07:39,576 --> 00:07:43,546 And then I switched teams over to Windows and I worked on this 150 00:07:43,546 --> 00:07:47,501 another API team were like, I'm gonna date myself here, but 151 00:07:47,501 --> 00:07:50,871 tablet PC. It was like an inking interface, 152 00:07:50,871 --> 00:07:54,547 you know, APIs for people who wanted to build like tablet 153 00:07:54,547 --> 00:07:59,095 applications. And I did a usability study. 154 00:07:59,615 --> 00:08:02,243 And back in those days, it was actually like a one-way mirror, 155 00:08:02,243 --> 00:08:04,375 like where I sat on one side and they couldn't see me. 156 00:08:04,375 --> 00:08:07,657 And I watched them code. And it was like the most 157 00:08:07,657 --> 00:08:10,515 humbling experience I've ever had in my life because they 158 00:08:10,515 --> 00:08:14,276 struggled to use my prototypes. I mean, it was painful and it 159 00:08:14,276 --> 00:08:18,935 was a big lesson, but also, like I'm very attracted to difficult 160 00:08:18,935 --> 00:08:21,973 things. So I thought, oh, well this is a 161 00:08:21,973 --> 00:08:24,295 really, this is way more interesting than I thought, like 162 00:08:24,295 --> 00:08:28,063 this whole design thing. And so that was a humbling 163 00:08:28,063 --> 00:08:31,245 experience and really taught me that I needed to connect with my 164 00:08:31,245 --> 00:08:33,850 users more. And even though I was interested 165 00:08:33,850 --> 00:08:37,914 in usability and in product thinking, I wasn't there yet. 166 00:08:38,953 --> 00:08:42,205 So then at Facebook, I think the thing I learned at Facebook was 167 00:08:42,205 --> 00:08:47,485 to be more entrepreneurial and to prioritize my time better. 168 00:08:48,445 --> 00:08:52,745 Because I was used to being given more tight like, hey, 169 00:08:52,745 --> 00:08:55,180 here's what you should go do. But at Facebook, Facebook was 170 00:08:55,180 --> 00:08:58,972 very much about this. This is, I joined in 2009, it 171 00:08:58,972 --> 00:09:02,375 was very much like distributed autonomy, not a lot of consensus 172 00:09:02,375 --> 00:09:04,394 building. You just go do a thing, you 173 00:09:04,394 --> 00:09:08,063 know? And you have to be very good at 174 00:09:08,063 --> 00:09:10,291 prioritizing your time or you're not gonna get... 175 00:09:10,291 --> 00:09:12,561 And my first couple years, frankly, I kind of struggled 176 00:09:12,561 --> 00:09:15,920 with that. My projects were hit or miss 177 00:09:15,920 --> 00:09:18,836 because like I didn't necessarily have a really good 178 00:09:18,836 --> 00:09:20,456 understanding of what the impact would be. 179 00:09:22,076 --> 00:09:26,532 And so this started to teach me that, hey, like product thinking 180 00:09:26,532 --> 00:09:30,711 is not just about usability, it's also about like what do 181 00:09:30,711 --> 00:09:33,371 users actually want in the first place? 182 00:09:33,461 --> 00:09:36,821 And like what's the best way to, like what are the things that 183 00:09:36,821 --> 00:09:41,693 are gonna make the most impact? My biggest claim to fame at 184 00:09:41,693 --> 00:09:45,956 Facebook was I founded this company called, or this, this 185 00:09:45,956 --> 00:09:50,257 project called Ent schema, which was like a really powerful ORM 186 00:09:50,257 --> 00:09:53,976 and sort of development platform for modeling our data. 187 00:09:53,976 --> 00:09:57,967 Like our graph like users and groups and status updates and 188 00:09:58,237 --> 00:10:02,105 photos and all those things. And it was like a huge step 189 00:10:02,105 --> 00:10:03,851 change in productivity for the company. 190 00:10:04,541 --> 00:10:10,443 And in that journey, I was a former, like I was, I moved down 191 00:10:10,443 --> 00:10:14,163 the stack, so to speak. Like I was a developer at 192 00:10:14,163 --> 00:10:17,569 Facebook and then I became somebody serving developers at 193 00:10:17,569 --> 00:10:20,103 Facebook. And so I had a lot of empathy 194 00:10:20,103 --> 00:10:22,931 for that role because of my couple years of experience. 195 00:10:24,302 --> 00:10:28,096 And so then around this time as I'm working on this project, 196 00:10:28,096 --> 00:10:32,794 they developed this system of archetypes which were five kind 197 00:10:32,794 --> 00:10:36,492 of staff level roles that they've seen engineers be 198 00:10:36,492 --> 00:10:42,226 successful with at the company. And the archetypes were a 199 00:10:42,226 --> 00:10:49,016 generalist, a specialist, a fixer, a coding machine which is 200 00:10:49,016 --> 00:10:52,431 somebody who's just very, very productive at churning out code, 201 00:10:52,431 --> 00:10:55,835 and - which I guess Claude, Claude Code is like a coding 202 00:10:55,835 --> 00:10:59,942 machine archetype frankly - and a product engineering hybrid. 203 00:11:01,057 --> 00:11:04,105 And I was considering going into management, 'cause like, you 204 00:11:04,105 --> 00:11:06,657 know, I was senior now, and of course at some point you're 205 00:11:06,657 --> 00:11:08,751 supposed to figure out whether you're like gonna go to 206 00:11:08,751 --> 00:11:10,786 management. And my manager was like, no, 207 00:11:10,786 --> 00:11:14,437 look like there's this archetype which you seem to be, which is a 208 00:11:14,437 --> 00:11:17,053 product engineering hybrid. And if you just keep doing what 209 00:11:17,053 --> 00:11:18,877 you're doing, like you, you're gonna go far. 210 00:11:20,257 --> 00:11:24,143 So he helped me understand like sort of what my niche was at a 211 00:11:24,143 --> 00:11:27,888 company where, you know, in the early days, it felt like you had 212 00:11:27,888 --> 00:11:30,486 to be a coding machine. Like that was the, like all the 213 00:11:30,486 --> 00:11:31,828 most wanted engineers were coding machines. 214 00:11:31,828 --> 00:11:34,018 And that was never me. Like I wasn't somebody who just 215 00:11:34,018 --> 00:11:37,364 churned out a lot of code. And so like learning about these 216 00:11:37,364 --> 00:11:40,557 archetypes and finding that there was a role for me really 217 00:11:40,557 --> 00:11:44,186 accelerated my career. And also just my impact of just 218 00:11:44,186 --> 00:11:48,607 understanding who I was and how I fit into the scheme of things. 219 00:11:49,775 --> 00:11:52,941 And then when I moved to Stripe, I think the thing I learned at 220 00:11:52,941 --> 00:11:55,101 Stripe was being more collaborative. 221 00:11:55,821 --> 00:11:58,801 As I mentioned earlier, Facebook is a very like distributed 222 00:11:58,801 --> 00:12:01,946 autonomy kind of company. Not a lot of consensus building, 223 00:12:01,946 --> 00:12:06,901 at least back, back then, and lots of experimentation. 224 00:12:06,901 --> 00:12:09,786 But whereas at Stripe, it's more, it's a like... 225 00:12:09,786 --> 00:12:13,801 Stripe builds developer APIs for moving money, which have to be 226 00:12:13,801 --> 00:12:16,918 pretty rock solid. And so there needs to be a lot 227 00:12:16,918 --> 00:12:19,056 of concensus building. There's a lot of document 228 00:12:19,056 --> 00:12:22,626 writing and so you get a lot of people who are at Stripe, who 229 00:12:22,626 --> 00:12:26,015 are very producty, first of all. Like Stripe has done a great job 230 00:12:26,015 --> 00:12:27,378 of hiring product-minded engineers. 231 00:12:27,858 --> 00:12:30,138 And secondly a lot of people were very collaborative. 232 00:12:30,448 --> 00:12:33,528 And so I became a much better collaborator at Stripe. 233 00:12:34,390 --> 00:12:37,953 And then, you know, finally, I moved to Temporal Technologies, 234 00:12:37,953 --> 00:12:40,883 which is like a durable execution platform or you could 235 00:12:40,883 --> 00:12:42,741 think of it as a workflow engine. 236 00:12:44,031 --> 00:12:50,542 And I was, at the time, I was, I was writing the outline for the 237 00:12:50,742 --> 00:12:53,505 Product-Minded Engineer, the book that just came out with 238 00:12:53,505 --> 00:12:56,524 O'Reilly. And I thought, well, and I had 239 00:12:56,524 --> 00:13:01,040 been a customer of Temporal and they reached out to me and I was 240 00:13:01,040 --> 00:13:04,225 expecting them to reach out and ask me to come be an engineer. 241 00:13:05,095 --> 00:13:07,195 But they reached out and asked me to come be a PM. 242 00:13:08,125 --> 00:13:11,398 And they needed somebody who like was a former developer who 243 00:13:11,398 --> 00:13:13,807 really understood their customers, who are pretty 244 00:13:13,807 --> 00:13:17,257 technical folks by and large. And I thought, you know what? 245 00:13:17,257 --> 00:13:21,605 This would be a fantastic way to like deepen my product chops so 246 00:13:21,605 --> 00:13:24,097 that I can then do a better job writing the book. 247 00:13:25,185 --> 00:13:28,545 But I didn't know whether I was gonna get the book deal at the 248 00:13:28,545 --> 00:13:30,666 time. So it was a little bit of a leap 249 00:13:30,666 --> 00:13:32,335 of faith, but then the deal came through. 250 00:13:32,355 --> 00:13:35,340 So, so yeah, so I've been a product engineer for a couple 251 00:13:35,340 --> 00:13:37,587 years now. I mean a product manager for a 252 00:13:37,587 --> 00:13:39,430 couple years now. Right. 253 00:13:40,090 --> 00:13:42,566 Wow. I think, I can see the kind of 254 00:13:42,566 --> 00:13:45,631 like learnings that you had in all these companies, right, that 255 00:13:45,631 --> 00:13:47,710 brought you to your current role now. 256 00:13:47,890 --> 00:13:51,010 So I think the, a few theme that I like to call out. 257 00:13:51,010 --> 00:13:52,865 Like for example in the beginning you learn about, you 258 00:13:52,865 --> 00:13:56,200 know, product thinking, usability of the users, right, 259 00:13:56,200 --> 00:13:59,908 using your product. And then at Facebook, you learn 260 00:13:59,908 --> 00:14:03,466 about entrepreneurial thing and, you know, autonomy and impact, 261 00:14:03,466 --> 00:14:05,480 right? I think that's kind of like also 262 00:14:05,480 --> 00:14:08,394 important as a product engineer. And being collaborative at 263 00:14:08,394 --> 00:14:12,236 Stripe, which is, now you're doing a the product management 264 00:14:12,236 --> 00:14:15,745 itself, right? So I think when you did the 265 00:14:15,745 --> 00:14:19,010 switch, what was your biggest struggle, maybe should I say? 266 00:14:19,010 --> 00:14:22,831 Is it like not being able to produce code more or like what 267 00:14:22,831 --> 00:14:25,721 kind of things that you struggle in the beginning when you switch 268 00:14:25,721 --> 00:14:29,308 to product manager? Oh, in this last couple years, 269 00:14:29,308 --> 00:14:31,182 you mean at Temporal? Yeah. 270 00:14:31,622 --> 00:14:34,835 Well, I mean, okay, so I did take a downlevel to become a 271 00:14:34,835 --> 00:14:37,132 product manager which I was happy to do. 272 00:14:37,162 --> 00:14:41,082 I mean, I think I was recently interviewing a bunch of people 273 00:14:41,082 --> 00:14:44,618 who've transitioned to the product manager and, you know, 274 00:14:44,618 --> 00:14:47,352 the advice is like, look five to 10 years out. 275 00:14:47,592 --> 00:14:50,892 Don't like think of a down level as like a career setback. 276 00:14:50,892 --> 00:14:53,477 'Cause you'll get back, you know, to the level that you 277 00:14:53,477 --> 00:14:56,558 were. And so yeah, look, five 10 years 278 00:14:56,558 --> 00:14:57,973 out when making these transitions. 279 00:14:58,024 --> 00:15:00,694 And so that was fine. I was okay with that. 280 00:15:01,594 --> 00:15:04,608 I think like as far as the actual behaviors I struggled 281 00:15:04,608 --> 00:15:10,282 with, I mean, I, one thing is when you're a product-minded 282 00:15:10,282 --> 00:15:13,493 engineer among engineers, there's a default, there's an 283 00:15:13,493 --> 00:15:15,706 amount of clout that you get because you're an engineer on 284 00:15:15,706 --> 00:15:17,707 the engineering team, like you're a tech lead. 285 00:15:18,187 --> 00:15:22,867 And so people, I found it easier to lead from that position. 286 00:15:23,287 --> 00:15:25,790 As a product manager, I'm in a different org from the 287 00:15:25,790 --> 00:15:27,149 engineers. They don't necessarily know 288 00:15:27,149 --> 00:15:29,977 who's this guy who's like asking them to do things. 289 00:15:29,977 --> 00:15:32,977 I'm not the one who's gonna have to be on the hook to build the 290 00:15:32,977 --> 00:15:39,218 thing that I'm advocating for. And so I find that I need to 291 00:15:39,218 --> 00:15:41,634 show my work more. Like I have to actually like 292 00:15:41,634 --> 00:15:44,902 show the user quotes of like the people who are asking for things 293 00:15:44,902 --> 00:15:49,172 and like be more detailed on like the scenarios that I write 294 00:15:49,172 --> 00:15:53,930 and just, you know, really provide more supporting evidence 295 00:15:53,930 --> 00:15:57,184 for what I'm saying because there's a little less default 296 00:15:57,184 --> 00:16:00,008 built-in trust. And also I'm not just 297 00:16:00,008 --> 00:16:03,130 influencing engineers, but I'm also influencing the 298 00:16:03,130 --> 00:16:06,801 go-to-market teams and other folks around the company. 299 00:16:07,361 --> 00:16:09,211 And so just the stakes are higher. 300 00:16:10,381 --> 00:16:13,341 And so yeah, showing my work is like the biggest thing that I've 301 00:16:13,341 --> 00:16:15,302 had to, you know, being more rigorous about that. 302 00:16:16,142 --> 00:16:19,022 And even if I already kind of know the answer like of what we 303 00:16:19,022 --> 00:16:22,884 need to do, I go ask users and then like, and maybe I'm wrong 304 00:16:22,884 --> 00:16:25,804 and maybe they're correct and they show me something that I 305 00:16:25,804 --> 00:16:28,308 missed which often happens. Or even if I was right all 306 00:16:28,308 --> 00:16:31,034 along, I still have that data that I can show how the product 307 00:16:31,034 --> 00:16:33,778 should work. Right. 308 00:16:34,108 --> 00:16:37,708 I think from my experience as well, looking at these type of 309 00:16:37,708 --> 00:16:40,692 engineer, right, product engineer, I think I can see, you 310 00:16:40,692 --> 00:16:42,478 mentioned a couple of things, right? 311 00:16:42,478 --> 00:16:45,700 Like being able to influence, I think, that's kind of like very 312 00:16:45,700 --> 00:16:47,800 important because not just influencing within the 313 00:16:47,800 --> 00:16:50,934 engineering team but also to the users, the stakeholders, the 314 00:16:50,934 --> 00:16:54,745 partners and all that. The second thing is, I think 315 00:16:54,745 --> 00:16:56,470 they're always around in meetings. 316 00:16:56,470 --> 00:17:00,015 You know, people ask them to join just because they have a 317 00:17:00,015 --> 00:17:02,545 breadth of knowledge and, you know, not just the technical 318 00:17:02,545 --> 00:17:05,380 skills, but also the non-technical aspects as well. 319 00:17:05,740 --> 00:17:07,450 And they care about the users, right? 320 00:17:07,450 --> 00:17:10,778 So maybe sometimes we can see it when they draft, you know, the 321 00:17:10,778 --> 00:17:12,839 ticket, right? The issue that they're working 322 00:17:12,839 --> 00:17:16,465 on, they will put more things beyond what the PM has written, 323 00:17:16,465 --> 00:17:19,538 maybe or beyond just what the engineer has written, which is 324 00:17:19,538 --> 00:17:23,080 typically just one or two lines. So these are some of the traits 325 00:17:23,080 --> 00:17:25,395 that I see. So maybe from your observation 326 00:17:25,395 --> 00:17:29,386 as well for people in the industry, at your side, what are 327 00:17:29,386 --> 00:17:33,572 the skill gap that are still kind of like missing, you know, 328 00:17:33,572 --> 00:17:37,068 for an engineer, a pure engineer, a techies who want to 329 00:17:37,068 --> 00:17:42,752 become a product engineer more? Yeah, I think for me the, I 330 00:17:42,752 --> 00:17:45,799 would call it the fundamental primitive of product thinking is 331 00:17:45,799 --> 00:17:50,308 the user scenario. And so what is that? 332 00:17:50,308 --> 00:17:53,188 I mean, it's basically a story about, you know, the way that 333 00:17:53,548 --> 00:17:56,603 engineers are gonna interact. Or sorry, the way that users are 334 00:17:56,603 --> 00:17:57,628 gonna interact with your product. 335 00:17:58,825 --> 00:18:02,962 And so, if you're just like in a conversation with like a staff 336 00:18:02,962 --> 00:18:06,788 level engineer, you're gonna hear them talk about, well, what 337 00:18:06,788 --> 00:18:09,022 if this happens and then this happens, right? 338 00:18:09,022 --> 00:18:12,607 And they're going to tell little stories in the conversation that 339 00:18:12,607 --> 00:18:14,742 are gonna ground the conversation in something 340 00:18:14,742 --> 00:18:16,995 interesting. And that's something that 341 00:18:16,995 --> 00:18:19,685 product-minded engineers are like you have to be able to do 342 00:18:19,685 --> 00:18:23,247 that. A story would consist of a 343 00:18:23,247 --> 00:18:27,269 persona or a person who's doing the thing and then they have to 344 00:18:27,269 --> 00:18:29,025 have a motivation for why they're using your product. 345 00:18:29,615 --> 00:18:32,531 And then a sequence of steps that they go through as they use 346 00:18:32,531 --> 00:18:36,281 it. And so, you know, maybe a pure 347 00:18:36,281 --> 00:18:39,006 engineer, infrastructure engineer or like some other 348 00:18:39,006 --> 00:18:42,415 level engineer is gonna start with just thinking like, let's 349 00:18:42,415 --> 00:18:45,775 say, you're working on a coffee ordering app, right? 350 00:18:46,495 --> 00:18:49,665 And they're gonna think about the like click the pay now 351 00:18:49,665 --> 00:18:52,780 button or something, right? And then they're gonna design 352 00:18:52,780 --> 00:18:55,935 what's inside of that, what happens when you click the 353 00:18:55,935 --> 00:18:58,615 button. But that's just one very narrow 354 00:18:58,615 --> 00:19:00,865 window in the story, right? So what happens first? 355 00:19:00,865 --> 00:19:03,797 Well, first they had to like select the item and they had 356 00:19:03,797 --> 00:19:05,935 this whole ordering flow that they went through. 357 00:19:06,340 --> 00:19:09,100 How do they even get to the, to that in the first place? 358 00:19:09,100 --> 00:19:12,714 And then you start to think in terms of the conversion rate of 359 00:19:12,714 --> 00:19:15,208 that flow. Like how much, how well are 360 00:19:15,208 --> 00:19:17,806 users proceeding along that journey to get to the actual 361 00:19:17,806 --> 00:19:19,456 purchase button, which is what you want them to do? 362 00:19:20,661 --> 00:19:23,761 Maybe you should be catching state from previous interactions 363 00:19:23,761 --> 00:19:27,892 to speed up, speed it up. And so you start thinking about 364 00:19:27,892 --> 00:19:31,435 this these like, you start simulating out what the sequence 365 00:19:31,435 --> 00:19:35,149 of steps that users are doing. And that's the simulation aspect 366 00:19:35,149 --> 00:19:38,315 of the story. But then also tell me more about 367 00:19:38,315 --> 00:19:40,495 the user. Like are they repeat customer? 368 00:19:40,525 --> 00:19:43,702 Have they ordered this before? Well then maybe you've got some 369 00:19:43,702 --> 00:19:46,925 sort of favorite system that you're providing, that help them 370 00:19:46,925 --> 00:19:48,955 reorder things that they've reordered in the past and cut 371 00:19:48,955 --> 00:19:50,305 out a lot of those checkout steps. 372 00:19:51,355 --> 00:19:54,448 And then, you know, you start thinking more about the 373 00:19:54,448 --> 00:19:56,395 customer's situation and empathizing with the customer 374 00:19:56,395 --> 00:19:58,740 more deeply. Like maybe that customer is 375 00:19:58,740 --> 00:20:02,040 actually on their commute and they're gonna pick up their 376 00:20:02,040 --> 00:20:05,377 coffee on the way to work. They're in the car and like 377 00:20:05,377 --> 00:20:08,206 they're trying to interact with your multi-step checkout flow 378 00:20:08,206 --> 00:20:10,057 while driving, which is not safe. 379 00:20:10,837 --> 00:20:13,477 And so, you know, as you kind of become more and more 380 00:20:13,477 --> 00:20:15,432 product-minded, you start flushing out these stories and 381 00:20:15,432 --> 00:20:18,696 making them bigger and bigger. And then by the end, you're 382 00:20:18,696 --> 00:20:20,646 thinking, okay, well actually what about voice commands? 383 00:20:20,646 --> 00:20:22,896 Like what maybe we integrate with, voice. 384 00:20:22,896 --> 00:20:26,705 And we, now you're looking up the Siri Kit SDK, and like 385 00:20:26,705 --> 00:20:29,911 trying to figure out if you can integrate like cheaply integrate 386 00:20:29,911 --> 00:20:34,626 voice commands into your app. And so, so that's the sort of 387 00:20:34,626 --> 00:20:38,581 like in just getting out, like zooming out and getting more 388 00:20:38,581 --> 00:20:42,241 context, using the story as a way to guide you through that 389 00:20:42,241 --> 00:20:46,232 journey of like, okay, I've got a tiny little story, what 390 00:20:46,232 --> 00:20:48,536 happened before, or what's happening next? 391 00:20:48,716 --> 00:20:50,666 And then who is this person and why are they doing it? 392 00:20:50,666 --> 00:20:53,424 And so you're just kind of like adding more fluff to the story 393 00:20:53,424 --> 00:20:56,073 until you've like covered what you need to cover to make a good 394 00:20:56,073 --> 00:20:58,718 product. Yeah, to me that kind of like 395 00:20:58,718 --> 00:21:02,065 sounds doable, right, for an engineer who wants to have more 396 00:21:02,065 --> 00:21:03,625 product-minded engineer mindset, right? 397 00:21:03,625 --> 00:21:06,595 So it's like understanding the user stories, the user journey. 398 00:21:06,595 --> 00:21:08,455 Some people also say that, right? 399 00:21:08,880 --> 00:21:11,418 Understanding the persona, the impact, how they're using your 400 00:21:11,418 --> 00:21:13,687 products. But for some engineers, they 401 00:21:13,687 --> 00:21:17,017 will think this is the job of product manager, right? 402 00:21:17,017 --> 00:21:21,899 So, what they expect is like, okay, they do the this kind of a 403 00:21:21,899 --> 00:21:24,047 story, you know, scenario and all that. 404 00:21:24,437 --> 00:21:27,615 Then they will write a ticket for me and I'll just, I just try 405 00:21:27,615 --> 00:21:29,717 to understand from the ticket and implement that. 406 00:21:30,147 --> 00:21:32,659 So what do you think the challenge of this, because I can 407 00:21:32,659 --> 00:21:36,285 see so many, how should I say conflict or misunderstanding 408 00:21:36,285 --> 00:21:38,947 between product and engineer simply because of this. 409 00:21:39,277 --> 00:21:42,739 So do you have any experience on how to handle or navigate this 410 00:21:42,739 --> 00:21:46,347 kind of conflict? Yeah, no, you're absolutely 411 00:21:46,347 --> 00:21:49,286 right. I mean, there's those of us. 412 00:21:49,316 --> 00:21:53,576 So I've been in a bunch of teams where I didn't have a PM because 413 00:21:53,576 --> 00:21:55,798 I was doing like developer infrastructure, right? 414 00:21:55,798 --> 00:21:59,404 And so it's like, okay, you've got to be a product-minded 415 00:21:59,404 --> 00:22:01,768 engineer because like or someone in your team needs to be, 'cause 416 00:22:01,768 --> 00:22:06,286 there's no PMs in that. And then when I have had a PMs, 417 00:22:06,286 --> 00:22:10,265 they're often very busy and they don't think in the level of 418 00:22:10,265 --> 00:22:14,631 detail that is like there's a lot of product decisions to be 419 00:22:14,631 --> 00:22:17,161 made that are kind of underneath the level at which they 420 00:22:17,161 --> 00:22:19,985 understand and that a lot of that comes from your knowledge 421 00:22:19,985 --> 00:22:21,721 of the system that they don't have. 422 00:22:22,983 --> 00:22:25,869 And then the communication is very painful between like a 423 00:22:25,869 --> 00:22:28,379 product manager who's only thinking in terms of the 424 00:22:28,379 --> 00:22:30,273 product. Imagine like, it's almost like 425 00:22:30,273 --> 00:22:33,121 speaking a different language because the engineer, their 426 00:22:33,121 --> 00:22:35,823 brain is indexed around the system, right? 427 00:22:35,823 --> 00:22:37,863 They've got like the system diagram in their head. 428 00:22:37,863 --> 00:22:41,986 They have the UI mockups and the relationships between the 429 00:22:41,986 --> 00:22:44,865 different UI screens. And then you've got the product 430 00:22:44,865 --> 00:22:47,923 manager who's only thinking in terms of like the user stories 431 00:22:47,923 --> 00:22:50,799 and the timelines of like, okay, the user does this and then this 432 00:22:50,799 --> 00:22:53,028 and this and this. How do you communicate with 433 00:22:53,028 --> 00:22:56,247 somebody whose brain is indexed entirely differently than yours 434 00:22:56,247 --> 00:22:57,653 is? It's very painful. 435 00:22:58,503 --> 00:23:01,711 And so having a person who has both indexes in their head, even 436 00:23:01,711 --> 00:23:06,589 if they may be the, not the, you know, you may not be the deepest 437 00:23:06,589 --> 00:23:10,221 database expert, but you maybe know enough about the database 438 00:23:10,221 --> 00:23:13,863 to know that like, oh, indexing is a thing that I need to do. 439 00:23:14,703 --> 00:23:17,683 Then you can identify that non indexed, you know, reads are 440 00:23:17,683 --> 00:23:23,116 gonna be a risk, right, based on the scenarios that the PM has 441 00:23:23,116 --> 00:23:24,656 brought or the ones that you figured out. 442 00:23:25,136 --> 00:23:28,970 And so the PM may not know to focus on like the scenarios that 443 00:23:28,970 --> 00:23:30,842 are gonna be scalability problems, whereas, you know 444 00:23:30,842 --> 00:23:33,656 that. So it's really this combination 445 00:23:33,656 --> 00:23:35,306 of skills that's like incredibly powerful. 446 00:23:36,432 --> 00:23:38,592 Even product managers that I talk to who are formerly 447 00:23:38,592 --> 00:23:42,200 engineers are like, oh, I use my technical skills all the time in 448 00:23:42,200 --> 00:23:45,950 my new role because they just understand that's it's that 449 00:23:45,950 --> 00:23:48,670 combination of like two indexes in your brain that's so 450 00:23:48,670 --> 00:23:55,120 powerful. I think like an early way to 451 00:23:55,120 --> 00:24:00,128 develop these skills is to write scenario tests. 452 00:24:00,798 --> 00:24:03,101 And so maybe you're used to writing unit tests which are 453 00:24:03,101 --> 00:24:05,582 like, I'm gonna exercise some tiny little piece of 454 00:24:05,582 --> 00:24:09,765 functionality about my product. But a scenario test would be a 455 00:24:09,765 --> 00:24:13,784 test where you are actually like writing down a user scenario and 456 00:24:13,784 --> 00:24:16,954 then going through those steps. Or maybe you're writing a test 457 00:24:16,954 --> 00:24:19,653 that's just very, very likely to occur in production because 458 00:24:19,653 --> 00:24:23,386 that's what users, you know. Like if your homepage has a 459 00:24:23,386 --> 00:24:26,624 default query of your database, like maybe your Netflix, and 460 00:24:26,624 --> 00:24:30,859 there's like the homepage query is the thing that's gonna happen 461 00:24:30,859 --> 00:24:33,577 all the time. Then you write a test for that 462 00:24:33,577 --> 00:24:36,348 scenario, right? And so upleveling yourself from 463 00:24:36,348 --> 00:24:40,298 writing unit tests to writing scenario tests is a really good 464 00:24:40,298 --> 00:24:42,338 way to practice your product skills. 465 00:24:42,428 --> 00:24:45,409 And if you don't know what the scenario is to write, then go 466 00:24:45,409 --> 00:24:47,618 talk to your PM and say, hey, like I'm writing tests and I'm 467 00:24:47,618 --> 00:24:49,858 not sure. I'm writing scenario tests, I'm 468 00:24:49,858 --> 00:24:51,573 not sure exactly which ones are the most important. 469 00:24:52,233 --> 00:24:55,123 And start asking them why or start asking them like for more 470 00:24:55,123 --> 00:24:56,530 context. And then you'll build that 471 00:24:56,530 --> 00:24:58,271 muscle. Yeah. 472 00:24:58,661 --> 00:25:02,420 So I like your analogy just now about two different indexes, in, 473 00:25:02,450 --> 00:25:04,280 you know, the people's mind, right? 474 00:25:04,300 --> 00:25:07,540 So one is indexed more for, from like architectural, maybe system 475 00:25:07,540 --> 00:25:11,777 level while the PM is indexing more on the, you know, user 476 00:25:11,777 --> 00:25:13,450 journey, the impact and all that, right? 477 00:25:13,450 --> 00:25:16,076 So I think that's kind of like a good analogy that I haven't 478 00:25:16,076 --> 00:25:18,310 heard before. So I think for engineers who are 479 00:25:18,310 --> 00:25:21,400 still struggling, like what do you mean by, you know, different 480 00:25:21,400 --> 00:25:24,640 mindset so this is one analogy that I think we can use. 481 00:25:25,000 --> 00:25:26,770 So I think writing scenarios is... 482 00:25:27,446 --> 00:25:29,971 Oh, sorry. I was just, in my book, I call 483 00:25:29,971 --> 00:25:32,426 it the great re-indexing because basically like when you're 484 00:25:32,426 --> 00:25:35,663 developing a product, you start with the user journey and then 485 00:25:35,663 --> 00:25:39,836 you go to the system and it's like a kind of a bit of a 486 00:25:39,836 --> 00:25:41,766 process to get from one to the other. 487 00:25:41,766 --> 00:25:45,276 You know, it's actually, that's the great art of software 488 00:25:45,276 --> 00:25:48,266 engineering really is basically just re-indexing. 489 00:25:49,575 --> 00:25:51,889 Yeah. So I think this is also 490 00:25:51,889 --> 00:25:53,625 something that we can use practically, right? 491 00:25:53,625 --> 00:25:56,073 So whenever we are in the, like for example in the 492 00:25:56,073 --> 00:25:58,675 non-engineering discussion, we have to remind ourselves, switch 493 00:25:58,675 --> 00:26:01,100 our index. Use the other brain, probably, 494 00:26:01,100 --> 00:26:04,165 the other parts of the index to actually, you know, talk more 495 00:26:04,165 --> 00:26:06,795 rather than, you know, still at the architectural system level. 496 00:26:07,395 --> 00:26:11,229 So, yeah, writing scenarios is definitely something very easy, 497 00:26:11,229 --> 00:26:14,398 practical for engineers to step up, right, in terms of having 498 00:26:14,398 --> 00:26:17,135 product engineering mindset. But in your book, you also kind 499 00:26:17,135 --> 00:26:19,039 of like cover like four different pillars, right? 500 00:26:19,429 --> 00:26:22,719 You mentioned about Develop, Deliver, Discover, and Define. 501 00:26:22,999 --> 00:26:27,483 I think this framework is, I feel is very, you know, strong, 502 00:26:27,483 --> 00:26:31,809 so that people know what is the roadmap for them to improve or 503 00:26:31,809 --> 00:26:34,455 increase their product-minded, product mindset, right? 504 00:26:34,725 --> 00:26:38,402 So tell us about this framework. How do we actually use it and 505 00:26:38,402 --> 00:26:41,126 what do they entail, actually? Yeah. 506 00:26:42,041 --> 00:26:45,231 So this is called the Double Diamond Framework. 507 00:26:45,451 --> 00:26:48,641 And it's a process framework. So it's not a process, it's like 508 00:26:48,641 --> 00:26:50,111 a way of thinking about process, right? 509 00:26:51,071 --> 00:26:54,085 And the four stages are Discover, Define, Develop, and 510 00:26:54,085 --> 00:26:57,666 Deliver, as you said. And it's called double diamond. 511 00:26:57,666 --> 00:27:00,576 Picture two diamonds like side by side, right? 512 00:27:01,196 --> 00:27:04,276 And so like, you've got your first stage is Discover, and 513 00:27:04,276 --> 00:27:06,966 that's a very like opening up phase, right? 514 00:27:06,966 --> 00:27:09,012 You're looking all over the place to figure out what the 515 00:27:09,012 --> 00:27:12,400 heck you're gonna do. And then you are talking to 516 00:27:12,400 --> 00:27:14,466 customers, figuring out what the problems they have. 517 00:27:15,216 --> 00:27:18,008 And then you go to the Define phase, which is like defining 518 00:27:18,008 --> 00:27:21,420 the product you're gonna build that will solve their problems. 519 00:27:21,510 --> 00:27:25,220 And that's like a convergent phase because you're trying to 520 00:27:25,220 --> 00:27:27,812 like figure out exactly what you're gonna do based on the 521 00:27:27,812 --> 00:27:30,901 things. And then you get to the how 522 00:27:30,901 --> 00:27:34,253 stage, which is like the Develop stage, which is like, okay, now 523 00:27:34,253 --> 00:27:36,384 let's explore a bunch of different ways to solve, to 524 00:27:36,384 --> 00:27:39,486 build that product that we did. And that's when we're 525 00:27:39,486 --> 00:27:41,405 refactoring, starting to play with different database, 526 00:27:41,405 --> 00:27:45,872 architectures and, or depending on your domain, you know, 527 00:27:45,872 --> 00:27:47,538 whatever technical challenges that you have. 528 00:27:47,538 --> 00:27:51,093 And then it's finally Deliver, which is again, a narrowing 529 00:27:51,093 --> 00:27:56,424 phase where you're starting to polish and test and get it out 530 00:27:56,424 --> 00:28:01,113 to production and experiment. Or and like do, like to do your 531 00:28:01,113 --> 00:28:03,678 like, metrics and A/B tests and stuff like that. 532 00:28:04,638 --> 00:28:07,509 And so what's interesting about these, what's most interesting 533 00:28:07,509 --> 00:28:10,466 about these phases is, first of all, like the thing I see 534 00:28:10,466 --> 00:28:13,968 engineers do the most often that's a mistake, is they jump 535 00:28:13,968 --> 00:28:18,492 to the Develop phase, right? So they start building 536 00:28:18,492 --> 00:28:20,778 something. Is it the right something? 537 00:28:20,778 --> 00:28:24,243 Maybe, maybe not. They've kind of skipped over the 538 00:28:24,243 --> 00:28:27,198 Discover and Define stages and jump straight to the solution. 539 00:28:28,068 --> 00:28:30,108 And then they start deciding, you know, which... 540 00:28:32,500 --> 00:28:35,732 And sometimes they even skip all the way to the Deliver phase and 541 00:28:35,732 --> 00:28:38,408 they just have a solution and then they just like write that 542 00:28:38,408 --> 00:28:41,898 and then they ship it. And so I would say, first of 543 00:28:41,898 --> 00:28:44,224 all, like yeah, make sure you're building the right thing 544 00:28:44,224 --> 00:28:47,775 because, you know, there's a high cost to, you know, you're 545 00:28:47,775 --> 00:28:49,851 wasting your time by building something that's not gonna make 546 00:28:49,851 --> 00:28:53,055 an effect. And then I think the second 547 00:28:53,055 --> 00:28:57,321 thing is, like I get into a, I see a lot of arguments where one 548 00:28:57,321 --> 00:29:01,801 person is like trying to just get the thing shipped and the 549 00:29:01,801 --> 00:29:04,295 other person is still trying to explore different solutions. 550 00:29:04,855 --> 00:29:07,986 And you get these arguments and people aren't really saying 551 00:29:07,986 --> 00:29:10,835 that, but that's what you can tell that they're just sort of 552 00:29:10,835 --> 00:29:13,615 in different, mentally in different phases in the double 553 00:29:13,615 --> 00:29:16,639 diamond process. And so if you can, if you notice 554 00:29:16,639 --> 00:29:19,830 that you're having an argument with a coworker about, of this 555 00:29:19,830 --> 00:29:23,734 nature, like you're impatient or they're impatient, check in on 556 00:29:23,734 --> 00:29:25,545 like, hey, I'm in the Develop phase. 557 00:29:25,545 --> 00:29:27,435 It sounds like you're in the Define phase or whatever. 558 00:29:27,965 --> 00:29:32,281 And a good way of resolving this tension because then you can 559 00:29:32,281 --> 00:29:35,241 have an explicit conversation about where you are in the 560 00:29:35,241 --> 00:29:38,048 roadmap. Even if you don't have some 561 00:29:38,048 --> 00:29:41,799 grand process built around these four phases, you can still kind 562 00:29:41,799 --> 00:29:45,186 of use it day-to-day. Right. 563 00:29:45,216 --> 00:29:49,143 So I totally understand when you mentioned developers or 564 00:29:49,143 --> 00:29:51,649 engineers tend to jump into Develop, right? 565 00:29:51,649 --> 00:29:54,649 So simply like from the industry, I, what I can say is 566 00:29:54,649 --> 00:29:57,765 like, they're waiting for the PM to kind of like discover and 567 00:29:57,765 --> 00:30:01,297 define the thing, you know, the ticket for them to work on, they 568 00:30:01,297 --> 00:30:04,155 develop. And not only that, they stopped 569 00:30:04,155 --> 00:30:07,169 there. So the, what do you call it? 570 00:30:07,189 --> 00:30:09,902 The dis... sorry, the Deliver phase, right? 571 00:30:10,292 --> 00:30:13,658 So at the end, they also don't care so much about whether, you 572 00:30:13,658 --> 00:30:16,592 know, the features they build are used, what kind of metrics. 573 00:30:16,592 --> 00:30:19,592 You know, what's the user journey like after using the 574 00:30:19,592 --> 00:30:21,410 product. So tell us about the importance 575 00:30:21,410 --> 00:30:24,530 of this Deliver aspect as well, because I think sometimes it's 576 00:30:24,530 --> 00:30:28,063 really missing from engineers. I agree. 577 00:30:28,363 --> 00:30:31,617 I agree 100%. And I think the biggest thing I 578 00:30:31,617 --> 00:30:33,223 see people miss is discoverability. 579 00:30:34,123 --> 00:30:38,441 And so there's a sort of, you know, we mentioned scenarios 580 00:30:38,441 --> 00:30:40,173 earlier as like stories that you tell. 581 00:30:40,793 --> 00:30:45,733 And a very classic user scenario starts with discover and then 582 00:30:45,733 --> 00:30:49,444 understand and then use, right? So first of all, they have to 583 00:30:49,444 --> 00:30:51,329 discover your feature. They have to figure it out, and 584 00:30:51,329 --> 00:30:54,415 then they have to actually use it safely to accomplish their 585 00:30:54,415 --> 00:30:57,497 goals. And I see people make mistakes 586 00:30:57,497 --> 00:31:00,647 in all three of those pieces of the user journey. 587 00:31:00,647 --> 00:31:03,167 But one of the more classic ones is the discovery where it's 588 00:31:03,167 --> 00:31:06,402 like, hey, I've got my feature, but like nobody knows it exists 589 00:31:06,402 --> 00:31:09,659 and they don't find it. And the engineer isn't 590 00:31:09,659 --> 00:31:12,566 necessarily thinking in terms of that kind of like growth hacking 591 00:31:12,566 --> 00:31:15,512 mindset of like, how do I get people using my feature? 592 00:31:16,772 --> 00:31:20,422 But the thing is, you can add a discoverability hack that's just 593 00:31:20,422 --> 00:31:25,826 gonna 10x the usage of your feature at like a 10th of the 594 00:31:25,826 --> 00:31:30,094 cost of building it, right? And so it's often an extremely 595 00:31:30,094 --> 00:31:33,874 high leverage thing to be doing to, you know, like okay, you've 596 00:31:33,874 --> 00:31:36,908 got an error message. And like the solution to your 597 00:31:36,908 --> 00:31:38,526 error message is to use your feature. 598 00:31:38,526 --> 00:31:41,854 So like tell them, tell the user about your feature in the error 599 00:31:41,854 --> 00:31:44,076 message as it's a very simple discovery mechanism. 600 00:31:45,075 --> 00:31:48,473 So that's a classic. And yeah, a lot of those things 601 00:31:48,473 --> 00:31:52,335 get driven during the Deliver phase when you've kind of got 602 00:31:52,335 --> 00:31:55,518 the core thing built and now it's about putting in the 603 00:31:55,518 --> 00:31:58,353 context of like the rest of your product and making sure people 604 00:31:58,353 --> 00:32:01,905 find it and then making sure that it's safe and then having 605 00:32:01,905 --> 00:32:05,189 the metrics feedback to then understand whether it's making 606 00:32:05,189 --> 00:32:08,988 the impact that you hoped. And also, like, you know, 607 00:32:08,988 --> 00:32:12,213 tracking metrics is huge for, you know, your career as well. 608 00:32:12,213 --> 00:32:16,137 Because if you can show the impact that you've made, it 609 00:32:16,137 --> 00:32:17,987 helps your manager understand what you've done. 610 00:32:19,264 --> 00:32:20,891 Right. So, yeah, definitely tracking 611 00:32:20,891 --> 00:32:22,571 metrics is very important, right? 612 00:32:22,571 --> 00:32:25,931 So, and especially because when you want to track those metrics, 613 00:32:25,931 --> 00:32:28,795 you kind of like need to put the instrumentation, the 614 00:32:28,795 --> 00:32:31,691 observability aspects into your solution as well, right? 615 00:32:31,931 --> 00:32:34,957 'Cause it's not so easy to get a metrics if you just deploy it 616 00:32:34,957 --> 00:32:37,705 and put it out there, right? So I think, this also comes back 617 00:32:37,705 --> 00:32:39,641 to how you develop the stuff as well. 618 00:32:40,031 --> 00:32:43,696 So I think, what I think you are trying to say is like this 619 00:32:43,696 --> 00:32:46,955 framework exists but we are not asking engineers to be good in 620 00:32:46,955 --> 00:32:49,975 all of them, right? But at least know some aspects 621 00:32:49,975 --> 00:32:53,673 of them, be part of the discussion, you know, in order 622 00:32:53,673 --> 00:32:55,627 to shape the feature much better. 623 00:32:55,986 --> 00:33:00,160 How do you think the engineer should think about now you have 624 00:33:00,160 --> 00:33:02,993 these pillars now? Do I need to always be involved 625 00:33:02,993 --> 00:33:05,291 in all different phases when I build a feature? 626 00:33:05,291 --> 00:33:08,619 Or like tell us practically, how do you use this framework in our 627 00:33:08,619 --> 00:33:10,492 day-to-day life? Yeah. 628 00:33:10,987 --> 00:33:15,107 So if you are, if you don't have access to a PM, then would need 629 00:33:15,107 --> 00:33:18,047 to be involved in all four phases. 630 00:33:19,367 --> 00:33:23,485 If you do have access to a PM then, I mean, I personally get 631 00:33:23,485 --> 00:33:26,617 involved in the Discovery phase anyway because I enjoy it. 632 00:33:26,617 --> 00:33:32,857 And I also think that you can help the PM narrow down the 633 00:33:32,857 --> 00:33:35,881 possible solutions. Like there's no point in the PM 634 00:33:35,881 --> 00:33:40,674 going and asking users if like, would you like a trip to Mars if 635 00:33:40,674 --> 00:33:42,627 you can't get them to Mars, right? 636 00:33:42,627 --> 00:33:47,137 And so like helping narrow down the options and helping the PM 637 00:33:47,137 --> 00:33:50,452 focus their efforts on what matters is a role for an 638 00:33:50,452 --> 00:33:52,157 engineer early in the Discovery phase. 639 00:33:52,157 --> 00:33:55,215 And then starting with the Define phase and on to Develop 640 00:33:55,215 --> 00:33:57,607 and Deliver, the engineer's gonna get much more involved. 641 00:33:59,377 --> 00:34:07,577 I personally, have things I enjoy about all four areas, so. 642 00:34:08,678 --> 00:34:11,348 Yeah, so thanks for that addition, right? 643 00:34:11,348 --> 00:34:14,927 So I think narrowing options itself, knowing what is the 644 00:34:14,927 --> 00:34:17,862 possibility to build. Because for example also if you 645 00:34:17,862 --> 00:34:20,547 work on legacy product, right? You know, the challenges, the 646 00:34:20,547 --> 00:34:22,838 constraints, you know, with the current architecture, the 647 00:34:22,838 --> 00:34:25,906 current system. So you kind of like know what 648 00:34:25,906 --> 00:34:28,838 options that the PM has, so that you don't fight in the end. 649 00:34:30,259 --> 00:34:33,052 One of the ways that I will get involved in the Discovery phase 650 00:34:33,052 --> 00:34:38,797 as an engineer is I'll like ask the PM or the sales person or 651 00:34:38,797 --> 00:34:42,543 the like solutions architect or, you know, the forward deployed 652 00:34:42,543 --> 00:34:44,434 engineer or these sorts of people. 653 00:34:45,154 --> 00:34:48,770 Like, hey, can I tag along in your meetings or can I read the, 654 00:34:48,770 --> 00:34:51,484 can I watch the trans, video transcript or whatever? 655 00:34:52,206 --> 00:34:54,875 And really I'm just kind of immersing myself in what the 656 00:34:54,875 --> 00:34:58,617 humans are, that are using my product are doing, which is 657 00:34:58,617 --> 00:35:04,027 gonna help me make decisions later in the project when the PM 658 00:35:04,027 --> 00:35:07,597 underspecifies things, right? Or when I have insights based on 659 00:35:07,597 --> 00:35:10,921 my knowledge of the system that I can combine with that 660 00:35:10,921 --> 00:35:13,561 information. And so there's some pretty high 661 00:35:13,561 --> 00:35:16,163 leverage ways. You could have an AI now go and 662 00:35:16,163 --> 00:35:18,217 find out all the user context for you. 663 00:35:18,217 --> 00:35:21,267 Like, hey, would anybody like this feature that I'm thinking 664 00:35:21,267 --> 00:35:25,657 about building? And then just have like a LLM go 665 00:35:25,657 --> 00:35:29,457 and search for anybody that they think would be interested. 666 00:35:29,457 --> 00:35:32,227 And then now you've got some leads to reach out to, right? 667 00:35:32,437 --> 00:35:36,377 And so like it's actually pretty easy to, and relatively low work 668 00:35:37,327 --> 00:35:41,038 to just tag along with some of these other roles as an 669 00:35:41,038 --> 00:35:44,105 engineer. Sometimes you can provide some 670 00:35:44,105 --> 00:35:48,231 insight to like, especially if you're working on a technical 671 00:35:48,231 --> 00:35:51,153 product, right? Where you can provide a deeper 672 00:35:51,153 --> 00:35:54,881 understanding to your customers for the hard questions. 673 00:35:55,601 --> 00:35:59,061 And then even if you don't, even if you don't think you're going 674 00:35:59,061 --> 00:36:03,396 to provide value, that's okay. It's okay to tag along or to 675 00:36:03,396 --> 00:36:04,466 watch the video transcript, right? 676 00:36:04,496 --> 00:36:07,950 'Cause you're gonna be learning. So don't just assume that 677 00:36:07,950 --> 00:36:11,078 because you're not gonna be providing value mean that, this 678 00:36:11,078 --> 00:36:13,194 doesn't mean that you shouldn't at least understand what's going 679 00:36:13,194 --> 00:36:16,770 on there. I think that's a very good tip, 680 00:36:16,770 --> 00:36:18,674 right? So, I think even though you 681 00:36:18,674 --> 00:36:22,188 don't have something to sort of contribute, you can still learn 682 00:36:22,188 --> 00:36:25,528 from those experiences. So you mentioned something very, 683 00:36:25,528 --> 00:36:27,710 interesting, right? Engineers now themselves can 684 00:36:27,710 --> 00:36:31,086 also use LLM to kind of like learn from all those things, 685 00:36:31,086 --> 00:36:34,479 like transcript conversations. And now I think it's a good 686 00:36:34,479 --> 00:36:37,836 segue to talk about a AI impact to, you know, engineering, 687 00:36:37,836 --> 00:36:39,336 product engineering and all that. 688 00:36:39,336 --> 00:36:42,106 Because I think one aspect that people kept talking about is 689 00:36:42,106 --> 00:36:45,486 like the impact of AI. Now that we can produce code 690 00:36:45,486 --> 00:36:49,553 much faster, engineers now have more time presumably to start 691 00:36:49,553 --> 00:36:52,416 thinking about, you know, the product aspect. 692 00:36:52,506 --> 00:36:55,746 So what do you think personally for your situation, right? 693 00:36:55,896 --> 00:36:59,676 What is the impact of AI with maybe your role or maybe the way 694 00:36:59,676 --> 00:37:02,732 you see it for product engineer? Yeah. 695 00:37:03,202 --> 00:37:06,993 Yeah, I'm absolutely trying to figure this along out, along 696 00:37:06,993 --> 00:37:08,652 with everybody else at this point. 697 00:37:09,998 --> 00:37:11,458 One thing I'll say, a couple things here. 698 00:37:12,508 --> 00:37:16,615 One is at my company Temporal, product is a bottleneck right 699 00:37:16,615 --> 00:37:18,782 now. And I think it's feeling like 700 00:37:18,782 --> 00:37:23,206 increasingly a bottleneck. One of the things that I started 701 00:37:23,206 --> 00:37:27,278 to see is a lot more prototypes coming out of engineering, is 702 00:37:27,278 --> 00:37:30,478 just completely awesome, right? Like I love seeing, you know, 703 00:37:30,478 --> 00:37:34,358 all these demos every, you know, in our sprint showcase every 704 00:37:34,358 --> 00:37:38,060 couple weeks. And then like what I'm feeling 705 00:37:38,060 --> 00:37:41,282 is like, you know, everybody looks at me and they're like, 706 00:37:41,282 --> 00:37:45,062 okay, we have this demo, like, help us get this out, right? 707 00:37:45,422 --> 00:37:48,482 And I'm just like, oh God, okay. I've got so much work to do. 708 00:37:49,152 --> 00:37:54,112 And so more product skills threaded throughout the 709 00:37:54,112 --> 00:37:57,990 organization I think will really help engineers be more empowered 710 00:37:57,990 --> 00:38:00,917 to get their own prototypes out to production. 711 00:38:01,527 --> 00:38:04,077 And make those, you know, like every prototype comes with like 712 00:38:04,077 --> 00:38:06,057 a list of decisions that need to be made about it, right? 713 00:38:06,747 --> 00:38:10,257 And so it's like, how do we drive the decision making that 714 00:38:10,257 --> 00:38:15,805 it takes to get it out? And, so yeah, I would say, you 715 00:38:15,805 --> 00:38:21,127 know, what Kent Beck was saying recently about my book was that, 716 00:38:21,127 --> 00:38:25,237 you know, Drew was helping to heal the rift between product 717 00:38:25,237 --> 00:38:28,907 and engineering. And I think that's an 718 00:38:28,907 --> 00:38:32,795 interesting way of phrasing it because if you think about it, 719 00:38:32,795 --> 00:38:35,587 these are two very tightly related disciplines, right? 720 00:38:35,587 --> 00:38:37,057 The product and the engineering side. 721 00:38:37,057 --> 00:38:41,703 And there has been this artificial divide and the sides 722 00:38:41,703 --> 00:38:43,057 haven't been talking to each other. 723 00:38:43,057 --> 00:38:46,038 Like if you, one of the reasons I wrote the book was because 724 00:38:46,038 --> 00:38:49,281 there was no engineering literature about some of these 725 00:38:49,281 --> 00:38:51,025 topics. And it's like the topics are 726 00:38:51,025 --> 00:38:53,490 well known in like the design community, the product 727 00:38:53,490 --> 00:38:55,699 community. But like nobody bothered to tell 728 00:38:55,699 --> 00:38:58,797 engineers about it. It was as if we were like in 729 00:38:58,797 --> 00:39:01,407 different silos and we never talked to each other. 730 00:39:02,797 --> 00:39:07,644 And so I think there's gonna be a combination like more people 731 00:39:07,644 --> 00:39:12,296 who are, what Else van der Berg calls M-shaped people, right, 732 00:39:12,296 --> 00:39:15,144 who've got like spikes in engineering skills as well as 733 00:39:15,144 --> 00:39:18,784 spikes in product skills. And 'cause it's such a leveraged 734 00:39:18,784 --> 00:39:23,007 combination, especially in the age of AI and especially when, 735 00:39:23,007 --> 00:39:27,677 you know, engineer's coding skills are maybe a little bit 736 00:39:27,677 --> 00:39:30,664 less leveraged than they were two years ago. 737 00:39:31,924 --> 00:39:35,070 And so, you know, I think some folks will shift over to product 738 00:39:35,070 --> 00:39:38,443 but that's sort of... but I thought, I also think that 739 00:39:38,443 --> 00:39:41,386 there's an enormous potential in just getting more people who are 740 00:39:41,386 --> 00:39:43,244 hybrids. And you don't have to go all the 741 00:39:43,244 --> 00:39:44,788 way over to product to like add value. 742 00:39:45,655 --> 00:39:48,998 And I might go back, I might, I'm actually kind of jealous of 743 00:39:48,998 --> 00:39:50,753 like the engineers right now 'cause they have all these 744 00:39:50,753 --> 00:39:52,895 amazing new tools that they're getting to use. 745 00:39:52,915 --> 00:39:55,015 And I'm like, I'm kind of missing out on it. 746 00:39:55,015 --> 00:39:57,349 Like I'm using Claude Code and some, and I'm writing some 747 00:39:57,349 --> 00:39:59,929 samples and stuff. But like, it's not really, it's 748 00:39:59,929 --> 00:40:02,610 not really the same. And I'm missing out on some of 749 00:40:02,610 --> 00:40:05,532 the fun, so maybe I'll go back and be a hybrid engineer again. 750 00:40:06,866 --> 00:40:09,723 Right. So I think that's a very good 751 00:40:09,723 --> 00:40:11,577 experience that you're experiencing, right? 752 00:40:11,577 --> 00:40:14,905 So, but because we talk a lot about engineer having more 753 00:40:14,905 --> 00:40:17,833 product mindset, is there such thing as a PM being more 754 00:40:17,833 --> 00:40:19,849 technical, right? PM, you know, who could write 755 00:40:19,849 --> 00:40:21,486 code? Is this something that is also 756 00:40:21,486 --> 00:40:23,157 happening? Because again, with the 757 00:40:23,157 --> 00:40:26,607 introduction of these AI tools, now presumably, you know, PM can 758 00:40:26,607 --> 00:40:29,663 do vibe coding, you know, all these, you know, Lovable, Bolt, 759 00:40:29,663 --> 00:40:32,822 Replit kind of tools to actually build prototypes themselves as 760 00:40:32,822 --> 00:40:35,589 well. So what is your thought on this 761 00:40:35,589 --> 00:40:37,647 like PM becoming more technical as well? 762 00:40:37,647 --> 00:40:40,882 Is this something that is also happening that people should do 763 00:40:40,882 --> 00:40:44,945 as well in the industry? I think that I would 764 00:40:44,945 --> 00:40:48,033 characterize it differently. Like okay, vibe coding as a PM. 765 00:40:48,723 --> 00:40:52,134 One of the things that it gets me is, for example, I don't need 766 00:40:52,134 --> 00:40:55,503 to go to knock, need to go knock on a designer's door to like 767 00:40:55,503 --> 00:40:58,378 mock up a UI, right? Like I can vibe code that. 768 00:40:59,028 --> 00:41:03,768 And that lets me show off like ideas more rapidly without all 769 00:41:03,768 --> 00:41:07,563 that back and forth with design. Just to, again, not to like say 770 00:41:07,563 --> 00:41:10,517 that this is gonna be shipping product design, but just to like 771 00:41:10,517 --> 00:41:13,973 have something to show people. And similar with the code, like 772 00:41:13,973 --> 00:41:16,653 if I wanna underst- if I wanna show off some specific 773 00:41:16,653 --> 00:41:19,881 interaction that I'm focusing on, I can vibe code that. 774 00:41:19,881 --> 00:41:23,445 But it's not, I wouldn't call that being more technical as a 775 00:41:23,445 --> 00:41:25,643 PM. And I don't think that that's a 776 00:41:25,643 --> 00:41:27,291 way to gain technical skills as a PM. 777 00:41:27,291 --> 00:41:30,766 Like I still think you need the fundamentals of like computer 778 00:41:30,766 --> 00:41:34,011 science or, you know, system critical thinking. 779 00:41:34,791 --> 00:41:36,081 Maybe it helps with a little bit. 780 00:41:37,011 --> 00:41:39,231 But at the end of the day, like the PM isn't writing production 781 00:41:39,231 --> 00:41:42,001 code, you know. And I, without those technical 782 00:41:42,001 --> 00:41:44,421 skills, I don't see that happening. 783 00:41:45,464 --> 00:41:49,729 But that said, I do think that for PMs who do have technical 784 00:41:49,729 --> 00:41:53,486 skills, it is, it remains a very high leverage skillset. 785 00:41:53,636 --> 00:41:57,432 And like I said, like with the PMs I've been talking to who 786 00:41:57,432 --> 00:41:59,846 have technical skills, they say it's indispensable. 787 00:42:00,236 --> 00:42:03,386 And it's one of the reasons that they have been able to stand out 788 00:42:03,386 --> 00:42:07,425 among some of their peers. Yeah, so I think in the end, 789 00:42:07,425 --> 00:42:08,679 it's like two different disciplines, right? 790 00:42:08,679 --> 00:42:12,528 So some people have a good spectrum of skills from both 791 00:42:12,528 --> 00:42:14,362 disciplines. I think definitely those people 792 00:42:14,362 --> 00:42:17,147 will be highly valuable. And that's why people keep 793 00:42:17,147 --> 00:42:19,743 talking about this product engineer because now that the 794 00:42:19,743 --> 00:42:23,003 engineers, maybe part of their work has been, you know, 795 00:42:23,003 --> 00:42:25,915 automated by AI, you know, churning code and, you know, 796 00:42:25,915 --> 00:42:28,057 doing all this, you know, fancy stuff, right? 797 00:42:28,417 --> 00:42:31,306 Now actually to increase, improve on the other discipline, 798 00:42:31,306 --> 00:42:32,587 right, which is the product mindset. 799 00:42:32,737 --> 00:42:36,157 Similarly, I think it could also happen with the PM learning more 800 00:42:36,157 --> 00:42:38,555 technical stuff. But I think still these are 801 00:42:38,555 --> 00:42:42,203 probably too hard to expect one person to be good at at the same 802 00:42:42,203 --> 00:42:44,077 time, right? So, which brings me to... 803 00:42:44,883 --> 00:42:48,133 Well, let me just like say one thing, which is like you can... 804 00:42:48,133 --> 00:42:53,009 Like I said, like if you have a technical background, you can 805 00:42:53,009 --> 00:42:56,178 definitely do both. And, you know, a lot of founders 806 00:42:56,178 --> 00:42:58,622 are this way, right? Like a lot of founders don't 807 00:42:58,622 --> 00:43:01,920 have, they don't hire a PM until they're, you know, their 10th 808 00:43:01,920 --> 00:43:04,386 hire or something. And, there's just, you know, 809 00:43:04,386 --> 00:43:07,636 like, so they have to be the PM at first. 810 00:43:08,356 --> 00:43:11,560 And so I do think that there's a lot of people that can do both, 811 00:43:11,560 --> 00:43:15,700 but I don't think vibe coding is your way to gain, you know, like 812 00:43:15,700 --> 00:43:19,043 vibe coding is not the route to that technical skillset. 813 00:43:20,122 --> 00:43:20,722 Yeah. As far as I can tell. 814 00:43:20,782 --> 00:43:24,660 So I think there's a danger of, you know, missed expectation, 815 00:43:24,660 --> 00:43:27,616 right? So people now think with AI you 816 00:43:27,616 --> 00:43:30,082 can replace engineers, you know, do vibe coding. 817 00:43:30,082 --> 00:43:32,692 So I think like what you mentioned earlier is like 818 00:43:32,692 --> 00:43:34,942 production, great quality. I think this is something that 819 00:43:34,942 --> 00:43:37,812 probably sometimes it's a hit and miss using all these AI 820 00:43:37,812 --> 00:43:39,910 tools. We can still hear so many 821 00:43:39,910 --> 00:43:41,722 security issues or maybe bugs happening. 822 00:43:42,112 --> 00:43:44,369 But I think one challenge as well, like how do you evolve the 823 00:43:44,369 --> 00:43:46,630 system? Because I think AI now is kind 824 00:43:46,630 --> 00:43:49,312 of like not good in refactoring its own solution. 825 00:43:49,312 --> 00:43:52,878 Maybe they can give you hints of what the system is all about, 826 00:43:52,878 --> 00:43:56,016 but still you need a technical ability to actually shape the 827 00:43:56,016 --> 00:43:59,563 system. So people talk about, you know, 828 00:43:59,563 --> 00:44:02,401 maybe ratio of a product engineer. 829 00:44:02,731 --> 00:44:05,728 Sorry, ratio of product manager and, you know, engineering, 830 00:44:05,728 --> 00:44:07,924 right? So I think this tends to change 831 00:44:07,924 --> 00:44:09,541 as well after the introduction of AI. 832 00:44:09,541 --> 00:44:10,981 So what do you think is a good ratio now? 833 00:44:10,981 --> 00:44:14,324 Because if you're saying now you are also kind of like still the 834 00:44:14,324 --> 00:44:16,831 bottleneck and engineers now churning more code. 835 00:44:16,891 --> 00:44:19,900 So what do you think is a typical good ratio or how should 836 00:44:19,900 --> 00:44:21,841 people shape their team structure? 837 00:44:23,372 --> 00:44:25,957 Yeah, that's a good question. I don't have a ratio for you and 838 00:44:25,957 --> 00:44:31,549 it'll depend on the company. I feel like there needs to be 839 00:44:31,549 --> 00:44:35,370 more product, total. Product thinking total in the 840 00:44:35,370 --> 00:44:37,795 orgs than there is today either ratio. 841 00:44:38,345 --> 00:44:42,515 Now whether that comes in more engineers becoming hybrids or 842 00:44:42,515 --> 00:44:45,970 more PMs being hired? I don't know the answer. 843 00:44:46,720 --> 00:44:50,395 But, yeah, it's gonna be a profound shift, like. 844 00:44:51,221 --> 00:44:53,951 And the good news is like, you know, in a lot of these 845 00:44:53,951 --> 00:44:59,002 companies, like the product manager role is one of the few 846 00:44:59,002 --> 00:45:03,381 roles that's paid on the same pay ladder as the engineering 847 00:45:03,381 --> 00:45:08,368 role. And so, it's like, it also has, 848 00:45:08,368 --> 00:45:12,014 involves rare skills that are hard to acquire. 849 00:45:12,991 --> 00:45:17,876 And so yeah, I would say that's a good sign for engineers who 850 00:45:17,876 --> 00:45:19,806 are... You know, I think there's like 851 00:45:19,806 --> 00:45:22,298 three skill sets, right? There's like people skills, 852 00:45:22,298 --> 00:45:25,076 there's system skills, and then there's product skills. 853 00:45:26,036 --> 00:45:29,949 And like you probably are going to need all three of those, but 854 00:45:29,949 --> 00:45:34,885 then you can kind of pick like maybe two of them to... like 855 00:45:34,885 --> 00:45:39,997 it's gonna be harder and harder to get by with just one of the 856 00:45:39,997 --> 00:45:42,997 three that you're spiked on as you become more senior. 857 00:45:43,277 --> 00:45:47,787 So looking to pick two of them is probably a good idea. 858 00:45:49,069 --> 00:45:51,364 Yeah, so I think that's very good tips, right? 859 00:45:51,364 --> 00:45:56,008 So people, system and product. So I think now if AI can help a 860 00:45:56,008 --> 00:45:59,426 lot in terms of, you know, churning out code, but we all 861 00:45:59,426 --> 00:46:03,472 know, right, as engineer also we know like writing code is not 862 00:46:03,472 --> 00:46:07,288 the only thing that matters. You know, you have still all 863 00:46:07,288 --> 00:46:10,044 this collaboration, defining what the right thing to build, 864 00:46:10,044 --> 00:46:12,295 right? And also the other aspects like 865 00:46:12,295 --> 00:46:14,314 for example, communication, influencing and all that. 866 00:46:14,644 --> 00:46:18,050 So do you think there's a good tips that you can give to 867 00:46:18,050 --> 00:46:19,902 engineering leaders or maybe stakeholders? 868 00:46:20,039 --> 00:46:23,184 You know, because the expectation they have now is 869 00:46:23,184 --> 00:46:27,137 like using AI we can improve, you know, the productivity of 870 00:46:27,137 --> 00:46:29,921 engineering by a lot, right? Even they're thinking about 871 00:46:29,921 --> 00:46:31,289 laying off engineers and all that. 872 00:46:31,689 --> 00:46:35,502 So what tips that you can give maybe to, you know, engineering 873 00:46:35,502 --> 00:46:39,935 leaders or maybe these executives to maybe correct 874 00:46:39,935 --> 00:46:44,725 their mindset in a way. Is there some something that you 875 00:46:44,725 --> 00:46:48,047 can chip in here as well? Yeah, sure. 876 00:46:48,667 --> 00:46:52,212 I mean, if you're not already doing it, you know, asking why a 877 00:46:52,212 --> 00:46:55,375 lot is, is a good practice of just making sure you're bringing 878 00:46:55,375 --> 00:46:57,645 in more and more context about what you're really trying to do. 879 00:46:59,131 --> 00:47:01,378 Switching your viewpoint constantly between the system 880 00:47:01,378 --> 00:47:05,125 and the users, going back between those two indexes we 881 00:47:05,125 --> 00:47:08,412 talked about, that's not an easy thing to do and you can easily 882 00:47:08,412 --> 00:47:09,961 kind of get stuck in one or the other. 883 00:47:09,961 --> 00:47:13,415 And so just switching, realizing when you need information from 884 00:47:13,415 --> 00:47:17,875 the other index is an important skill. 885 00:47:18,912 --> 00:47:22,740 More writing down the stories and scenarios and then sharing 886 00:47:22,740 --> 00:47:26,084 those with your team and using that as a mechanism to get 887 00:47:26,084 --> 00:47:28,716 alignment, right? So one of the powerful aspects 888 00:47:28,716 --> 00:47:32,676 of stories that we didn't talk about yet is everybody 889 00:47:32,676 --> 00:47:37,020 understands stories. And so not only are they a good 890 00:47:37,020 --> 00:47:39,952 way to discover potential problems that you might need to 891 00:47:39,952 --> 00:47:42,537 overcome in your product, but they're also a good way to 892 00:47:42,537 --> 00:47:45,057 communicate to other people whose brains all work 893 00:47:45,057 --> 00:47:48,334 differently than yours. But the story is that sort of 894 00:47:48,334 --> 00:47:51,576 medium of communication or that, you know, we, a lot of us, you 895 00:47:51,576 --> 00:47:54,520 know, grew up hearing bedtime stories or reading children's 896 00:47:54,520 --> 00:47:56,119 books. And so we've all read stories 897 00:47:56,119 --> 00:47:58,283 from an early age. And so a good way to communicate 898 00:47:58,283 --> 00:48:01,257 to people, and it's a good way to get alignment across a lot of 899 00:48:01,257 --> 00:48:04,143 people if you're a leader of like, hey, we all agree that 900 00:48:04,143 --> 00:48:05,997 these are the scenarios that we care most about. 901 00:48:06,867 --> 00:48:09,087 And then you share those stories and people nitpick them. 902 00:48:09,087 --> 00:48:12,892 And then you've got your like compendium of stories or your 903 00:48:12,892 --> 00:48:15,739 like document full of stories that are like, these are the 904 00:48:15,739 --> 00:48:17,307 ones we're going for, for this milestone. 905 00:48:17,307 --> 00:48:20,307 It's a great leadership technique. 906 00:48:21,117 --> 00:48:24,189 And then finally, I mean, you know, finding ways for yourself 907 00:48:24,189 --> 00:48:26,827 and for your team to engage with the users. 908 00:48:27,922 --> 00:48:33,170 Customer support is one way. One of the things that I see 909 00:48:33,170 --> 00:48:36,624 commonly missed is, especially on consumer facing businesses, 910 00:48:36,624 --> 00:48:41,107 is the walls go up because there's so many users and 911 00:48:41,107 --> 00:48:44,014 they've got so much feedback and it's just so much noise, right? 912 00:48:44,014 --> 00:48:48,174 And people have their hot takes. And you can't get work done as 913 00:48:48,174 --> 00:48:51,572 an engineer if you're constantly dealing with like customer 914 00:48:51,572 --> 00:48:53,504 input. You know, it's a little bit 915 00:48:53,504 --> 00:48:56,389 easier on a, on like a business-to-business kind of B2B 916 00:48:56,389 --> 00:48:59,789 thing, but still. And even on an internal tools 917 00:48:59,789 --> 00:49:03,790 team, it can be distracting. And so a lot of engineers 918 00:49:03,790 --> 00:49:07,244 instinctively put up walls. What that means is they lose 919 00:49:07,244 --> 00:49:09,182 sight of what the users actually want. 920 00:49:10,453 --> 00:49:14,373 And then that causes problems. Like there was this, recently, I 921 00:49:14,373 --> 00:49:18,897 drive a Lucid Air, Lucid the car brand, electric car brand. 922 00:49:18,897 --> 00:49:23,884 And I drive a Lucid Air. And the company was having a lot 923 00:49:23,884 --> 00:49:27,416 of quality issues, right? Just with their software, like 924 00:49:27,416 --> 00:49:30,052 the hardware, the, everything about the drive was great, but 925 00:49:30,052 --> 00:49:31,456 the software, there were software problems. 926 00:49:32,536 --> 00:49:34,036 It was hard to give them feedback. 927 00:49:34,036 --> 00:49:37,816 Like it was like... and so they set up this email that you could 928 00:49:37,816 --> 00:49:40,156 just, email address you could, that users could just send 929 00:49:40,156 --> 00:49:43,264 feedback to it. And then they had an AI sift 930 00:49:43,264 --> 00:49:46,189 through all of the feedback and figure out what the most 931 00:49:46,189 --> 00:49:48,096 important and most frequent things were, and then present 932 00:49:48,096 --> 00:49:51,741 that to the engineering team. And they made this, they just 933 00:49:51,741 --> 00:49:53,570 made this big like quality release and everybody's really 934 00:49:53,570 --> 00:49:55,612 excited about it and really happy about it 'cause it's 935 00:49:55,612 --> 00:49:58,216 fixing so many problems. And they had just, frankly like 936 00:49:58,216 --> 00:50:02,006 the trick was just to like not lose the connection with, I mean 937 00:50:02,006 --> 00:50:05,429 I'm probably minimizing some of the engineering stuff that 938 00:50:05,429 --> 00:50:09,195 happened, but like, 'cause I'm not at the company, but they 939 00:50:09,195 --> 00:50:11,679 just found a way to reconnect with their users. 940 00:50:11,739 --> 00:50:14,917 And so that was, that would be my top advice is just like, make 941 00:50:14,917 --> 00:50:17,954 sure you're staying connected with the users and then finding 942 00:50:17,954 --> 00:50:22,169 a way to balance the randomness of it from the, the feedback. 943 00:50:22,469 --> 00:50:27,594 And it could be like getting reports from your support team, 944 00:50:28,055 --> 00:50:30,297 to make sure that you're, they're passing things through 945 00:50:30,297 --> 00:50:32,684 to you. It could be lots of things, but 946 00:50:32,684 --> 00:50:35,105 just find a creative way to, to stay connected. 947 00:50:36,338 --> 00:50:38,653 Yeah, I think those are very good tips, right? 948 00:50:38,653 --> 00:50:41,533 I would say maybe if I can just, mention some of them. 949 00:50:41,863 --> 00:50:45,778 Like thinking more about whys, start writing more scenarios 950 00:50:45,778 --> 00:50:48,953 based kind, write more documents, you know, documenting 951 00:50:48,953 --> 00:50:51,193 all this user journey and scenario. 952 00:50:51,193 --> 00:50:53,833 Because I think that's a good way to actually collaborate and 953 00:50:53,833 --> 00:50:57,403 align your expectations with stakeholders, product and 954 00:50:57,403 --> 00:50:59,510 engineers. And yeah, engage with the users 955 00:50:59,510 --> 00:51:01,102 more. I think this is quite 956 00:51:01,102 --> 00:51:03,607 straightforward, but I think sometimes we neglect doing it. 957 00:51:04,027 --> 00:51:07,709 So maybe now the advice for junior engineers, because I know 958 00:51:07,709 --> 00:51:10,717 that you have been around in the industry, you understand the 959 00:51:10,717 --> 00:51:13,867 impact of AI. You also see the kind of product 960 00:51:13,867 --> 00:51:17,167 mindset needed. Some juniors, you know, may have 961 00:51:17,167 --> 00:51:20,181 difficulty now to find a job simply because of, you know, 962 00:51:20,181 --> 00:51:24,091 this AI thing happening. So what will be your good advice 963 00:51:24,091 --> 00:51:27,873 for juniors now because they're new to in the industry, they're 964 00:51:27,873 --> 00:51:31,359 not strong enough yet at the engineering level, but at the 965 00:51:31,359 --> 00:51:33,621 same time people now expect them to have more product thinking. 966 00:51:33,621 --> 00:51:36,797 Is there such practical tips for them that you can give them as 967 00:51:36,797 --> 00:51:40,327 well? Yeah, this is a great question. 968 00:51:41,083 --> 00:51:43,453 So I'll do my best being not a junior engineer anymore. 969 00:51:43,813 --> 00:51:47,683 So like hopefully this doesn't come across as tone deaf. 970 00:51:48,853 --> 00:51:53,013 One of the things, okay, so imagine you're doing a quiz, and 971 00:51:53,013 --> 00:51:56,229 on the one hand, let's say you're doing a multiple choice 972 00:51:56,229 --> 00:51:59,084 quiz. And on the other hand, it's a 973 00:51:59,084 --> 00:52:01,604 freeform quiz where you have to like type the answer, right? 974 00:52:02,506 --> 00:52:06,971 You're gonna learn better in the freeform quiz because in the 975 00:52:06,971 --> 00:52:10,183 multiple choice quiz, you can just look over the answers and 976 00:52:10,183 --> 00:52:13,326 you can see, oh, well it's gotta be this one 'cause it can't be 977 00:52:13,326 --> 00:52:18,113 those other three. And so a lot of that work of 978 00:52:18,113 --> 00:52:22,298 generating an answer was done for you by the author of the 979 00:52:22,298 --> 00:52:25,965 quiz. And generative AI is effectively 980 00:52:25,965 --> 00:52:29,573 doing that for you. It's basically like reducing 981 00:52:29,573 --> 00:52:33,298 something that was previously, like something you had to work 982 00:52:33,298 --> 00:52:34,928 hard at to like a multiple choice quiz. 983 00:52:36,345 --> 00:52:39,295 But you are also a generative intelligence. 984 00:52:39,849 --> 00:52:43,517 And so, and that's an important, I still feel like that's a very 985 00:52:43,517 --> 00:52:48,105 important way to train and force yourself to do. 986 00:52:48,105 --> 00:52:50,558 And so even if you've got something that could give you 987 00:52:50,558 --> 00:52:53,715 the answers, you know, sometimes not using it or thinking 988 00:52:53,715 --> 00:52:57,081 critically of at least thinking critically and editing what it 989 00:52:57,081 --> 00:53:00,859 did, I think it's gonna continue to be important and it's gonna 990 00:53:00,859 --> 00:53:04,319 differentiate the people who have a like steadier growth to 991 00:53:04,319 --> 00:53:08,591 their career and like ramp up to the level of getting a new job 992 00:53:08,591 --> 00:53:13,883 versus people who kind of stay stuck at this sort of like intro 993 00:53:13,883 --> 00:53:18,253 level, entry level skillset. And then I think the second 994 00:53:18,253 --> 00:53:20,977 thing is like you could do two things with your extra time. 995 00:53:20,977 --> 00:53:23,347 So, okay, you're, you can ship more code now, right? 996 00:53:24,247 --> 00:53:27,859 You can write more, or if you haven't gotten a job yet, you 997 00:53:27,859 --> 00:53:31,030 can write more apps. And that's a good thing to do, 998 00:53:31,030 --> 00:53:32,605 you know, just like doing more of that. 999 00:53:32,605 --> 00:53:37,549 But also consider some of the time that that's freed up to 1000 00:53:37,549 --> 00:53:41,353 improve your skillset. You know, like don't just do 1001 00:53:41,353 --> 00:53:46,077 more code with the extra tools that you have, but develop some 1002 00:53:46,077 --> 00:53:49,215 of these higher level skills such as product skills, 1003 00:53:49,215 --> 00:53:51,575 collaboration skills. Ownership skills is another one 1004 00:53:51,575 --> 00:53:54,695 that we haven't talked about, but just skills of like getting 1005 00:53:54,695 --> 00:53:56,755 things done and seeing them through end-to-end. 1006 00:53:57,919 --> 00:54:01,469 Those are all good ways to upskill. 1007 00:54:02,319 --> 00:54:04,789 And then be ready for somebody to hire you. 1008 00:54:05,714 --> 00:54:08,798 So yeah, see things through, don't just write the first 1009 00:54:08,798 --> 00:54:10,284 prototype and then move on to something else. 1010 00:54:11,453 --> 00:54:14,419 Yeah. Again, another analogy I haven't 1011 00:54:14,419 --> 00:54:18,087 heard before about, you know, using quiz versus the freeform 1012 00:54:18,087 --> 00:54:21,703 kind of like quiz, right, to kind of like explain about this. 1013 00:54:21,973 --> 00:54:24,791 'Cause, yeah, I believe if you use a lot more of these AI 1014 00:54:24,791 --> 00:54:26,963 tools, yes, you're just giving given options. 1015 00:54:26,963 --> 00:54:28,493 Sometimes it's just one option, right? 1016 00:54:29,063 --> 00:54:32,337 Until you criticize it, and ask it differently in the different 1017 00:54:32,337 --> 00:54:34,194 prompts, maybe ask them to tweak something. 1018 00:54:34,554 --> 00:54:37,580 So if you don't train that muscles, definitely maybe we 1019 00:54:37,580 --> 00:54:39,564 don't even have a multiple choice quiz. 1020 00:54:39,564 --> 00:54:43,126 It's like one way quiz that you just, you know, clicking on and 1021 00:54:43,126 --> 00:54:44,304 on, right? Like a wizard. 1022 00:54:45,084 --> 00:54:47,664 But also I think the other thing is like shipping is definitely 1023 00:54:47,664 --> 00:54:50,424 important, but also don't forget about the other aspects, right? 1024 00:54:50,424 --> 00:54:53,296 I think the good thing now for me at least personally with AI, 1025 00:54:53,296 --> 00:54:56,934 I can ask all random questions that I'm interested in when 1026 00:54:56,934 --> 00:55:00,371 working on something that kind of like forces you to also learn 1027 00:55:00,371 --> 00:55:02,556 something new, right? And if you're interested, you 1028 00:55:02,556 --> 00:55:04,586 can dig deeper, you know, through other materials, 1029 00:55:04,586 --> 00:55:07,052 resources, and all that, including your book, which I 1030 00:55:07,052 --> 00:55:10,496 find there are a lot of practical tips for engineers to 1031 00:55:10,496 --> 00:55:12,656 start having this product thinking mindset. 1032 00:55:12,656 --> 00:55:15,706 It's not like a theory thing, but more practical steps that 1033 00:55:15,706 --> 00:55:18,656 people can find as well. So speaking about that, as we 1034 00:55:18,656 --> 00:55:21,244 move towards our, you know, end of conversation, is there 1035 00:55:21,244 --> 00:55:24,619 anything important in your book that we haven't really covered 1036 00:55:24,619 --> 00:55:30,067 today? Well, I hope so. 1037 00:55:30,447 --> 00:55:34,177 Yeah, I mean, it's, so the book is like, really, it's framed 1038 00:55:34,177 --> 00:55:37,677 around these four pillars that you asked me about earlier to, 1039 00:55:37,677 --> 00:55:43,182 you know, Discover, Define. And it's showing how product 1040 00:55:43,182 --> 00:55:47,917 skills are used at all four like stages in the journey. 1041 00:55:48,687 --> 00:55:52,973 And so it covers, you know, topics from product architecture 1042 00:55:52,973 --> 00:55:58,649 to error messages, which is one of my favorite topics of like 1043 00:55:58,649 --> 00:56:03,067 writing good error messages and that are actionable and help, 1044 00:56:03,067 --> 00:56:07,882 actually help users. And prioritization. 1045 00:56:08,740 --> 00:56:09,730 Yeah, there's lots of good stuff. 1046 00:56:10,030 --> 00:56:13,918 Dogfooding so like using your own product and just how to 1047 00:56:13,918 --> 00:56:15,955 write scenarios better. So there's a bunch of different 1048 00:56:15,955 --> 00:56:17,059 topics. It's sort of a, somebody called, 1049 00:56:17,059 --> 00:56:20,277 one of my readers called it the speedrun your product thinking. 1050 00:56:20,547 --> 00:56:23,517 So it's supposed to be very practical of like, you know, 1051 00:56:23,517 --> 00:56:26,462 much more applied to the engineering role than something 1052 00:56:26,462 --> 00:56:29,587 you would read from like the design or the product community. 1053 00:56:30,428 --> 00:56:33,438 So yeah, there's a bunch of stuff, but I don't know that 1054 00:56:33,438 --> 00:56:37,254 there's any one thing that stands out as, critical to talk 1055 00:56:37,254 --> 00:56:40,866 about now. Yeah, so I think, yeah, 1056 00:56:40,866 --> 00:56:44,412 dogfooding, thanks for sharing that because I think some 1057 00:56:44,412 --> 00:56:46,092 engineers don't actually use the products. 1058 00:56:46,833 --> 00:56:49,501 For example, so sometimes if you build B2B, right, sometimes it's 1059 00:56:49,501 --> 00:56:51,213 also difficult for you to get access to. 1060 00:56:51,213 --> 00:56:54,403 But always don't forget if you have a chance, dogfood your 1061 00:56:54,403 --> 00:56:57,039 product. Use your product because you can 1062 00:56:57,039 --> 00:56:59,893 empathize with the users experience, which is you, 1063 00:56:59,893 --> 00:57:02,823 yourself, and try to improve your product thinking as well. 1064 00:57:03,513 --> 00:57:05,823 So Drew, thank you so much for sharing all this. 1065 00:57:05,823 --> 00:57:08,633 I hope people check out your book, especially engineers who 1066 00:57:08,633 --> 00:57:11,383 are now trying to become much more product-minded, because 1067 00:57:11,383 --> 00:57:13,983 it's very important skill in this AI age. 1068 00:57:14,418 --> 00:57:18,482 I have one last question for you which is like a tradition in my 1069 00:57:18,482 --> 00:57:20,498 podcast. I call this a three technical 1070 00:57:20,498 --> 00:57:22,917 leadership wisdom. Think of it just like an advice 1071 00:57:22,917 --> 00:57:25,939 you wanna give to the listeners to, you know, close this. 1072 00:57:26,359 --> 00:57:28,459 Is there any version that you can share with us today? 1073 00:57:29,829 --> 00:57:34,012 Yeah. So I guess number one would be 1074 00:57:34,012 --> 00:57:38,707 to have metacognitive skills, which by that, I would mean 1075 00:57:38,707 --> 00:57:42,407 thinking about thinking. Like stepping back and thinking, 1076 00:57:42,407 --> 00:57:45,832 what am I good at? What am I not good at? 1077 00:57:46,412 --> 00:57:51,138 What do I need to improve? What do I need to, what is like 1078 00:57:51,138 --> 00:57:56,095 my, what are my superpowers and where is it that I am the most 1079 00:57:56,095 --> 00:58:00,914 leveraged as an employee? I think it's just so critical to 1080 00:58:00,914 --> 00:58:03,049 just be stepping back sometimes and thinking about how you 1081 00:58:03,049 --> 00:58:06,123 think. And this can, if reflect by 1082 00:58:06,123 --> 00:58:08,319 being, having a conversation with your manager. 1083 00:58:09,279 --> 00:58:12,686 Like, hey, like this is the kind of or like somebody you're 1084 00:58:12,686 --> 00:58:14,709 thinking of like going to workforce. 1085 00:58:14,739 --> 00:58:17,409 Like, Hey, here's my skillset. Like what do you think of this? 1086 00:58:17,409 --> 00:58:20,685 Like this is what I'm good at, this is what I don't love as 1087 00:58:20,685 --> 00:58:23,540 much. And then also using that to 1088 00:58:23,540 --> 00:58:26,254 decide, like there's times in your career where you wanna 1089 00:58:26,254 --> 00:58:29,294 double down on your strengths and there's times in your career 1090 00:58:29,294 --> 00:58:30,850 where you wanna show up your weaknesses. 1091 00:58:31,500 --> 00:58:36,036 And just thinking strategically about that can go a long way 1092 00:58:36,036 --> 00:58:39,380 towards making sure that you're happy and productive. 1093 00:58:40,430 --> 00:58:46,407 So that would be one. I think two is building 1094 00:58:46,407 --> 00:58:52,274 ownership skills. And by that I mean like I said 1095 00:58:52,274 --> 00:58:56,419 earlier, seeing things through and being accountable to the 1096 00:58:56,419 --> 00:58:58,761 outcomes is just always critical. 1097 00:58:58,761 --> 00:59:05,949 And it's the thing that is the least, is the thing that the 1098 00:59:05,949 --> 00:59:11,121 like LLMs are like the furthest away for being able to do. 1099 00:59:12,774 --> 00:59:16,371 One of the fun things about ownership skills is that you 1100 00:59:16,371 --> 00:59:20,978 been, can be more in control of your own destiny, right? 1101 00:59:21,158 --> 00:59:25,374 Like you can work on fewer failed products and things like 1102 00:59:25,374 --> 00:59:28,410 that because you're the one who can see them through. 1103 00:59:29,480 --> 00:59:32,110 And so that would be my second one. 1104 00:59:33,410 --> 00:59:37,911 And the third one is just take the time, take some percentage 1105 00:59:37,911 --> 00:59:41,931 of your time to getting better, right? 1106 00:59:41,991 --> 00:59:45,543 Like at being curious. It could be learning more. 1107 00:59:45,543 --> 00:59:47,253 It could be learning about this whole new AI thing. 1108 00:59:47,313 --> 00:59:51,910 It could be going and figuring out what this Moltbot thing is, 1109 00:59:51,910 --> 00:59:54,783 Moltbook thing is, you know, whatever, whatever. 1110 00:59:54,813 --> 00:59:58,593 Just being curious. It could be about practicing. 1111 00:59:58,653 --> 01:00:01,413 It could be reading a book or a blog. 1112 01:00:02,264 --> 01:00:04,987 But allocate a percentage of your, don't let the company that 1113 01:00:04,987 --> 01:00:12,261 you work for take away your time to becoming better in your 1114 01:00:12,261 --> 01:00:14,201 career. You don't let them overload you 1115 01:00:14,201 --> 01:00:16,919 to the extent that you're not still learning and not getting 1116 01:00:16,919 --> 01:00:21,364 better. Yeah, so I think that's the last 1117 01:00:21,364 --> 01:00:22,908 tip there always, very important, right? 1118 01:00:23,478 --> 01:00:25,698 Sometimes also this is also my perspective, right? 1119 01:00:25,698 --> 01:00:30,198 So don't also let the company you work at kind of like drive 1120 01:00:30,198 --> 01:00:32,738 where you should be, right? What you should learn, right? 1121 01:00:32,753 --> 01:00:35,473 So for example, if you're working, I dunno, in financial 1122 01:00:35,473 --> 01:00:38,406 industry, you always learn about financial, but also like maybe 1123 01:00:38,406 --> 01:00:41,314 spend time to actually, you know, learn other aspects of 1124 01:00:41,314 --> 01:00:44,226 other jobs as well. Because one day it might come 1125 01:00:44,226 --> 01:00:48,010 handy for your next career. So Drew, thank you so much for 1126 01:00:48,010 --> 01:00:50,125 your time today. If people want to connect with 1127 01:00:50,125 --> 01:00:53,050 you, find you online, ask you more about, you know, 1128 01:00:53,050 --> 01:00:55,784 product-minded engineering mindset, is there a place where 1129 01:00:55,784 --> 01:00:58,421 they can find you online? Yeah. 1130 01:00:58,421 --> 01:01:01,701 So I have a blog on Substack at drewhoskins.substack.com. 1131 01:01:03,371 --> 01:01:06,319 You can connect with me there. You can also reach out on 1132 01:01:06,319 --> 01:01:08,919 LinkedIn. I understand that LinkedIn 1133 01:01:08,919 --> 01:01:13,370 doesn't always let you include a message depending on the tier of 1134 01:01:13,370 --> 01:01:19,119 account that you have, but I will try to connect with you and 1135 01:01:19,119 --> 01:01:23,278 see if you want to chat or have feedback about the book or 1136 01:01:23,278 --> 01:01:25,555 looking for advice. You know, I'm pretty open on 1137 01:01:25,555 --> 01:01:27,278 that platform. Right. 1138 01:01:27,368 --> 01:01:28,958 So thank you so much for writing this book. 1139 01:01:28,958 --> 01:01:32,300 I think this is one of the rare materials that engineers can do 1140 01:01:32,300 --> 01:01:35,143 to upskill themselves. You know, coming back to your 1141 01:01:35,143 --> 01:01:37,385 theme, you know, improving yourself, time to learn 1142 01:01:37,385 --> 01:01:39,753 something outside of just the engineering aspects. 1143 01:01:39,933 --> 01:01:43,503 I know that we all talk about AI these days, but I think product 1144 01:01:43,503 --> 01:01:46,293 mindset is definitely very critical in this era. 1145 01:01:46,623 --> 01:01:48,573 And yeah, and I hope people check out the book. 1146 01:01:48,573 --> 01:01:50,853 So thank you so much again, Drew, for this conversation. 1147 01:01:51,735 --> 01:01:53,235 Thanks Henry. I loved your questions. 1148 01:01:53,355 --> 01:01:54,345 They're really thoughtful.