Den Delimarsky: What Makes for Successful Products! 🎁

Hi everybody. Today I chat with Den Delimarsky, product manager, engineer, reverse engineer of things, and a whole lot more. My goal was to talk to him about all of his really fun side projects around taking the Halo video games and making it easy for you to visualize your game statistics in them. We instead deviated and talked about some other really fun topics.

Instead, we talked about why some products succeed, why some products fail, what it means to have a great product, and what the role of engineering and product management is in building great products, especially when we have AI breathing down our necks and doing some really great work without having to have all the skills that traditionally went into engineering and product management. We cover a whole lot more as well, so you don't want to miss it. It's a great topic. Pull up a chair, stick around, it's going to be fun. All right, Den, it is great to meet with you online.

I believe, and I think we chatted about it just before the call, that you and I met in real life on the Microsoft campus a long time ago, maybe 12 or 13 years ago. Beyond 10 years is just long-time-ago territory, so I have no idea anymore. It's great to catch up with you again after all this time, and of course I've been following your work ever since then as well. So in many ways I feel like I know you really well through your work, even though I haven't spoken to you directly until right now.

Yeah, I'm excited to be here. Thank you for having me, and it goes both ways. By the way, Kirupa, I like your website. Folks, if you have not checked out his website yet, go do that right now. Pause this podcast, go check it out, because if you're looking for somebody who has both design and engineering chops, Kirupa is your man. We talk a little bit more about this technical content creation in the world of AI later on as well, because it raises an interesting question about what the next 20 years of doing this work look like.

You've been writing tech for a long time too, so I'd be curious to hear what your future version of all of this looks like as well.

But before we get to that, who are you, and how did you get started in tech? That's my favorite question to ask whenever I'm in these conversations.

Yeah, that's going to be a long, long story, but I'm...

And we have time. We have time for the full, long answer.

I like that about podcasts. So we're pushing the bounds. I'm Den. I'm a product manager at Microsoft. Before that I've done a couple of other things. I've been at a startup. I've worked at another large company that shall remain unnamed. Before that I was at Microsoft twice, actually, so this is my third time coming back. I boomeranged twice back to the company. You explore things, realize it wasn't that bad, and then end up joining again. I've been in the security space for the past, like close going on two years now. So, I work on a team that builds the identity SDK.

So if you're using any kind of auth in your apps, websites that use Microsoft Entra ID, that's, that's my team. But before that, you know, you asked like how did I start that? I want to say, in the most kind of typical cliche fashion for somebody working in Tech, that it was like starting from the early childhood, like when I was about like seven, eight years old, something around that. As you said, you know, once you go past a decade back, like it's all a blur,.

But I think my parents were the ones that kind of instilled in me like, hey, there's this cool thing called the computer, you should learn how to use it. And luckily, like we were not a wealthy family by any stretch of the imagination, but in our house we always had, like growing up, there was a computer like one of those like old 486 machines that are just like running like what? Like Windows 95 I think. Even before that we had a box that was like a Soviet knockoff of an IBM machine that ran like some quasi DOS system. That was kind of cool because you could run this.

I forget the name of the game, but it was basically this like bartender that has to jump between like different levels and like pick up like beer bottles and then put the beer bottle empty beer Bott, like it. It was just this very fun game and I remember spending a lot of time on it with these like 5 inch floppy discs. That you know you. You ask people now, what's a floppy disc? That's another podcast for you. But so back then this was kind of what spurred my interest in technology and I was like, oh, this is kind of cool.

What happens if I want to build something for this computer? What if I want to build this game? And that's when I started learning Visual Basic and that was the gateway to me realizing that I actually want to do this long term. Because Visual Basic 6, that was, I think, the first time that I saw like I can drag buttons on a form and like if I program it, I say if you click this, a message box can pop up and say Hello World.

It sounds stupid because you're like yeah, there's like five lines of code for somebody that was like I don't know, like said like seven or eight, that was massive. That was like wow, like this is just the pinle of computing. And so since then I kind of stuck with it and you know, through High School, through college, and not only did I pick up that, but I also got into engineering. Like to me, my kind of the innate curiosity of just like, well, how the heck does it actually work? Is what kind of BU?

Built on my experience with computers and I was like, okay, well, how do I take it apart? And the story that I tell people is actually that's how I got into Microsoft. That's how I got noticed by Microsoft is that at some point in the past I revers engineered the API for the Zune. For people that are younger they might not know what a Zune was, but back in the day that was a cool thing from Microsoft. That was totally cooler than the iPod, I promise you.

And they had this desktop client, this app that ran on Windows that would pull your like stats around, you know like which artist you're listening to, like we're going to get into the whole stats thing, but like all these kind of metrics that you could pull and like that's kind of cool, right, like. But how do I do these? So I learned how to use like Wireshark- and I think at the time Fiddler was a thing by now- and I put together those blog posts of like here's how to do this.

And also, I think I stumbled across something that was like would allow me to download like the movies, like the Blu-ray quality movies, through Zune, and I blogged about it as well. And then somebody from Mar, I was like let's, let's chat about that. And I don't think the blog post is live anymore, but that open doors for me. So I met the amazing folks that ran at the time, coding for fun. So Clint Rutkas, Dan Fernandez- I'm sure you're probably familiar with them- oh, yeah, very much so like great friends, yeah.

So, they kind of opened those initial doors and, like Brian Peek and all of them, and I kind of got to know the work that they're doing and they involved me in some of the conversations and the project that they were building and that's what kind of started my official, like quote unquote- career, if you will. So I started as an engineer and then down the line, I realized that you know what? But like, look, I like talking to people, just like you. I have a podcast and I genuinely enjoy it, and I was like man even back then.

This was, like I want to say like close to 10 years ago, more than that- and I was things like okay, well, like what is that job where I can combine talking to people and code? And apparently there was a thing called product management that I Microsoft called it program management at the time, but regardless. And so I went down that path. I interned as a PM and realized, like yep, that's what I want to do. And here I am. You know, 2024 it's GNA, going on a decade, I think more than a decade, of basically being in the field. That is, you know, really cool.

This was close to 10 years ago, more than that, and I was thinking: what is the job where I can combine talking to people and code? Apparently there was a thing called product management that Microsoft called program management at the time, but regardless, I went down that path. I interned as a PM and realized, yep, that's what I want to do. Here I am in 2024, going on a decade, I think more than a decade, of basically being in the field.

You know, let's go back a little bit. Visual Basic, right? You say only five lines of code, but the reality is that in a world before Visual Basic existed, drawing the window, drawing the button, getting the event handling, all that stuff working, that was easily hundreds of lines of code.

And the funny thing is that I think a lot of people today just don't understand how amazing it was to have something where you can go from, like I launched a Dev tool, I did something very quickly and got hello world up that it's actually not just like a console message or, like you know, just like simple text on a page, but actually was like part of a, you know, a full windowing system.

Like I think that's just one of those things where you know you've been in the developer space for a long time, so you might relate- is that I feel like as an industry, we' just gone backwards in so many areas when it comes to, like, how easy it is to build web. You know content. Like you know, I was in the whole Windows development space. Like you know, windows- and WPF of course- was huge when I was at Microsoft for a long time and so I was there.

But then I went to the web world and I'm like, wow, the website is, so, you know, outdated compared to how easy we had it on the desktop side and of course, you know, the flash world was very, you know, unique in that sense was like it was the web world, but it gave like that flexib ility of like a full desktop compositor and all the things without having to do that work. But that, of course, unceremoniously, like you know, no longer became relevant very quickly. But I think that's one of the most interesting things is like you had to go back in time, right, and I always wonder.

If Visual Basic did not exist and the barrier for building apps or just even getting started was extremely high? Like: imagine a world where you had C or C++. Would you, or would I or others who are currently having a very similar path, have gone into the industry and stay there for as long as we have? Yeah, that's, that's a great question, mainly because I think I'm a firm believer in removing barriers to entry for folks like I, the nothing I hate more than gatekeeping, right like there.

There's a lot of these conversations where folks talk about like well, you're not a real programmer unless you understand these algorithms and can write assembly code. Who cares? Like literally who cares? Right, it's like what? Like we forget that using computers it's a tool, it's a tool for something, it's a tool for entertainment, it's a tool for solving problems.

When I write code, I write code to address a problem and the problem can be, you know, I say problem- and this very broad term of like it could be my curiosity, like I'm curious how this works and I address that problem by writing code, and I don't believe that there is kind of any inherent kind of benefit to saying like: well, you can only be classified as a programmer. If you fit in this like narrow box and to your questions, like I don't think I would be in the field.

Actually, if the barrier to entry was higher or maybe I would have gotten in the field, but much later, primarily because- think about it like I was not a super smart seven or eight-year-old, like I was not one of those like genius kids that is like, yeah, age four, they can speak seven languages and write, like you know, assembly code like I was not that kid. And if to me, if the barrier to entry is like, well, learn this. Like cryptic language that has zero like human humanness to it, I probably wouldn't have stuck with it, right?

And I think it was a massive, massive benefit that computers were accessible, that by then they were well, I don't want to say like super accessible, but they were more accessible than even a decade prior. Languages were abundant. Like we had basic. There was Pascal, which was very easy at the time, like turbo Pascal was a thing, even though it did not have like a gooey component, but it had its gooey version, which I believe was dely so there's all these tools like it. It just so happened to be like the timing was good and then on the web, kind of side of things, you had front page from Microsoft.

That also helped you, kind of like the drag and drop things and I think that definitely accelerated my interest because also that gave you the kind of instant gratification of like oh, I want to build this app for my school that did like quizzes, right, like you click a button and like it tells you pick the right or not or the wrong answer. And imagine writing that in the like assembly or C, like with, like Win 32, like MFC apis, or it's horrible. It is still horrible today, like even for me.

Now, if you tell me, like go write some C++, like Win 32 code, like can, can I do something else? Right, like it's I think it's definitely like that. That Paradigm helped tremendously in me picking up the interest in seeing the words. And then after that, of course, as I built my experience, I started diving deeper into a lot of these topics. Like, well, now, if I want to do, you know, reverse engineering on specific like file formats, I need to learn how C works and how C structs are like laid out in a specific binary file.

But that stemmed from that understanding of like, but I already knew how some of these things work at a high level and now I can do a deep dive, right, like, if you think about the analogy of learning how to swim, if I, you know, take you by helicopter in the middle of the Atlantic Ocean and drop you off and be like, all right, good luck, learn how to swim.

Horrible, like what are the chances you're going to come to shore, versus if you start from a more shallow pool and then you're like, okay, now I kind of get the idea and I can be more comfortable and get it to a deeper and deeper level. I think that analogy still stands. Yeah, that's actually a great way of looking at. It's actually funny because I brought up a swimming analogy- my previous chat with someone else earlier as well, so the different one was still swimming related.

So there must be something in like you know, you're, I think you're, you're Pacific Northwest, right, like oh, yeah, no, yeah, there something in the air here, know, I'm also here. Like there's something in the air here where, like swimming, you know analogies, our bodies of water, that's it.

Exactly, exactly. No, I think it's, you know, an interesting way of looking at it because you know, programming itself is hard. But if you take many steps back, is that you know, yes, we write code, but the people who end up benefiting from that don't really care. They have a problem, they're trying to get solved and how it gets there and how it works out less interesting for them. You know, and this is a classic Model of like. You know, we all drive vehicles.

We don't know the internals of like you know- at least I don't on like how every decision was made and why the car was made the way it was and what works there. But there are people out there who do care about it. I'm glad they do care about it and they very passionate about that, just like, you know, developers are in this case. But if you take many, many steps back- and this is probably the product manager in both of us speaking- it's like if you take many, many steps back, you know where's the real value ad in this?

Is a real value ad in knowing how to write assembly codee or is a real value ad in being able to have something in Market quickly that solves the problem very well. Yes, one could make the case that the performance could be, you know, a little bit better if you wrote, you know assembly, if you were in an unmanaged code stack and things like that. But then it's like, I don't know about that. And what about crossplatform? What about all these other things you kind of get, you know, in many ways, I would say, for free. It's always a cost, but the developer cost might have been a little less.

And those are all the attentions that you know I definitely saw growing up, you know, when working with developers and, of course, at Microsoft, I saw that all the time when we make that shift from like unmanaged to manag, and you had net and you had long horn, you had you know all those various things where, like, will managed code be in Windows itself? Will it not be in all these things? So you know, we were like right in the middle of all these conversations and- and today it's kind of like the gatekeeping in some ways- does you focus on web development?

For example, is someone who uses Framer or Wix or Squarespace oress to get content out there? Would they be considered a developer or would did not be considered a developer because they didn't actually go and like run some npm, you know command to create the entire scaffolding for an entire app and do everything from, like you know, markdown scripts and so on. It's a hard question, and but I agree with you though, like in a grand scheme of things, does it really?

I'll tell you this: I have a friend who's an entrepreneur, and he is non-technical. We're talking, he doesn't write JavaScript or HTML, but he's great at executing on the business side. He can figure out the end-to-end story of a business very quickly, and when I talked to him recently, the same topic came up. Right, it's like you're, you're not technical, he's like: well, you know what? Like it's true, but also there's a lot of tools that are available today that can kind of piece this thing together for you.

Like you mentioned Wix, there are Squarespace and then Shopify has their own like store and you can customize it and you know what? He's still successful. It still brings like five figures every month. It's ridiculous. And we're, we're like right, like he solves a problem. He found a problem and he's addressing it through some SAS business and he did not really build the kind of the core kind of components to it and there's going to be some work that he needs to do to make sure that you know, oh, I need this like custom flow, to get like track, like customer orders or something.

But there's a lot of stuff that you can basically use like Lego bricks, where you can just like put it together and it kind of gets you like 90% of the way we need to get. And so in this example he's solving a problem. He's doing the thing he's actually having running a business is bringing the money. Does he care that behind the scenes, the users view or react or like I don't know whatever other framework is famous in this week? I don't know. He doesn't care, doesn't matter.

Yeah, exactly right. And there's this moment, you know, or Le movement, like you know, like five, six years ago, it's like you, your performance of your content needs to be really, really high, because if it's not, it's going to be, you know, not great Fore from an SEO point of view and things like that. As it turns out, that's actually not very true. You know, I don't think, know SCH really, at least frombody think publicly doesn't really care about those kind of things.

It also it's like we're talking about performance and it's funny because sometimes people conflate this, especially in a technology space, as to where performance matters and where it doesn't. And I'm not saying that this is like an incentive for you to go and build extremely slow websites, because those are like super frustrating, like I, Reddit, I'm looking at you. Your mobile app is freaking horrible. I'm never using it, I'm not like. And their mobile site is even worse because it starts all these like it loads and it starts spinning.

It's like: whatever framework they use, can you please not? But it like the? The? The focus on performance perance often times takes the developer Centric view instead of the customer Centric view. Oh, I'm a developer, I want to increase performance. Okay, like you're going to squeeze like 7 Seconds out of some request somewhere, doesn't matter for the customers of your marketing site? I don't know, but most likely not. Like I don't know. Never in my life have I went to a site and like: wow, this loaded like half a second faster than it could have. That's impressive.

Oh, I look, I went to a site to like: place an order or watch a video or whatever, it doesn't matter. A lot of times the customer doesn't care. It's a lot of this developer driven. Oh, I need to squeeze every, every like millisecond out of it. And it depends on the context, right, like if you're working on something that is a backend service, that is a distributed system, yes, every millisecond counts.

You want to squeeze as much performance as possible, but for a lot of things like, oh, I'm building a website for my customers to read a blog, or something like, oh, one framework gives you like 3% faster load times. Like, does it really?

Matter? I don't think so. Yeah, and especially true if what you're building is unique, where there's no competition for it. You know, like for R, Reddit can be 10 times slower, but because the things you want to read are on Reddit and nowhere else, we're going to be like, yep, we're going to take a little longer. You know, same with Amazon, same with some of these other various things.

You know, the there are cases where, if what you're building, of course it's a commodity- you know, I look at new many ways as an example- where a lot of this republish, you know, you know the Associated Press or reuter and things like that. Yeah, I'm going to go to these sites that have fewer ads and fewer like. You know, things like pop up saying, like you know, subscribe or do something like that. I'm like, you know, I have my Buy store, like, okay, I'm gonna avoid those kind of sites, but those aren't by you know, and large like the most common things that people spend.

Exactly like, my bank website is slow. Am I going to stop banking now? No, I'm going to still figure out. Okay, let me use a different browser because it's not working in this browser, like something you I'm going to jump through hoops because there's no alternative. And I think that often gets missed as well because, as a technologist, you're like: I'm going to spend an entire Milestone doing. You know these kind of things.

When the reality is like, you know, if you reduce friction as part of your checkout flow, you know, if you reduce few of these interstitials, if you autofill things in a more Smart Way, those are probably going to be much more meaningful than improving the performance by a certain point. No, agree, It's Tricky. Yeah, I agree. And especially, you know, even kind of building on what you just said of like websites, that you don't have a choice. Like, oh, you can find a product, but it's only on Amazon. Are you really going to stop using Amazon to order it? Probably not, that's not necessarily.

You know a forcing function for Amazon to say like, oh, we don't care about the performance. Then, like, your checkout process can take seven minutes and who cares? Like, you still want to make sure that it's good, it's a good us exp to me, like, as a customer, I enjoy when websites are Snappy, they're fast, they're responsive. Like these are all the things that matter. I want my bank to be responsive when I initi, like an external transfer or something for that to be responsive and I don't need to click twice on a button because I didn't realize that it's actually loading already.

And then, yeah, we like executed transaction twice. I don't want that right, but there's a marginal benefit to it, like, oh, but if the statement loads, you know, on some marginal Improvement- faster, do I as a customer care, probably not, like there's bigger fish to fry. And to me again, this is- I've seen this play out multiple times- where a lot of times there's kind of this enthusiasm that's very kind of engineering driven. I was like: wouldn't it be cool if it made this more performant? Totally it would be.

But if you have like a list of like 10 other things you can actually improve that your customers would meaningfully benefit from, I'd rather do that. Yep, and I think this you know, I think you touched upon it indirectly right now- I know I worked at- you know- different companies and I worked at different teams that Microsoft all had a very different culture in many ways.

I do think that in sit situations where engineering drives, like you know, the large part of the influence over what the product ultimately does, there's a slightly greater emphasis on things like performance and these other metrics, whereas I've seen, like, when you know, either product or design happens to be, like you know, more influential in these areas, where this sometimes I take a- you know, like a different, you know different prioritization where, like you know, does this make the user feel more emotionally attached to your product? You know it's.

So maybe this little animation I might add, like you know, maybe 0.1 second of extra, like you know, file size and time, it's actually worth it because you know it's going be memorable, people going to like the brand of it and things like that more. Whereas if you look at it purely from a rational, you know, metrics driven only point of view, you might be in a situation where, like, yeah, we're going to. You know there might be something huge that is actually a real problem behind why this app is really slow.

But I'm going to block this net new thing you're doing because that's what at least not going to add to the problem more, and so it's easier to say no to something than it is to like actually go and like refactor something that's actually like, probably the real course Source, yeah, of like the performance problems, and It's Tricky, you know, and I think you and I probably you- you say work at startups and large companies. I.

I love working at large companies. I love the drama, I love the chaos. When you survive at a large organization, you realize those skills are very valuable there, even if they don't translate to other areas quite as effectively. Yeah, go, go, shave some 10 kilobytes off of this, no one's going to care. But if it keeps you happy- and you know I have the freedom to continue executing my road map, go for it. I like.

That framing, mainly because I also think that often times we sweat like the small details and we think it's so important and I like the frame of like that's not just the hill I want to die on, like does it matter? Like in a year, who's going to remember that we shaved off like 10 kiloby or something like? Yeah, see, I don't know, not that many people. Who's going to care about any decisions that we make in like one year, five years?

Unless you're working on something like medical equipment where it's like literally life saving, like there is huge, you know, there's a huge liability on you to do the right thing as good as possible. Most of us don't do that. Most of us build like CR apps and like sdks and applications and it's like, yeah, there's some things that are critically important and that's why I.

I said context matters. I work in security, and for us performance matters. When you deploy some kind of container that does authorization or authentication logic, every shaved-off amount of time is important. If I were building an SDK for talking to my router here on my desk, I don't care. It doesn't matter.

There always an interesting thing about you know, especially with PMS who are working on developer facing products, is a very different world than a consumer product where, like consumer product, you know you want to minimize friction, you want to make it very easy for people of all experience levels and abilities to be able to use your product very well, whereas with developer facing product it's like, well, you know, there's a certain level of technical depth you probably need to have, you know, to be able to be successful in this area anyway.

So if there's a little bit of friction there, a little bit of extra work you need to do to be unlock, it's okay.

You know we're willing to sacrifice some of that because you know fit and finish and polish may not always be needed and that's always ATT tension though, like you know we, you know at Microsoft, you know, like different teams, you know, we know we want to speak, say them out loud, but we know some teams really care a lot about developer experience and do a really good job, like making really polished apis and, like you know, experiences on the console, on the web and the CLI and all these things. Other teams really, really don't. But at the end of the day, though, does it really matter?

Because you know if you need to do something- Mission critical and there is no alternative, and you already bought in on this like overall stack, you're going to do whatever it takes to get done because, again, as a developer, you're flexible. You've seen worse things in the past. You probably, you probably- wrote assembly, you know, back in the day. So for you, like you just have like a mouse and a keyboard, can visually do something, even if it's, like you know, writing in a terminal.

That is huge, and I feel like the luxury that all of us who are product managers in a developer-facing space operate in is both a curse and a blessing. 100%. All I can say is I agree.

So, getting back to the Zune, I loved the Zune. I had so many of them, at least five, every generation of it. Probably the best hardware I've seen, and the best screen at the time for being able to navigate. No one else ever did that really well, even when the Xbox replaced it. You know, for a brief moment, can play like music on the Xbox and you can have it be streamed. It was never the same Fidelity of the visuals. It was like more like this. It's more like what Spotify is today.

You know almost, like you know 15 years later, where it's like, yeah, you see the album art, you might see some colors or something about the artist going on behind the scenes, but it doesn't look as Tastefully or as designer friendly as it was. And also, the Zune was one of the few devices that didn't have a converter from analog to digital when you were actually projecting. It was an HDMI connection, fully digital.

So if you cared about audio quality, which I'm not sure my ears could ever detect, psychologically I was like, wow, I'm getting the best quality audio that I can because there is no translation going on between analog and digital.

You know, for all the crap that products like Windows Phone sometimes get, and some of that is justified, Zune was one of the best gadgets I've ever owned. I'll echo your sentiment. It was such a polished experience. That was not just perfectly round, but it was this kind of rounded rectangle shape and yeah, and it was just it was so good. And then you plugged in your computer and then the Zune client would fire up and like the like I said, like the visuals of, like artists and syncing, and it was the first client that actually, like it, bootstrapped the whole concept of Metro design.

I- I don't think they call it Metra anymore. I think they at some point I got replace with something else, but it doesn't matter. So that design language is what that was kind of those initial steps and it was so good and when they discontinued it I was like man, that's extremely disappointing because I love my Zune it. It was one of the gadgets that I think I will say the unpopular thing. I liked it more than the iPod. I think the iPod was the first, but the Zune was better and you know. But I don't. I don't want to get on a flame war on.

This. I mean I think at this point, like people have no idea what an iPod even is either. So I think you know we're in very territory. That's true, because when I was an intern at Microsoft- it's probably like 2007, 2006- the intern gift was, I think it was a Toshiba gigabit. You know, I was running the portable version of Windows Media Center UI almost in many ways and that was also absolutely beautiful. Like I think Windows Media Center also didn't get enough credit for like how well of a UI it had for, like the 24 or 12 foot experience and that in a portable screen was fantastic.

Like I love being a kind of like the rectangular with the glossy in the shadows. I think you know I was actually watching a video of it just recently because I always like, just like to go back and be like man. We had it so good with some really good UI back then. Right.

Yeah, even now it holds up extremely well. Of course, the Zune holds up very well even now because that tastes fulness of like a minimalistic design that has, like you know, B colors and edges. It's Timeless in so many ways and absolutely- and I think this goes back to like what you just talked about right now with developer tools and so on- is, like, you know, does it really matter? Did it really matter that Zune had much better UI, much better packaging at the time, much better? You know all these things. I think Zune was also the first one to have like a monthly past right.

Like you have unlimited songs for a monthly fee, 10 songs that you can download for free every month. You can keep them exactly, exactly. The Zune pass had all these things going for it, right, but the end of the day, it didn't matter and it always.

I always remember that part because I was like so in the middle of a lot of these things with the Zune team on like how it works, on the runtime capabilities and so on, and working developer division at the time, and it always go back to like you know, it doesn't matter if you build a better product, it doesn't matter if you do all these things. There are more fundamental forces at play here and sometimes distribution is critical.

Sometimes having the- you know the partnership with the big lab so that you get some songs on day one- far more important than being able to have like other things, and at that time Z had really good marketing as well. So you can't even say, like you know, micros wasn't investing enough into it, and so on. It's like they did all the right things. It's just that, like you mentioned, it was not the first MP3 player by any means. I mean, NE was the iPod.

There were many MP3 players that were around at the time like, but it was definitely the one where it wasn't, was not different enough in the areas that mattered, where it C people to be like. I'm going to switch away from what I'm going to do. I'm going to switch away from the trend of people buying iPods to try this thing out.

Yeah, I think that there's fundamentally a shared understanding across good product managers. Is that, for example, being the first is not the most important thing, right? It's like it's sure you can be the first in certain things, but often times the second product can win at the same time- and this holds true as well- is often times because you gave up that first place and then you're second.

Like you said, there is more forces in play now that you need to overcome, which is, if I'm a user and I need to switch my let's say, the Zune came how many years after the iPod, like I can look it up right now, I can Google it, but let's say like two years, hypothetically. If it's two years off of the iPod, or three years, that means that those three years the customers have already kind of bought into the competitor ecosystem.

Right, they use iTunes, they bought a bunch of music and at the time, don't forget, iTunes was DRM, so the music was not easily transferable, so I couldn't just plug in another MP3 player and just copy my iTunes music on it, like it was like: oh no, this music plays well on your iPod, but good luck if you want to take it somewhere else. Or I bought movies on iTunes that are also DRM, that I cannot take anywhere. So those three years establish that kind of foothold of like all these customers now have this kind of in. They've invested into this platform to some degree.

So, you coming in with something else, it has to be massively better for them to abandon all of that. If it's just another one like oh, but we also do music, it's like well, yeah, all right, and it's a totally fair thing, right, it's like there needs to be some kind of benefit of saying like, why would I switch? And yeah, we can argue about the fact that there is kind of new customers and there's existing customers and maybe they should have pursued a different market.

And, like I have not worked with the team, I don't know what their plans were, I don't know what the data they had at the time, but ultimately, what matters is, like you said, like the competition kind of showed that the iPod won, and then, you know, there was the iPod touch and then after that they just wrapped it all up like nope, it's just the iPhone now. But yeah, you know, I always think about, like you know, because we both work on products and you know, even we don't work exact on MP3 players. The similar forces exist, you know, that influence exactly what happens here.

And I always have this model where I think of, like you know these, I think of like multiple sine waves, you know, kind of going parallel. I look at three of them at least. One is technology itself. You know technology is evolving and so what you're doing today, you know it's going to be really cool for a couple of bit and it's going to become boring. It's going to be that's like the, that's like the Valley of the sign. The PE is like something really cool is happening. Then there's the whole user preference. User Ben, you know what users really care about as well.

Like you know, for the most part, you know there might be a certain need that comes out where us like, oh, this is exactly what I need. Then they're going be like: okay, I'm bored, I don't need it anymore, so I'm not going to use it anymore, so that there's a little peek and Valley of that. That goes on as well. Then there's the actual team who's building it themselves.

Oftentimes, like you know, when you look at PMS, you have the founder type of PMs and you have the operator type of PMS as well, and so often times when you're doing something brand new and something really cool, you know you often have the founder type of PMS who are, like, willing to be dealing with ambiguity and working on some of these things, and then they eventually move to do something else and you're left with a different kind of- also equally important, on how do you now take this product and make it sustainable and make it go, you know, in the long way?

And so what I always f with the iPod and Kos them in some ways, is that they had a technology Trend right, and so as the screens became bigger, as the form factors were able to be smaller, as you can do more things with touch, you don't need to like have, like you know, physical buttons and so on, they kept up with the trend. So they never let the hardware itself language and it's of software as well. You know, like all the stuff that kind of played in the color screens came in. It was really cool. They had the like, the really tiny form factor.

They the smaller form factor, like the, of course, the larger size ones, they're almost like iPhone size.

They had all that going for them and you know they also read the trends effectively, where not only they first in reading that, you know people want music, you know everywhere they go- maybe audio books and maybe videos as well- and as they got to the point where, like you know what, maybe privacy and not privacy, but the being able to carry your music on any device, listen to any machine without having it be DRM and so on- not a bad idea also, and we can actually do some of that- they stayed up to trade on all these kind of Trends.

So it's a case where, like the opportunities, most products, you know, most successful products, end up going to this period where they're like they just they struggle, they become, they go to dark days and then they eventually emerge at some point. They're lucky. But you know with, I think in the case of the iPod, they were firing on all cylinders, consistently really well. The opportunity never came to point where, like you know, that product was at a Valley and the Zune came in at a peak, where they the differences between what made the Zune truly valuable, what made the iPod truly valuable, just didn't quite exist.

And I look at that in terms of many apps that I use on a regular basis as well, because my favorite example always is like not taking apps right. Like you know, the not taking apps I use have evolved, you know, over the past like 15, 16 years. You know it used to be notepad on my Windows machine, like I use a notepad file and like many notepad files of various things I do, and then it went to Evernote for a brief while. Then it went to, like you know, one of my friends built a not taking app. I think I forgot what it's called.

This point, wow, I forgot was called completely. But who's? Let me ask who's? Your friend is Pascal D Silva. I think I know the what you're talking about, but yeah, he created a company called thinko t I n KO. It was probably the most colorful, most visually stunning note app- again, very simply, to take note apps in. Hang on, let me let me now I to Google this- find out right now: thinko note taking app. I'm just really, really curious now because I've never heard of this.

Actually, I think I've heard because the name Rings a yes, and pasc has been a regular on my podcast as well and he's like you know, he and I work close together on like various design things as well. So, okay, you know, I mean this might one to we edit out in the final recording, because we're both Googling this. But hang on, thinko, no, taking it was actually. It was also on the Windows phone. It was a Windows Phone app as well, and so that's why I remember, like you know, using it quite a bit. Thinko, Pascal note. Okay, I'm seeing. Okay, I think I'm on the right page.

Now let me go and see what's the first result. Okay, I think I go to archiveorg at this point. Wow, this is what happens when you know you've been doing things for like so long that you it's kind of like living long enough where the stadium gets built and torn down and rebuilt again. I think I've been in Seattle now long enough where that might be happening again. You know, with, like I think, the Sounders and things like that. Okay, I'm at 2017. Let me see a snapshot of what's going on here: redirecting, go for it. Let's see. Okay, 2012 looks about right in some ways.

Okay, I'm on the website right now, so I'm on the right page. Light box. Okay, Dracula, this is before, then. I mean, you can always find it later. It's no big deal, that's true. That's true, you know, I do one more click. Okay, I'll find it later we'll talk about be edited out as well. We'll include it in the show notes. It's fine, it's post edited. That's it's great. Yeah, so for whoever's like watching after at this moment, yeah, den and Ice probably spent like maybe you know three minutes going like archiveorg and all these things to find it out.

But, yes, you know, getting back to like what I was saying about no taking apps: always a great example. Like you know, what made me choose it back then? What made these products really cool? What made them no longer cool? Like, did they just keep adding more and more? Because you know, my goal for no is like, simple, easy to use. I can access it from various devices that I'm on very quickly, what seem very fundamental, basic kind of a point. But you know, over the time, all these products, they had something there. They somehow ruined it, but some other reason.

And then something else came in which, basically, you know, five years later, was basically V, one of the product I'm replacing from like five years ago. Like you know, look at notion. I'm like, yeah, notion, you know, four years ago was exactly what Evernote was, like you know, 10 years ago, and now I'm- I just use Apple notes right now and I use quip every now and then- most at sales force- and quip was really popular and quip still maintain that very simple kind of a model like I can write something I can share with someone very quickly, no complicated UI, just primarily focusing on text.

I'm like this is actually pretty cool, has commenting capabilities as well, and so that's why I still use even now. But I know at some point it's going to be like, okay, they're going to add more features, because that's what you know, that's what do they add more features to things? And then it gets to the point where, like, I can't use it anymore, so I'm going to wait for some other company to basically copy what was done by quip. You know, seven years ago or six years ago, yeah.

Well, and that there's a misconception that every Market is a winner- take all market, and that's not true. Now let's be clear: there are winner- take all markets. For example, we talked about Windows Phone early on, right, Windows phone came on the heels of iPhone and Android already being a thing, right, and both iPhone and Android had a bit of a head start in terms of building their app ecosystem, like yeah, we all know that like, iPhone launch without an app store and then it came eventually and it did not have copy paste, which came eventually.

But when Windows phone came on the market, that ecosystem already kind of almost like cemented itself around two key players and as it did that, a lot of people realize like well, hold on, my Windows phone doesn't have a copy paste, right, they're like, oh, but that's okay. The iPhone didn't launch with it either. Yeah, but you're competing Now with an iPhone that has all those things. Right, you're you. You have an inferior product that you're competing with something that is much better. They failed to pick up traction on the kind of the app ecosystem, right, like the.

I remember, look, I was a Windows one MVP like I was pretty deep into the ecosystem and it sucked that my friends with iPhones be like, hey, have you seen this? Like cool thing, that was like Doodle Jump or some like one of those like Flappy Bird and whatever. And I was like, nope, not on the Windows phone. All right, man, oh, Snapchat is on the iPhone. Have do you want to? Do you want to like? Send a? Receive Snapchat? You know, like images? And I was like I don't have Snapchat on Windows phone, right, like that thing, it killed it.

I mean, when you don't, because there is a win or take all Market there, it's like whoever was the first? And then you invest in the ecosystem and you your ecosystem involved, and then another product comes in that doesn't quite match up to that ecosystem. Those apps are not there, those capabilities were not there, no matter how good your camera is or like how fancy your messaging interface, like it doesn't matter. But also there's markets that are not win or take all, like we're thinking about, like SAS businesses, right, like a lot of SAS businesses. There is opportunity for everyone.

Like you said, note taking- like how many note taking apps are there? There is one note, there is Loop, there is note Droid, there is bear for iOS and Mac, there is, like Evernote. I don't know if they still exist or not. I think, like didn't they sell out or something, but that there's plenty of them and there is a market for all of them, because they all solv their kind of oh, there, there's notion, of course, and they all solve their individual kind of Market needs.

Like I don't want notion, I want something simple, so I'll just go and use notejoy I, you know, or Apple notes or whatever, like something simple doesn't mean that there all needs to be Consolidated across one no taking app. A lot of SAS business are the same and they're not win or take all markets and that's kind of the misconception a lot of people like we have to be the only one in the market, like or not. If you have like a thousand competitors, that's probably a problem. If you have five competitors, I can totally see another business living there. I.

I think the bigger risk- you know in many ways where this often comes up- is if your success is dependent on the attention of some very small skilled number of individuals. In the case of phone is developers, you know, are developers skilled enough to basically build for, you know, your platform and the other platform and the other platform, in which case, in many ways, they're not. They don't have time.

You know, I mean zamaron, there was Cordova, there is react native, there's flut, all these tools that are existing today, but you know, they all have their small quirks and TR off where, like, yeah, you know, I'm going to focus all my attention on. You know either, like you know, iOS or Android. So Windows phone was always in this weird spot and, of course, they had a very different programming model from everything else as well, and it got to kept changing those which.

Changed halfway. I was just going to say.

Like that. That was another thing that a developer said, like what? Like you want me to relearn the thing that I invested just the past three years in like that was that. That was it like. When that happened, I was like I'm out. Yeah, it was really tough. And then, you know, the web View apps came in, but, you know, web View apps were never quite as good or forant or as nice as the native app. So you were like, okay, you know, this is just not a not a good case, but about noting apps in particular, you're right.

You know when you, when you're, you know when having many, many products doesn't cause any like I guess I'm going to call it like you know, Supply constraints. You know there's no short of developers and that you don't have to worry about that. You no taking apps unless you're building a platform, which notion does have a platform, but if no one built on noi's platform, the core product as a note taking app, though, is absolutely fantastic, and no one really has ever come to me like, hey, can you not taking app to a, b and c?

Mine can, and I'm never like, oh man, I need to go switch that other exactly never happened, right, because that that this doesn't exist, at least in that world. Maybe it might the future, who knows? But it definitely hasn't happened before. So in those cases, even if you're a successful product or company, have like one% or 2%, 5% of the market, that's absolutely fine. And of course, like you mentioned, like in the SAS Market, having like 5% of you know, instead of paying customers to use your product and you have 5% of any like large Market, that is huge.

You don't have to have 10%, even like a 90%, it doesn't matter. Like Salesforce has so many competitors, yet they're still very successful. All their competitors are very successful. Like there's never been a case where, like we need to basically have 100% of thisat. It's just never going to happen and that is completely okay because you know you're not constrained by anything. And I say it's also the scale is different depending on who you ask and who you talk to.

That is, if you talk to somebody that's like you myself, that works at a big company, like there's all these conversations about like okrs and kpis and like we want to drive this up and kind of 5% of the market might not be enough right to sustain a product. But think of like I'm I've been lately very into kind of the SAS business kind of angle of things, like the Indie founder, Indie startup stuff. I'm kind of like exploring, like I was like I wonder how that works.

Like I've never been an indie founder- not that I want to quit my job and do an indie founder thing- but like it's an interesting domain that I'm just kind of looking into and people misunder, understand, like look, if you have a th000 customers that pay you $10 a month, that's 10 grand right there a month. That's nothing to sneeze at as an individual, right? Like for a business that like oh, I charge $10 for somebody to pay me for this, like not taking app that is very specialized to some Niche, you only need a th000 people. That there you go.

Like you're not cornering any Market per se, but you're addressing a niche need and that's kind of cool. Right, like the scale of like bringing in $10000, some like a lightweight business, that's great. Like it's not always about the millions of dollars and I think at larger companies with larger products. Of course, when you talk about the cap, haacks, and opcs and all these kind of breakdowns like, you end up with like, okay, well, if we invest so much in R&D and we then do all the distribution and all these things.

That compounds to very, very, very, very large amounts and so like at a big company or more con in terms of like this needs to be actually, you know, like growing in the Market at a certain rate, when you're building something small for yourself, like a lot of like no taking apps, you're not constrained by the same forces or you don't have the same pull, and then you can be okay with something much smaller. That still is kind of smaller in the grand scheme of things, but for an individual.

It's freaking huge. Yeah, I think the indie hacker space is a really fun one. So much of my Twitter feed is filled with indie hackers doing really cool things. What always makes it exciting, and what's often missing in large companies, is that almost every indie hacker built something because they're solving a problem for themselves. And I think it's Levelsio, right? I don't know if it's him or someone else, but I think his entire operation is a single PHP file for the back end.

Back end. You know, yeah, I think, going back to the earlier point, it's like, yeah, it doesn't matter how you build it, as long as the end result is like: I mean, I'm not going to be like man, I wish this was like you know, this complicated, you know, serverless solution. Nope, it works and makes them very happy and, you know, very successful in that fun I listen to a recent podcast where, they were interviewing Peter and, by the way, Peter like does a lot of like great stuff. Like I don't necessarily agree with, like everything that he says, but he builds and he's actually like a doer.

There's a lot of people that you listen to. They're like quasi entrepreneurs and they all they do is just talk. Peter builds, he actually does the thing and it is kind of cool that, like you said, like he is very much like: look, I have a PHP file, I rent a VPS, I throw my PHP file in there and there's some database and that's it. That's kind of the thing. We tend to over complicate things like, oh, but like, what about this kubernetes cluster and all these like site car things that need to like, what are you building right? Like I years back.

I was doing these like Seinfeld clips and I would just remove the sound and overlay with like Seinfeld and Tech, and one of them was the kubernetes one about like how Kramer wants to do something with kubernetes. And then jer's like, what are you building? And it's like, oh, some like dumb site. And there's just so much of that in real life where you're like, oh, like we need kubernetes and like an AKs cluster and all it's like, but what are you building? Like, oh, a Blog, really like, what scale are you preparing that for? Like, why do you need this or same the people talk about?

You know it's like, oh for to get a personal landing page. Use like react and all these like components and then do like or just open notepad and drop some HTML that does the exact same job with just vanilla JavaScript, right, and I think a lot of the stuff is. We're going to come to the point where that bites us back there, like that overly complicated stuff that's starts breaking unnecessarily. You're like: why am I dealing with this? I need an HTML page. That was actually very frustrating for me recently. I was looking that just bootstrapping a website for one of my projects, that kind of.

You saw that I'm working on, like the thing called open Spartan and that kind of tails on my kind of fandom for Halo. But it basically is some like home brew projects for me to track Halo stats, and I was like, look, I want a website for this, I want a landing page and I want some documentation. That's it, that. That that's all I need. I want plain vanilla markdown that I can convert to docs and I need some plain HTML and I use Hugo as a static side generator.

And I was looking: okay, surely this is like invented, like there's templates that do this and literally every template that I would look at, like we use like react, and then you have to install a bunch of npm packages and I'm just like WTF, man, like I'm literally looking at the simp, like I want to slap an image in the middle, some text, some links and then a download button, and then I go to another button and it takes me to a documentation site that's generated from markdown. It was insanely hard to find something that is simple.

I found I did land on then like a theme, because like, look, I don't want to rewrite a theme from scratch, like I have better things to do, but like all of it was so overly complicated, like all of it was just like: oh, download these mpm packages and then go and configure this and that. And it's like: why, why? Why is this so complicated? For?

Something so simple? Yeah, because I think the number one thing right is always like: well, people like what I'm creating, you know, is it like even worth it? Like what am I doing here? And the quicker you can go from like I have an idea to I'm going to Val and see if it works. That's your number one problem, not what your tech stack going be. Exact single PHP file.

And things like that. The thing is in very small teams, or if you're the founder, or if you're an indie hacker. Basically you can try to keep that. You know Focus, you know always there. You know you and I work at very large companies and we know that it doesn't always scale that way when you go to a large organization where you have people whose full-time, dedicated jobs, as it is to like: Oh, I'm a database expert, I got hired as a database expert.

Therefore, everything I'm going to do is like make sure we have database solution, yes, and I always sit back and go like: you know, I love working on like zero to one products. That's what I spent most of my career working on, and I'm always like very keenly- maybe like almost like paranoid- about making sure that every person we bring on to the team has a mindset where it's like: okay, the biggest problem we have right now is what we're building, worth it, will people like it and things like that it's less about. You know how do we scale for a billion users?

And if you can't get one user, if you can't get 10 users, can't get 100 users. I don't care about the billions solution, as long as we have a way where I can go from a solution has like 10000 people using it, a thousand people using it, 100 people using it, can also scale to sing 1 billion eventually, without like causing the entire service to be, you know, interrupted and having a recovery rewrite. I'm generally okay with like that level of flexibility and it comes from having, you know, both. That's why that's we talked about earlier is like why so the side projects?

And the side is that I never lose that you know, that muscle, because it's very easy to be in a large organization and just get comfortable with the idea of like I'm going to move the needle from one part of the table, another part of the table and that to be success, whereas the real metric is, like you know, can we reinvent a category, can we do something completely new? And that requires having this constant questioning of am I making sure the team is working on making that happen, or are they now optimizing for things that are not necessarily optimized for right now?

Exactly, yeah, I mean we talk about Peter and this is kind of one of those things where he does it really well is just focusing like I solve a problem and we'll cross the bridge when we get to it of like billion of users. But like, why Design This? When he was writing his book- I think it was called make he literally was showing that he was writing inside a vs code and he's: I'm just going to write in vs code or like a Google doc or something for like a draft and get feedback and then I'm just going to convert to a PDF there.

There you go, there's the book. Right? How many people do you know that will try to write a book? It's like: let me find the perfect software for this and how do I lay out the pages? And let me pick the font for it. And like: how do I like align this?

And we're spending so much time like bike shedding instead of actually focusing on what's important is like I want to ship a book, I'm going to write the book and I'm going to deliver it and I'm going to on it and over time, if it becomes more popular, like I don't want to speak for Peter, of course, like he has his own mind on that, but like in my mind, if I'm writing something simple and then I evolve it and I iterate based on feedback, like, oh, now everybody's downloading it, I better go and figure out how to do XY and Z.

Instead of me spending like six months trying to be like I'm gonna make it perfect and then I launch it and nobody's using it.

Yeah, I mean, what he described, and what Peter does as well, seems like common sense. Yet I always feel like whenever you're in a large venue or a large group, you explain this and people are like, wait, what are you talking about? I'm out the door with it, whereas, like, you'd still be like you know, writing a PRD and like getting approvals from all these kind of things and exactly, and that's the part that is always like worrying.

Some times we look at software development and just a complexity of things and, not to mention with AI, with some of the you know the tools that are available now, what used to be needed to be able to build an app that does all these things. Yeah, the barriers is being lower and lower, and I think in many other Industries and many non-tech areas, you know if, if you were to ask me like, okay, you need to go replace, like the tire in your car. I would be like: great, I'm going to go to a shop.

I don't care if it's a best shop, it's going to be in town, they have an availability. They're going to pick a tire that you know. I'm going go to Quick reviews. It's GNA, be done, done, that's it. I'm not going to like, oh, what kind of tool should I get to like, replace it. You know what do I do myself? Like I'm not going to do any of that stuff, right? So when you apply the same thing to programming, there's going to be a lot of people entering this field who are not going to be in the bike shating mindset. They have no concept.

They don't care about half things as programmers be worry about all. They're going to be like: okay, I need an app that is abnc. I'm gonna tell this thing, an agent or some AI capability, that I want to do abnc. And when that happens, it's going to create this huge influx of a lot of people whose their careers are built on bike shedding, and probably very successful careers based on bike shedding are going to be in for a rude awakening where they're going to realize like: wait, what do you mean ship something? What do you mean actually finish the book?

What do you mean actually, you know, take something you have as an idea and actually get out the door, and so I see that happening sooner rather than later nowadays. Oh yeah, and especially because the tools that we get now like we think.

We see what I call like AI, because it's not truly like intelligent, right, it's, it's autocorrect on steroids, right, like in a way that, how an llm works. But it's an amazing thing, like it's freaking fantastic. My use case for that personally is I use it to write SQL queries. Like I hate dealing with SQL, primarily because there's just so much kind of flexibility in how you compose and do these joins and stuff and then, especially if you need to join between like seven tables, it becomes this overly complicated.

I was like man, I'm going to spend like half a day just writing this query for data that I already have. I go into chat GPT- on paid version, by the way, 3.5- and I say here, here's the database that I have, here's the table, here's the 10, 12 columns that it has. This column has a data structure of this JSON. This column has a data structure of this JSON. Give me a query that- and, by the way, there's more than one table. So I' be like there's like two, three, four, five tables, whatever.

Give me a query that extracts me this metric, that's it, from these tables above and I can give it hints and say like, oh, but like: use the value of metric ID from this column or this met. It computes me the entire, like this, like three-page squl query that does the whole, like JSON parsing, and it extracts the field into its own column and then joins that. And then, and then and I would ask, okay, now this query, can I optimize it? And I literally would just ask it: can I optimize this query?

Be like, oh, yeah, actually, instead of this joint, you could use this join, and I'd be like, okay, but like let me go and actually cross check, because I'm not a SQL expert necessarily, but I'll go and check and I'll go and like, look up on, like stack Overflow or whatever, and like, okay, yeah, this seems like it would optimize the performance, it makes sense. I saved myself like half a day in, at most like 15 minutes of just like, and now I have a working SQL query that extract me the data. The SQL query is not going to go anywhere in production, it's not Mission critical.

I don't really care if it's optimized to the millisecond that it could squeeze out of it. And be like, did it give me the right data? And then I will go and check and I will actually, like you know, validate that it doesn't produce junk, because in the quer is like, oh, it missed a column and now it's Computing the wrong thing. Like I would still look and see like I don't just blindly use it. But it's a freaking amazing tool because it saves me so much time. And there's this kind of anxiety. Our industry right now it's like: well, is it going to replace developers?

Is it probably a certain degree of optimization will happen, like I think if we think about the entrylevel careers, that landscape I think will experience some tectonic shifts because you know the people that just you know toss out like crud apps. They like, oh, it's like talking to this database, all that stuff can be like automated. If you saw, like the developer AI- I think it's called Devon- that they released, it's freaking amazing. Like sure, we just saw the demos, we did not see it in practice, but it is just like the pace at which we're going is not the pace we will see in 5 years.

Like that's my prediction. I don't predict many things, but I think that's my prediction. Pretty safe bet, by the way. Like I'm not putting much on the line here because, given the velocity of everything we're, we're we're seeing, but the these optimizations will land us in a position where, like, a lot of entry-level jobs might disappear. Oh, you need, like, an HTML developer that knows CSS and JavaScript to like spin up your marketing sites entirely automated- gone. Oh, you need, like this entry level like database analyst that's going to run and compose SQL queries- gone.

So now you end up in a position where you're like: okay, but now we need to figure out, like, what is an entrylevel job. Once that actually happens and you know you might need some different level of expertise, you might need to be able to learn more in-- depth topics about programming. And we talked about like the barriers to entry at the very beginning. May, maybe that will get a little higher because, like, you'll actually need to have certain level of expertise in certain domains. That is going to put you above kind of the fold. But at the same time, like the technology is not slowing down, like it's already.

Like again, like I see it in my job right now is like if my job right now would be like just purely writing SQL queries to extract data, like I'd be worried.

Yeah, I think you're more of at this point, more of a conductor. You know you may not know how to play instrument in the orchestra, but you kind of have a good sense of like you're both the conductor and the composer and maybe, in the short term, conductor long, the composer, where you kind of like know that this is what it want it to sound like. You don't exactly know the details of what instrument to play, when and where, so you're going to be experimenting using the AI as like a sounding board.

It's like you know, maybe the first 10 attempts bu, it will be bad, but you know enough about quality and taste to be like: okay, this is a good solution, this is bad, this be tweaked this way and so on. So it goes back to like the various ESS you often see, especially in product management on. You know, having the core skill is important, but you- us like, you know how do you develop good taste, good product sense, how can you spot a good product from a bad, and those are things that often takes like years of experience to you mentioned, though you're short circuiting all that you know.

Basically, there will be no intermediate steps. You're going to start day one being like: okay, let me go right a spec on like changing this icon color from something to another. That's going to be automated away. It's going to be more of like: okay, why is there an icon even there? What should the icon do? We need exactly better way of conveying this information. You're moving up a level and that gets you know.

That is good territories for a lot of us who've been PMS for a long time, but for entry-level PMS, who never saw this before, it's going to be scary and I agree there going to be tectonic shift and I don't know if the world, or even the education system or even this onboarding plans, is preparing people to.

For sure, 100%. And I think the important part here, and part of the reason why I don't buy into the idea that there's going to be this job called a prompt engineer, is that, in my mind, caveat personal opinion, that's a dumb job. I can introduce so many problematic things into the fold, into my product, into whatever I'm building, because, like, I have no idea what I'm doing. You know, I asked them to give me the query I pasted, the query I copy pasted. There you go like no, I still need to validate the data, I still need to.

So that's why I really like the framing and I think not to like necessarily, like, call out, like specific companies, but like the. The framing of this being a co-pilot to you as a developer, as a designer, as somebody, is genius in my mind, because it's like it's somebody that assists you. It doesn't necessarily take over a 100% of what you're doing, but it can help you do what you're already doing. If you are a doctor that goes and says, like I need to analyze these, you know 17 x-rays.

Wouldn't it be awesome for an AI to look at that and be like, hey, like these are the anomalies that I see? And then you, as a doctor, you're not abdicating your responsibility, right? You're not? Like, oh, AI said here, I'm going to go to tell patients: no, you're not, you're, you're absolutely not. You're still going to look, you're going to validate that and say like, hm, okay, this warrants, like, another test, this warrants me to go and reimage. Same thing goes for developers, same thing goes for designers, same thing goes for product managers.

The application responsibility is just not something that I see happening purely because somebody needs to make sure that whatever the output is actually the output. Just because you could type in some text and you generate an image like, hey, look at me, I'm a prompt engineer. Now, look how, how awesome. Like I'm, I designed this thing. Right, I produced this art. Like, no, you didn't. And here's the thing: like, if you have like, like you mentioned like, if you don't have the sense of like, what is good art. How should a page be laid out? What are the proportions? What's the good color scheme?

You have to have that sense right, like you can't just toss things over the wall and be like, well, well, the AI told me that my page should be yellow with these blue buttons, so that's what I'm going to do, like I hear you, Dan, now I know when we started this conversation and one things I reached out to you, and one: the chat. I.

Like, I wanted to hear more about your Halo integrations and things like that. I think we probably covered a lot more interesting topics than we could get to in that time frame. I think we should probably have you on in the future to talk both about this and about that. But before that, I do want to cover the Halo part. It's one of the formative games for me. When I first played Halo on the PC, that was an eye-opening experience. I played Half-Life and all these games, but Halo was the first time I was like, wait a minute, this is absolutely amazing. Those were mind-blowing moments for me.

So what's your favorite Halo game, man?

I'm going to go against the grain here and say that I actually like Halo 4. Halo 4, yes. People bag on me for this all the time because Halo 4 is when 343 took over from Bungie and they totally butchered it. No, they didn't.

I started my halo career, with Halo 3, but when I saw four, I was like this is like levels better than what I played in three and then with like the multiplayer and four was great and just the Dynamics of that game and just the visuals hands down, you know, I still like I'm in the middle right now of replaying the campaign again- an MCC, because I played kind of the original Halo 4, but now I have the. It's not remaster, it's just integrated in the Master Chief collection. But that's that's my current Pastime.

It's just going through the campaign once again after what it's been like 10 years, something like that. Yeah it really.

Has. I remember like buying it on the day of- you know that, Mar, how you get the discount as well at the time. So you know it was like on day one. I was like I've been getting it, going to play it and so on. So what, what is your take on Halo ODST? Or did you ever play Halo ODST? Yes?

Yes. Halo 3: ODST was, I think, an interesting spin, and I actually wish we had more of them. Because you take a different perspective, it'd be cool to see a Halo from the perspective of the Covenant or maybe the Forerunners. So ODST was actually, in my mind, really good because you see somebody that's not necessarily the core protagonist, like the master chief, the Spartans. You see a Spartan, you're just a normal human being. Yes, exactly, you're a normal human, you're a soldier and you go through the motions of what you see happening, right, and I think that was a great experience.

And again, the visual, like the atmosphere, the kind of the meme of like the saxophone starts playing as you start like walking around. Like it was great, I loved it and I- maybe I'm just a very easy tolee fan because, like I played through all, the, all the games and they all sound really cool to me and they all look really cool to me. And you know, like Halo infinite, the story, I think the spoiler alert, the reveal of the Endless at the end, that opens up new doors for, probably, future campaigns. Maybe, like I'm excited about that, that sounds great.

I don't know, man, it's just I feel like there's just so much in the universe to still.

Very, very last question: Halo Wars. What was your take on that?

Haven't played beyond one or two games. Okay. Look, real-time strategy is my thing. I play Age of Empires a lot, and somehow Halo Wars just never really clicked with me. But you know what? I'm going to try it again. I know I played Warcraft 3 and StarCraft, Age of Empires, and all those games, and I loved them. I was like, how can a controller and a console let me do all these things? They had really interesting ways of doing it, and for probably a year or two all the people on the team I worked with at Microsoft would get together in the evenings and play Halo Wars together.

It was actually a lot of fun. So I need to give it another shot. At some point I see the beauty of this podcast is that after this I'm just like, man, now I want to try Halo Wars because Kirupa recommended it, and this is your seal of approval to it.

Oh, hold on, I lost your video for a second. Oh, you're back now. Now you're back. Now you're back. Well, Den, it was fantastic talking with you. I think we covered a lot of really fun topics on product management, which actually touches everything. You don't get to chat with that many people who've been a product manager in a dev technical space for as long as you have, so it was great catching up on all of that. And we talked about Halo at the end as well, so I think that more than made up for my curiosity about Halo in general. Thank you so much for...

Having me here.