Kent C. Dodds (00:00)
Hey everybody, I am Kent C. Dodds and we are talking about product engineering and how we need to transfer the way that we build software into being more product focused. with me is Wayne Allen. Would you want to introduce yourself a little bit, Wayne?

Wayne Allan (00:18)
I'm Wayne. I have been a software engineer and a product manager half and half kind of throughout my career and more recently I'm kind of straddling both roles at the moment. So I'm well informed on the topics of product engineering.

Kent C. Dodds (00:39)
Yeah, that crossover is something that is interesting. In my thesis of the future of the world for software developers, it's that software development will kind of gradually grow closer to product management. What are your thoughts on that?

Wayne Allan (00:57)
Yeah, in fact, I think I love the term product engineering. ⁓ It's I guess it's it's great to see it kind of emerging as a term. But I think it's been around in practice for a while, but just without a proper name. In fact, like I think one of the best teams I've worked on where I was a product manager, I went away on vacation for a week. And ⁓ there was a couple of product decisions that needed to get made. And the team was like, Wayne,

⁓ We made all of these decisions because we thought this is what you would do. ⁓ And I looked at the decisions they made, was like, that's exactly the kind of decision I would have made with all those inputs. And so that was probably one of the most effective teams I've worked on. And it's probably one of the characteristics of some of the best engineers I've ever worked with as well.

Kent C. Dodds (01:51)
Yeah, yeah, let's drill down into that a little bit. what, is it just that your team really knew you very well or did they have certain characteristics that were similar to the things that you value that made them come to the same conclusions?

Wayne Allan (02:10)
Yeah, I think there was a lot of value towards delivering customer value. So I think those were some of the ideas we shared. They weren't there just to kind of tinker with tech, but they wanted to get an outcome. And I think that was a kind of a shared value. So, you know, the kind of way I think about it, I didn't come up with this, you know, there's the...

The product concern is building the right thing and the engineering concern seems to be building the thing right. And I really love that kind of dichotomy, but ⁓ I would argue that building the thing right is downstream of building the right thing. And ⁓ maybe I can share a bit of an anecdote on that. ⁓ This was kind of the catalyst of getting me into product management. So.

Kent C. Dodds (02:46)
Mm.

Wayne Allan (03:07)
I was an engineer working on a ⁓ Jason product for a flagship for a property company in Australia. And we built this system that could handle the entire population of Australia all logging on at the same time, which was completely unnecessary. We launched it and no one used it. And it was devastating. We'd spent a year.

microservices, it was everything, it was everything. ⁓ But I think because the context around the product wasn't set right, we ended up spending all this time building the wrong thing. And that got me kind of curious about how do we make sure we build things that people want?

Kent C. Dodds (04:00)
Yeah, like lots of thoughts on that. It's the pre optimization, know, premature optimization sort of thing. Yeah, when you said building the right thing is kind of downstream from or yeah, building the thing right is downstream from building the right thing. So like you build the right thing first. I think.

⁓ A couple of things came to my mind. So first is the make it work, make it right, make it fast. ⁓ I think a lot of engineers would be familiar with. And the primary reason for that is because if you go for make it fast and you spend all this time making the thing fast, then you find out later that it's done wrong. And so you have to completely re-architect it. And then you find out later,

that it doesn't work in the first place ⁓ or like it's not the right thing or whatever. So ⁓ I think like that resonates with me a lot. And then ⁓ the other thing that occurred to me was ⁓ this actually stuck with me quite a lot. Adam Dodd from the Everyday Astronaut ⁓ went and interviewed Elon Musk on Starbase. And one thing that he said that stuck with me is,

a mistake that a lot of engineers make is optimizing the thing that should not exist. And I think that's something that is easy for us to do when we're focused on building the thing right rather than building the right thing.

Wayne Allan (05:32)
Absolutely. Yeah. And like, I think back to this example, ⁓ we probably could have launched something in two weeks and ⁓ done the integration manually, sent things through that to our integration partner with just a developer emailing it through. We could have tested the market and learnt a lot of things very, very quickly and not invested a whole team, which I think at the time was like,

1.2 million Australian dollars. So it was a huge investment. And I think one of the challenges was that people were just so confident about the success of the product because they'd had so much success with the flagship product. And so there was a disconnect between the product managers and the software engineers and they weren't talking.

Kent C. Dodds (06:05)
Wow.

Hmm

Wayne Allan (06:29)
and context wasn't kind of making it into the team. And so, you when I think about product engineering, I think about software engineers caring about all of the details around, you the, I think the customer experience and the commercials of the product.

Kent C. Dodds (06:52)
Yeah, that, ⁓ yeah, you said a couple of things like the product ⁓ managers and the developers weren't talking. We could definitely talk about that too. And then you mentioned ⁓ like doing the integrations manually. Of course, integrations are always where things explode and complexity and challenge and ⁓ cost. And so that makes me also think of the idea of doing it the hard way first. ⁓ And I have had...

A lot of people who ask me for advice and tips on building an app or something, I've got a neighbor who asked me to ⁓ kind of help guide him on stuff. And he had just this really big ⁓ idea, ⁓ a big product that he wanted to build. And I just told him like, you really should build like a really small thing first, something you can do in just two weeks or something. This was about a year ago. And just this last ⁓ week,

He said, hey, we're almost done. This is ⁓ over a year of working on it. And he added all of these different features that he wanted ultimately, but decided like, I told him you should do this later, test the waters, make sure you've got actual customers who are going to be interested. And see then you talk to the customers and they can start asking for things. And you find out you never needed this feature in the first place.

Wayne Allan (07:52)
You

Kent C. Dodds (08:16)
So ⁓ I'm really worried about him launching this ⁓ to find out that nobody cares, nobody wants it or whatever. And he spent all this money, all this time putting together this big thing that he solved the problem that he actually didn't understand.

Wayne Allan (08:34)
Yeah, and I think this is ⁓ more of a problem with with vibe coding, being able to kind of create all these features. I will say one good thing about it is it does get people to that moment a bit sooner where they build all the features and no one uses it. ⁓ So I call that the field of dreams, know, that if build it and they will come, there's this kind of idea of just one more feature, man, and then everyone will flock to my app. ⁓ Yeah, and so.

I have a similar situation where people come to me and say, Wayne, can you, you you can build an app. I've got this great idea. I'd love you to build it. And, know, and I'll often ask them or suggest a lo-fi way of testing their product idea. I'll say, you know, hey, you can do this with a Google Sheet. You can do this with like a type form or whatever. And

Kent C. Dodds (09:27)
Yes.

Wayne Allan (09:32)
you can see the excitement drains from them as I suggest all these lo-fi ways. And that's often a tell when they're in love with their idea. And that's a big thing to be aware of as like when you're doing product is falling in love with your own ideas. And there's kind of a principle there where you kind of want to fall in love with the problem and fall in love with the customer. I think that's kind of just a good principle to hold. Otherwise, yeah, you end up

Kent C. Dodds (09:35)
Yeah.

⁓ yeah.

Wayne Allan (10:02)
creating these monstrosities and then when they fail you take it really personally and that has kind of this negative reinforcement loop where you just lose I guess steam and you lose kind of passion and so you've wasted all this time because you're in love with your own idea.

Kent C. Dodds (10:08)
Yeah.

That is such a solid takeaway. I wanna make sure anybody listening right now doesn't miss this. You fall in love with a problem. what that means is when you say, when somebody comes to you or maybe it's your idea, you go to somebody and you tell them what the problem space is and you tell them about your solution and you're all excited about it and they say, couldn't you just use a Google spreadsheet to solve that? Just to see if it works. If your reaction is just sadness,

Wayne Allan (10:27)
You

Kent C. Dodds (10:52)
then you loved the solution. But if your reaction is like, ⁓ yeah, like that would be so much easier. And you're like really excited about like, this is actually a solution that I could just try. Like that means that you love the problem, that you want to solve the problem. That's really, really great idea.

Wayne Allan (11:12)
Yeah, it's a thing I look for when I'm interviewing product managers is are they in love with the idea or are they in love with the problem? And I have knocked people back ⁓ because they had this mentality of when I'm the boss, we'll do all my ideas. So that's something I look for for a good product manager. I think when you're an engineer and you're not so attached, but I think as engineers are moving into that space, it's something to be aware of.

Kent C. Dodds (11:43)
So I was having a conversation similar to this with Jamin who he's gonna be coming on to the ⁓ podcast series later. ⁓ So I'm looking forward to talking with him about this. one thing that he mentioned in that conversation was that ⁓ if you're having those conversations with a new client or something, it can be really disheartening to hear that your idea can be solved by a spreadsheet. ⁓

And especially in the consulting business, you don't want to lose their business. And so you want them to stay motivated and engaged and don't lose the energy. And you do consulting as well, if I'm not mistaken. So how do you manage ⁓ both sides of this? it's, yes, we want to keep things realistic. We want to ship something and iterate, but then we also...

⁓ want to maintain the excitement and the energy in solving the problem.

Wayne Allan (12:48)
think there's a few ways we can answer this one. ⁓ Well, there's like many aspects that we can talk through this one. I think ⁓ I did a bit of theater at school and ⁓ this is probably cliched now, but there's this yes and kind of mindset where you take an idea and you might maybe highlight the great parts about it. go, yes, and what if we focused on this aspect?

of the idea. So you're kind of trying to point people into the right direction without saying no. Because as soon as you say no, people kind of just disengage. And so ⁓ it's a really destructive word. And so I think that is one of the techniques is you say, yes, and what about these things? Let's focus on that area. That's kind of how I deal with that part.

Kent C. Dodds (13:25)
Mm-hmm.

Yeah, kind of as a follow up to that idea, is this something that in those kinds of meetings, you can't, maybe not in the meetings, but like just in the attitude, can that attitude be trained in somebody? Whether that be like the business idea guy or in the developer who is like, and we wanna make sure that this can scale to every person in ⁓ Australia. ⁓

⁓ How do you, is it possible to, for somebody to learn that and to be trained in like that proper balance?

Wayne Allan (14:07)
You

Yeah, think actually engineers are best positioned to do this. Again, some of the best engineers I've worked with will often have some of ⁓ the greatest ideas on how to implement something or how to compromise to achieve a product outcome. And so they can be the ones suggesting, hey, well, if we did it in this way,

we could satisfy that customer need and we could do it in two weeks. ⁓ And so that yes and mentality is just like finding a way to achieve that particular customer need. ⁓ I think a lot of product managers just don't have the technical know-how ⁓ to do that. you know, I would often bring my ⁓ tech lead with me to a lot of conversations because he could connect the dots on the systems that he was, you know, an expert in.

and come up with solution. So I think that's something to think about as far as the of the talents of the software engineer and getting them invested in the product outcome.

Kent C. Dodds (15:28)
Yeah, you know, I think that this is one attribute of software development that has not changed ⁓ in like 50 years or whatever, like really understanding the problem space and being in love with the problem space, but also having real empathy with the customer. I know for myself, I am most excited about and do the very best job in projects where I am the user because that's like ultimate empathy, right? Like you really understand where it's falling short and

all of that, whether you have the skills to solve those problems is another ⁓ value of being a software developer. But understanding and having empathy with the customer ⁓ is really a key piece to this and it has always been a really big and important valuable aspect of a software developer. What is changing is that it used to be that you could ⁓ provide a lot of value by just churning out the code.

not as valuable as it used to be. Now the real value is in knowing what direction to point your arrow so that it actually hits the target.

Wayne Allan (16:39)
Yeah, think, think, um, you know, LLMs have definitely sped things up. Um, but one, one thing I think maybe this is, I don't know if this is a controversial take or if it's, it's, it's, think actually cloud computing, AWS sped things up fast enough that we could, we could create more applications than we, we ever needed to. remember when I first started it, know, physical hardware,

was very much required and that had huge amounts of lead time. And so I think this has actually been a problem for longer than people realize. We've been actually able to build fast enough, but we actually not been able to validate with customers at the same rate that engineers could build. And so a big problem I see in large companies is that they spend six months validating an idea.

Kent C. Dodds (17:11)
Hmm.

Wayne Allan (17:37)
you know, again, that's what got me into this. so, yeah, so I think it's really fascinating. People say LLMs sped up, but I think this has been a problem even for product managers and organizations validating ideas and the speed of which we can add value. Yeah, that's a thought that I've been having. it's probably engineers are not the first ones to face it. ⁓

product managers have been quietly sitting on this problem for a while.

Kent C. Dodds (18:10)
⁓

Yeah, can you dive into that problem a little bit more? why is this such a problem and how do you combat it?

Wayne Allan (18:20)
Yeah, so we touched on this a little bit earlier.

is that people are in love with the ideas. So there's that at play. People don't like their ideas killed. And so it requires a certain level of vulnerability. So there's like a bit of ego death in there. But also I think talking to customers seems to be a challenge for a lot of folks. And

talk about people who doing it really well. think, you you look at Cursor, Versel, Cloudflare, they spend a lot of time on X talking to their customers. And again, their customers are software developers who are on X and Twitter. ⁓ And so those feedback loops are really, really short. If there are problems, they're kind of immediately addressing them as they're arising. And it's great to watch. But many industries don't have the same level of access to customers.

even for the product managers, there have been times where for me to talk to a customer, I've had to schedule something for two weeks time. And that makes it really difficult to validate an idea when your feedback loops are really, long. And I think one of the transferable skills between engineering and product is thinking in feedback loops.

Kent C. Dodds (19:40)
Hmm.

Wayne Allan (19:50)
Like we have, you know, CI and unit tests and all of that kind of stuff. And, you know, we care about how quickly those things run. And I think in product management, we don't often take the same attention to how quickly we can get feedback from our customers. And so, you know, at the worst case, you end up with these huge studies which run for six months. And then by the time all the insights are delivered,

They're almost meaningless because the industry's moved on. And like, that's just, that's kind of, that seems kind of insane when you say it out loud, right? ⁓ But that research is so expensive to do. So I think, as a product engineer, if you're in an organization where you don't have those feedback loops, I think the action you would take is to kind of escalate that with your product manager.

Kent C. Dodds (20:31)
Yeah.

Wayne Allan (20:49)
kind of start making noise about it, saying, you know, can't act as product engineers unless we can talk to customers or have a direct line to them. And one of the organizations I've been working with recently has set that up. They have preemptive bookings so that they can ⁓ have conversations with customers. They don't know what the conversation is going to be, but it might be in like a certain domain, like let's say payments.

And here's a bunch of customers who are happy to talk about payments. We don't know what the subject is, but we've got these slots and you can book them in. it's kind of, ⁓ I guess, ahead of the need and making that more of a regular cycle of talking to customers. Another way of doing it is writing shotgun with the sales team. If you're in an organization that's heavily driven by sales.

Kent C. Dodds (21:42)
Hmm

Wayne Allan (21:45)
you can get a lot of insight by just jumping in the car with them and even just sitting there. You don't have to say anything at all. You can just kind of listen to the salespeople ⁓ talk, but you can even just ask the sales team. The sales team will have their finger on the pulse of what customers are asking for and what they care about. So that can be a great way of informally getting feedback. And the support team as well. In fact, support.

Kent C. Dodds (21:56)
Hmm.

Wayne Allan (22:14)
support folks often make some of the best product managers because they've spent so much time on phone calls ⁓ with customers, hearing all their problems, hearing every edge case, kind of getting to the why of...

getting to the why of maybe a request or drilling down those two or three levels to actually figure out what the problem is. So you can kind of talk to customers, like use them as a proxy for talking to customers. You can sit on calls, all of that kind of thing. ⁓ So I bring this up because I think sometimes, I see this in product managers actually, they get really hung up on having all these formal feedback loops instead of kind of maybe being a bit scrappy.

Kent C. Dodds (22:51)
Mm-hmm.

Wayne Allan (23:06)
my advice to people getting into product engineering is to kind of be a little bit scrappy. You don't have to have a, what ⁓ would you call it, a potentially a watertight argument or a statistically significant insight. Maybe this is like a hangup I can talk through is that you'll often see people trying to get product insights.

and they want to run these statistically significant studies and they want kind of a bulletproof case for why they're investing in a certain feature or a certain product and they get really uptight about needing that level of certainty. my advice to people getting into the product engineering space is that everything's uncertain, everything's a bet. And so how do you...

make that bet as small as possible and execute it as quickly as possible. So that's why lightweight conversations with customers is probably the best thing, even though it's not maybe a legally binding or something at the quality of a court case with evidence and all that kind of stuff. It's just quick and fast and you know.

Kent C. Dodds (24:10)
Hmm.

Duh.

Wayne Allan (24:32)
some small insights.

Kent C. Dodds (24:35)
Yeah, yeah, like you're developing intuition for yourself as a software developer. And like so many things that I thought of as you were talking about that, it sounded like you were saying that a software developer hanging out with salespeople and support people, going out to lunch with them, having conversations is actually a way to make yourself a more marketable and valuable software developer, which might take some developers off guard a little bit.

Wayne Allan (25:04)
Yeah, well, like I would call myself a raging extrovert. So it's very natural for me to be able to do those kinds of things. And people who are maybe more introverted might find that a bit of a struggle, but it's worth pushing yourself ⁓ to try and do it. I will say one of the problems of being an extrovert in these positions is listening. So you often want to tell people your great ideas or empathize with them and actually like...

Kent C. Dodds (25:27)
Haha, yeah.

Wayne Allan (25:32)
learning how to be quiet and listen is, so there's struggles from both kind of personality types, just to kind of...

Kent C. Dodds (25:40)
Yeah, yeah.

See, you can relate to the introverts too. There's struggles, we all struggle.

Wayne Allan (25:46)
That's

right, we all struggle with that.

Kent C. Dodds (25:49)

Yeah, I also really liked that you said that the feedback loop doesn't have to be some big formal thing. And in fact, it potentially is better if it's not because it helps you avoid the trap of scheduling out, you know, seven weeks or six months or whatever. And it just makes me go back to what we were talking about before with your first example, where you're just

pre-optimizing all of this stuff and the end result is not actually what you need. So I really like doing things the scrappy way. Do it the hard way first. And then like once you figure out the shortcomings of that hard way, then you can start optimizing. But if you just decide, okay, we're gonna do this big program now at our company, we're a user focused company and now we're gonna do this thing, you'd probably do it wrong.

Wayne Allan (26:39)
You'll probably do it wrong. You'll probably spend way too long doing it wrong. And that's a huge, know, so much, so many companies are wasting millions and millions of dollars on these big programs. And it's kind of, again, a negative cycle. So what will happen is they'll spend 12 months building the wrong thing, you know, flush millions down the toilet, and then they'll want to avoid that. And so,

Kent C. Dodds (26:43)
Yeah.

Mm-hmm.

Wayne Allan (27:08)
What happens is they then go, well, we need this very formal PRD, like products, requirements, document, and we need to have solid numbers, well researched. need really high confidence that we're pursuing, we're not gonna waste money again and that this pursuit is right. And that's kind of doubling down on a bad practice to begin with. Now, I think you can...

Kent C. Dodds (27:33)
Hmm.

Wayne Allan (27:37)
When you're going after a big market, you can do things like market sizing and kind of understand the total addressable market. The problem with that initial scenario I talked about was that our flagship product was doing something like 500 million and the market was still very big, right? The total addressable market for this adjacent product was 30 million. So it's like paled in comparison.

Kent C. Dodds (28:06)
Yeah.

Wayne Allan (28:07)
And if you captured the whole market, would still be ⁓ such a small amount of money compared to the flagship product. So, you can kind of just look at it from a magnitude, the magnitude of the opportunity and kind of rule it out straight away. And I think I worked with an executive and we were working on some ideas. And I remember him just pulling out a scrap piece of paper, drawing some numbers and then saying, yeah, we should go after that.

Kent C. Dodds (28:15)
Hmm.

Yeah.

Wayne Allan (28:37)
And I think this was my first foray into product. And I was kind of gobsmacked. I thought there was going to be way more formal kind of proof and research. But it was like, I'll get the finance people just to validate my assumptions, but then let's go ahead with it. And that was groundbreaking to me of just how scrappy even an executive can be. Yeah.

Kent C. Dodds (28:58)
Hmm.

Yeah, I mean, maybe that's what made him a or the executive an effective executive is being able to make those kind of snap decisions. ⁓ the tricky thing here in this kind of leads me to my the next thing I wanted to ask you about is while we're going scrappy and while we're iterating, I ship something, know, MVP and then iterate on it and all of that. ⁓ I think that we have and you actually mentioned this to where we had

hardware was like ⁓ a factor that made it really hard to ship things quickly. And in particular, hardware that you would install in the customer's own location or you would package up and people would buy it, ⁓ you had to get it right. now you really don't. And I think that's great in some cases, but we also, I think have gotten very too used to.

having software that doesn't work. Or maybe it's mostly our expectations. ⁓ If you are an early alpha customer for a product and you know that you're an alpha customer, then it's okay to have a couple bugs in there. And maybe that's kind of what, ⁓ I'll put words in your mouth. Maybe this is your response, is being more clear. ⁓ But I think that we have just gotten into this epidemic of software just not working.

And ⁓ especially now that it's so easy to ship software, ⁓ we're just, you know, ship it and then fix the problems. ⁓ So where's the line there? How do you manage that?

Wayne Allan (30:36)
Yeah, this is a really interesting topic. I think there's a thing called the logistics growth curve, and it's just an S curve, if you remember from maths. And that's the time it takes for people to adopt a product.

Kent C. Dodds (30:55)
Hopefully it's a true S curve and not a bell curve.

Wayne Allan (30:59)
Yeah,

maybe. It's like if things look exponential and then they turn into an S curve and then it turns into a bell curve. I think about this with Apple, actually. This was their first example I saw of this is Apple can't ship more phones, even if they wanted to. So they could. They could ship a lot more phones, but people wouldn't adopt them. know, people change phones maybe every two to three years.

Kent C. Dodds (31:05)
Yeah.

Wayne Allan (31:27)
And so they can't ship more phones because the market just won't take them. ⁓ And I think that's the new bottleneck for software development is that I think we're actually seeing this with Claude code is that they're shipping so many features, people just aren't adopting them. And they're kind of overwhelmed by the amount of features that are coming out. And they're slightly fatigued.

Kent C. Dodds (31:48)
Hmm.

Yeah, I see that from

Cloudflare as well. It's impossible to keep up with these features. Like, Bun is another example of this in the JavaScript ecosystem, just constantly like in the next version of Bun. Here's the thing, I'm not complaining, but it is very hard to keep up with all of these things that are coming out.

Wayne Allan (32:11)
Yeah, yeah, look, thoughts on Bunn is I thought probably they should have focused on being a full drop-in replacement for Node.js, but there were still areas. And like if I was thinking about product managing that, it was really cool. They had all these other ideas, which were really exciting, but they kind of missed some foundational ideas. And so there's actually a mental model for this. It's called the Kano model.

and there's kind of three categories of features. So one is called like a hygiene feature. And I like to explain this with a hotel because it's slightly humorous. If there's no toilet paper at my hotel, that's a bad experience. But if I have 100 rolls of toilet paper, it doesn't increase my good experience of a hotel. So there's a certain amount of that feature you can't deliver anymore. In fact, if there's 100 rolls of toilet paper, I might be worried about the food.

Kent C. Dodds (32:59)
Hmm.

Hahaha, yeah.

Wayne Allan (33:12)
But then there's performance features. And so if you think again, in the hotel industry, they have the star rating from one star hotel to a five star hotel. All the features along that are very well understood by the industry. And that's kind of what makes it a one star or a five star. And then there's a feature set called Deliders. They're unexpected.

by customers. so if you went to a hotel and they had a free taxi service that drove you around, that would be a delighter. That's not something that hotels often offer. And so when I think about something like Bunn is that they've done all of these delighter features but haven't maybe taken care of some of those hygiene features, which is fully implementing that as a node drop-in. And so

That's a mental model I often think about as a product manager is can I get away with maybe leaving some of those hygiene features out? There are definitely products that have launched successfully that have actually said we're not going to do any of those and we're actually just going to bank on just being a complete delighter and we're not going to implement all these other things and we're just really going to focus on this delighter. That's worked really well for them. ⁓ But yeah, a lot of the time you have to think about

the mix of features that you're delivering and what your strategy is. If you're not going to delete, if you're not going to, sorry, if you're not going to implement some of those hygiene features, you may be annoying your customers. ⁓

Kent C. Dodds (34:50)
⁓

I think that's a really good, at least it resonates with me that one of the reasons that I haven't adopted Bunn and a lot of things is because I have lots of dependencies that are using node things that Bunn doesn't support and I don't want to take the time to get rid of those dependencies. Now it's a lot easier to do that now with agents but early on in the bunn days it was just like, are you guys node compatible yet? No? Okay, well I'm gonna continue.

cheering you on because I like you, but I can't adopt that. ⁓ One interesting thing about the delighters is ⁓ I think this is maybe what is going ⁓ into, ⁓ like we talked about Claude and ClaudeFlare, lots of these features are really useful, ⁓ but as we said earlier, they can be really overwhelming. So.

If you're a hotel and you offer that free taxi service, like do I walk into the hotel and there's a big sign that says free taxi service? Like for a lot of customers, that'll be great, but for some, it'll be just like, get rid of me sign, you know, and, in the software world, that's like a notification that pops up and it's irritating, especially if you've really invested in these delighters ⁓ and you as the creator of these things, you're probably really excited about them. You want everybody to know. And so you're going to just pop up things and you have this onboarding process or whatever.

⁓ How do you communicate these to the right people without annoying the people who don't care?

Wayne Allan (36:26)
Yeah, so I think this maybe goes back to the product strategy of how you're going to release something. So if the product strategy is to throw as much mud at the wall as possible, you're kind of doomed from the start. And I think what I'm seeing with a lot of the AI companies and the hosting companies is they are doing this kind of mud at the wall strategy. A company, again, this is such a cliched product thing to refer to is Apple.

Kent C. Dodds (36:40)
Hmm.

Wayne Allan (36:56)
But Apple do product really well and they take their time and I know people say, know, Apple, they're not innovative. I think people often miss the mark that Apple are extremely effective at releasing features. They have some duds from time to time, but most of the things they release like hit the mark really well. They take their time. They keep that feature set small and easy for people to understand.

And if you look at over time, just, kind of keep building up that user base and they keep building up that product understanding ⁓ and build it up like a brick wall so that people know how to use those products and continue to use those products. And they don't overwhelm them with features because they understand it's like, you know, some of those users are like my mum, you know, like I think I taught her to text message like 10 times before the iPhone. But when she got an iPhone, she didn't need any help with all the...

predictive text, she could just... So I think about those kind of things. I think if we go back to the Kano model as well, that kind of performance vector, which is kind of linear, not, yeah, linear.

Building your features in good quality is a part of performance. I would say to a lot of them, really understand the feature you're going to build. So you might use a pilot group to test some of those features out. And this comes to the idea of ⁓ the technology adoption curve. There's a real kind of dynamic.

Kent C. Dodds (38:17)
Hmm.

Wayne Allan (38:42)
between early adopters and the early majority. There's a great book called Crossing the Chasm, and there's this real divide between people who are innovative. I think you mentioned something around like, if you're an innovator, you like to play with new things and test things out, and you're okay with them not being good quality. It's like testing the idea and playing around with it. So you're tolerant to things not being implemented.

Kent C. Dodds (39:11)
Yeah.

Wayne Allan (39:12)
well. And I think AI has kind of existed or that a lot of the LLMs and developments have been really focused on that market or that segment or cohort of the market. But now it's starting to shift over into the early majority. So people at large enterprises are starting to try these things. And the needs of the early adopters versus the early majority is very, very different. And this book, Crossing the Chasm, talks about

Kent C. Dodds (39:20)
Hmm, yeah.

Hmm.

Wayne Allan (39:40)
What worked for your innovators and early adopters does not work for your early majority. They require a lot more stability, a lot more predictability in the way you deliver features. They require a lot more go-to-market, so a lot more hand-holding, which means you can do less features. So if I was thinking about those companies, I would be focused on my innovators and early adopters.

Releasing as much as I can to them and kind of figuring out what works and what doesn't work Once I kind of get that down then I take I go I've got confidence in this feature I can take this to the early majority and and really walk them through and then make sure that early majority and the the late majority Adopt that feature and it gets like penetration into that whole cohort so that's kind of How you would think about it as a product manager?

And I think many of the AI companies are about to find out that they're going to need to do that. I don't think they've got to that point yet, but you're starting to see everyone get fatigued by all the changes. And, you know, I'm working in large enterprises, consulting to them, and I'm seeing that fatigue. People are just struggling to keep up. And so it's going to be a real problem for them very soon.

Kent C. Dodds (41:01)
Yeah, I can see that. ⁓ Well, it certainly makes a lot of sense that the people who are early majority or the early minority, early adopters are willing to put up with things. They're willing to ⁓ click around on the UI and figure things out. people like, she's maybe not an early adopter, she's more like late adopter, laggard. But like doesn't.

doesn't wanna click the wrong thing and it expects it to work. And ⁓ so figuring out how to communicate to those people, the level of stability that you have, and that makes a lot of sense. I wonder, how do you feel like this changes as the human to computer interface is changing? Where like, ⁓ I think we are going to continue to progress in this direction where the agent is the one interacting with the software.

and the user pretty much just interacts with the agent. Does that mean that we now don't really need to worry about, know, posted signs of like, hey, check out this delighter. It can just be as part of the agent and the user just gets used to, this is the job I want done. ⁓ like make that happen however it happens and then the service, you know, exposes the right capabilities.

Wayne Allan (42:25)
Yeah, think there are definitely aspects of user interaction that will be reimagined. ⁓ I think about some of the sites I've worked in, ⁓ in Melbourne in particular, Melbourne, Australia, that's home to a lot of listing ⁓ companies that kind of got really big. So think the back of the classifieds on the newspaper.

they all became websites. So they're all monetized a UI to some degree. So think like looking for a car, looking for a house, ⁓ looking for a job. These companies have monetized ⁓ a search engine and a UI. That all starts to disappear with LLMs. So their moat of filtering and serving

serving up these listings disappears significantly.

I think there's a big shift in the way we look at UIs. You think in Melbourne, there's a lot of companies there that essentially have monetized what used to be in the back of a newspaper. And they've monetized, they've turned that into a website with search and listings. And ⁓ essentially, they've monetized that. And so,

That is being challenged with LLMs because you can now search this kind of content in a different way. You can have such niche search queries. Like if you think about looking for a house, I can put in the weirdest ideas. Like I wanna be in a leafy street. Like I want a street that has lots of...

Kent C. Dodds (44:17)
Yeah

Wayne Allan (44:19)
trees in it. Whereas like, know, to think about implementing that in a search filter, that's that and the amount of kind of things you would need to do. Whereas an LLM could probably look at a map like the the suburb overlay from a satellite and potentially feed that into its search results and go, OK, if I look at the satellite, I can see this is where all the tree coverage is.

So I'm going to focus my search on this particular suburb. And ⁓ if I look at the houses in this particular street, I can now give you an answer that is very specific. Like if we wanted to implement that in a search engine, that's incredibly difficult. So, yeah, go.

Kent C. Dodds (45:07)
Well, and

I was just going to say, like the cool thing there too, from a user experience standpoint, is that the developers don't have to implement that. Up until now, we've had to implement every integration possible. let's say that you're Zillow and you're tasked with actually implementing support for that. Well, now you have to go and find some integration.

with some sort of satellite imagery thing and do all that yourself. Whereas with agents, there's like maybe a service that the agent can go use to get the satellite imagery and then it overlays that on your thing. Like the agent is the glue, which I think is ⁓ part of what makes this user interaction model change so much is that our integrations ⁓ are significantly less ⁓ challenging to create and significantly less

necessary.

Wayne Allan (46:06)

That's right. And so it challenges some of the moats that many of these companies had, which were their integrations and were the fact that it costs so much to integrate ⁓ these kind of data points. And so I think the pivot is to becoming a system of record and a system of transaction. I think that's the shift I'm seeing in the market at the moment is that's what people are thinking about. ⁓ I think the share market got destroyed.

when people realize you could vibe code a SaaS product over a weekend, even though that's like unrealistic if you've ever tried to vibe code something more complicated than brochureware. But the idea is, but the idea of being a system of record and that being defensible. So you're owning the data and maybe owning the transaction, not necessarily the user interactions. So that can like mean bringing things back to being APIs.

Kent C. Dodds (46:43)
Yeah.

Yep.

Wayne Allan (47:05)
that just expose data and text.

Kent C. Dodds (47:11)
Yeah, it's an interesting future, that's for sure. Well, Wayne, I really appreciate you giving us some of your time today to talk about these things. Is there anything that we didn't talk about that you were really hoping we would get into?

Wayne Allan (47:23)
I think we covered so many things. ⁓ I, you know, there's a couple, yeah, I think, I think the great thing is that, that, ⁓ there's a lot of transferable skills from engineering into, into product engineering and product management. So I think you don't have to kind of relearn everything. You can, you can, you can kind of continue, continue on and become more fully stacked.

Kent C. Dodds (47:29)
We went all over it.

Wayne Allan (47:51)
So now you know infrastructure, backend, frontend, you also know product. But my main takeaway from all of it is actually talking to people is the biggest hack and the best advice I was given. Not that I needed much encouragement to talk to people. So maybe I'll caveat with, don't just mean talk to people, I mean listening to people. And by listening, I mean asking good questions.

Kent C. Dodds (47:52)
You

Yeah.

Mm.

Wayne Allan (48:19)
I think

that's probably the biggest hack that has worked for my career is figuring out how to ask good questions and then listen. Yeah.

Kent C. Dodds (48:31)
Yeah,

that is good. And actually that works perfectly because at the end of each of these episodes, I ask for a specific tip or action item, homework if you will, that you can give to the listeners. And it sounds like that's a really good one. Is there anything else that you'd like to encourage people to do?

Wayne Allan (48:49)
And yeah, so talk to people, ask good questions. Listen, I think there's a if you if you want to kind of read up on asking good questions, there's a great book called The Mum Test. And the crux of it is that your mum is always going to tell you that she loves your ideas. Because your mum loves you and and wants to encourage you. And so so one of the good ways to ask product questions.

is to ask them how they've solved this problem in the past rather than asking them, do you think my idea is good and would you use it? You get way more insight asking them what they've done in the past to solve this problem.

Kent C. Dodds (49:29)
Mmm.

That is great. And it also ⁓ goes right back. Like we got a bunch of circles going on in here. This one's circling back to the idea that you don't wanna fall in love with the solution. So you don't tell them your solution. You don't care about the solution. You care about the problem.

Wayne Allan (49:40)
That's right.

That's right, exactly, that's right. We've tied this up into a perfect little bow.

Kent C. Dodds (49:52)
Very good.

That's perfect. Hey, thanks so much, Wayne. I really appreciate you. ⁓ And is there a good place for people to reach out to you if they have further questions or just want to connect and keep up with what you're doing?

Wayne Allan (49:58)
You

Yeah, I'm quite active on X, so feel free to reach out to me there and I'm always willing to have a chat. Either DMs or in public, I'm easy either way. Tag me in whatever you want and I can add my two cents.

Kent C. Dodds (50:24)
Awesome. Hey, thanks so much, Wayne. Appreciate you. And we'll see everybody in the future. Bye-bye.