Episode 245: Building Product Thinking in Engineering Teams with Matt Watson

Join Melissa Perri as she sits down with Matt Watson, founder and CEO of Full Scale, to delve into the evolving world of product management and software development. In this insightful conversation, Matt shares his journey from developer to CEO, offering lessons on how to blend engineering expertise with product thinking. Discover how Matt encourages a culture of ownership and courage among teams, and how AI is reshaping the roles of engineers and product managers alike.

If you're interested in enhancing your product management skills and understanding the importance of clarity, communication, and collaboration in tech teams, this episode is a must-listen. Matt’s insights will resonate with anyone looking to break out of the build trap and focus on delivering real value to customers.

Tune in to gain practical strategies for fostering innovation and empowering your team to think beyond the code.

You’ll hear us talk about:

• 10:15 - Encouraging Product Thinking in Engineers

Matt discusses the importance of engineers understanding the product's broader impact, not just focusing on the technical aspects. He emphasizes the need for engineers to see themselves as part of the product team, contributing to the overall vision and strategy.

• 22:40 - The Role of Clarity and Communication

In this segment, Matt highlights the significance of maintaining clarity in software development. He shares how regular communication and one-on-ones are essential for coaching and ensuring everyone understands the vision and scope of projects.

• 35:55 - The Impact of AI on Engineering Roles

Matt explores how AI is transforming traditional engineering roles, pushing engineers to adopt more product thinking. He underscores the growing importance of emotional intelligence and teamwork as AI takes on more technical tasks.

Episode resources:

Matt on LinkedIn: https://www.linkedin.com/in/mattwatsonkc/

Product Driven: https://productdriven.com/

Full Scale: https://fullscale.io/about-us/

Other Resources:

• Check out Monday dev

• Check the Product Strategy course

• Angel Squad

• Product Institute

Follow/Subscribe Now:
Facebook | Instagram | LinkedIn

Episode Transcript:

[00:00:00] Matt Watson: We need product managers and, you know, higher level executives to help drive strategy, right? What's going on in the market? Bets we're making as a company? All that kind of stuff, right?

I don't expect developers and engineers are gonna jump in and start doing all that kind of stuff, but the engineers need understand at a lower level, like, why are we doing this? And in my book, I create the product driven model and the first of the five things is called vision. I don't mean HR slogan, vision statement, whatever. I mean the vision of like, why are we doing this thing this week? This thing, why does this thing matter?

The best developers we have are the ones that ask a lot of questions. They'll validate assumptions, they'll push back, they'll bring ideas, right? That takes courage. It's a lot easier to just do what you're told, never speak up.

It takes courage to speak up and ask questions to push back, right? I work at this big company, I'm tired of them shoving stuff down my ticket queue and all this stuff is dumb. Why are we working on this? The customers don't care about this. We should do this technical debt thing. The whole system's gonna meltdown 'cause we don't fix these things. It takes courage to say those things, right? It takes courage to speak up. But that starts with the sort of team culture of do I give people space to speak up and say those things?

Is there psychological safety right within the team? Do I encourage people to bring ideas and speak up? Like it starts with that. So to me I think that's the fundamental thing of all this is like the team members have to have courage to speak up and you've gotta build a team culture that incentivizes it, rewards it, and allows it, or otherwise you're just gonna get a bunch of order takers.

[00:01:23] PreRoll: Creating great products isn't just about product managers and their day to day interactions with developers. It's about how an organization supports products as a whole. The systems, the processes, and cultures in place that help companies deliver value to their customers. With the help of some boundary pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you find your way.

Think like a great product leader. This is the product thinking podcast. Here's your host, Melissa Perri.

[00:02:01] Melissa Perri: Hello and welcome to another episode of the Product Thinking Podcast. Today I'm excited to introduce Matt Watson, the founder and CEO of Full Scale, and the author of the new book, Product Driven. Matt's Journey from a young startup founder and CTO to leading a company to a nine figure exit is truly inspiring.

I'm excited to dive into his leadership experiences and learn how product driven strategies can unlock real ownership and impact for technology leaders.

Welcome Matt.

It's great to have you here and I'm excited that you are so passionate about product management coming from the technology field.

[00:02:32] Matt Watson: Well, that's just the way I started my career.

[00:02:34] Melissa Perri: Yeah.

[00:02:35] Matt Watson: It's like, go talk to me and figure out what they need done. Go build it, that's how it started right?

[00:02:38] Melissa Perri: So tell us a little bit about your career, you've done so many different things. What really took you onto the path that you're on now?

[00:02:45] Matt Watson: So first ever software development I did, like professionally, I was actually in college at a tech school, I was doing computer science related stuff, but I was selling computers at Sears and a car dealer came in to buy a computer for me. Of course, I asked him, what do you need the computer for?

What am I gonna sell you? Trying to figure that out. I ended up rewriting a visual basic six, like Microsoft Access database for this guy, and this was like 25 years ago. But that was my first experience in software development. Like I literally went to car dealership, sat down next to the guy, and it's like, this is a report I need, I need to do this thing.

Like it was very much product thinking from the beginning. That's how I started my career. then I started my own SaaS company when I was about 22. And so I never worked in big tech, never worked in a big company.

[00:03:31] Melissa Perri: That's really inspiring. 'cause there's a lot of engineers I feel like, who are still figuring out product thinking, but the best ones I've ever worked with, they get that. They get those things. So can you tell us a little bit like what motivated you to write Product Driven?

[00:03:46] Matt Watson: Yeah, so today I have over 250 engineers that work for me, over 70 clients we, we do work for. Now, really consistently, we hear from our clients that the engineers that they love are the ones that ask all the questions, they validate assumptions, they push they bring ideas, right? They, they collaborate.

They're really good at communication. They're really good at collaboration. And the ones that aren't so good are the ones that don't ask any questions, just say yes. They just follow the statement of work or the project requirements. They just basically do what they're told.

They're just order takers About, uh, a year ago, summer of 2024, I went and did a, a keynote speech at a dev conference in the actually. And I decided to do it on this topic about how software engineers need to think outside the code. They need to think more product than the customer. And that, that really just inspired me to keep going down this journey. And I renamed my newsletter and then decided I wanted to write a book. And yeah, here we are.

[00:04:40] Melissa Perri: That's really cool. And in the book you talk a little bit about this concept of product thinking, which is the name of this podcast. How do you really define product thinking and what does it mean for engineers to do product thinking?

[00:04:53] Matt Watson: I think as software engineers we stare at our computer all day, and we think more about the code, right? It's like kind of playing with Legos all day. And, and we love tools. We, you know, we, we like to solve hard problems and all this. But if you're not focusing on the customer and the product and focusing outwards, right?

I think about it like focusing inwards versus outwards. If you're not focusing outwards on the customer, you're focusing inwards, which is just basically on the code. You're like, my, my code is my product, but it's not, nobody cares about your code. They care about what your code does, right? They care about the higher level purpose of this, and I think that's the struggle with most teams is they're very inward thinking.

They're just thinking about the Jira ticket, the code that needs to be done. The requirements need to be done. And just shipping their, part of the thing. as a leadership, we've gotta get everybody always aligned and focused on, the product, the business, the customer. Like why does this matter to the customer?

Because it's so easy to just be like, oh, we're having fun playing with our Legos here. Like we're just building cool stuff with our Legos, but we just lose sense of why.

[00:05:55] Melissa Perri: And a lot of the teams that I work with they're still figuring out like the boundaries I think between product management, engineering, design. And they might be listening to this going, Hey, I'm. Of worried like my engineers, if they get more into product thinking like, what am I supposed to do as a product manager?

Can you talk about what's it mean as a product manager and an engineer to work together where you're both doing product thinking?

[00:06:17] Matt Watson: I think we all need access to the same information, but some of it's just through different lenses, right? We need product managers and, you know, higher level executives to help drive strategy, right? What's going on in the market? Bets we're making as a company? All that kind of stuff, right?

I don't expect developers and engineers are gonna jump in and start doing all that kind of stuff, but the engineers need understand at a lower level, like, why are we doing this? And in my book, I create the product driven model and the first of the five things is called vision. I don't mean HR slogan, vision statement, whatever. I mean the vision of like, why are we doing this thing this week? This thing, why does this thing matter? And to me it starts with that of, you know, the product team, helping, making sure the engineering team know, like, why are we doing this very specific thing? Why does this matter? And how do we know, at the end of this if it worked or didn't work, and how do we get feedback on if it worked or didn't work, right? So I think it's making sure that everybody works together on all of these things and we don't want the product managers to also be the gatekeeper of all the things and be the only people who drive what needs to be done.

I think everybody needs to have. A voice and a boat, like the engineering team may also know way more than the product team does. Like a lot of times companies hire these product managers that come in, the product managers don't really know anything. They're like, they just, this is their first day on the job.

They don't understand the legacy of everything, how the product works, the market, the industry, all the things. Or maybe the engineers even know way more. You know, and, and it's always difficult to balance things like technical debt and maintenance and all these other things. And a lot of times developers are more focused on that stuff and not enough on product. Which I'll be the first one to say, is one of the biggest problems there is. But as leaders, we have to just figure out how to strike the balance of all these things, right? Like we have to lead and get everybody's vo voice and everybody's vote, but we're gonna have to make the decisions.

[00:08:07] Melissa Perri: Your dev team is shipping faster than ever, but your tools, they're still stuck in 2012. Monday dot com's dev platform changes that With Monday Dev, you get fully customizable workflows, real-time visibility across your development lifecycle, and seamless GitHub integration without admin bottlenecks slowing you down.

Whether you're working in the platform or straight from your IDE Monday Dev keeps your teams aligned, focused, and moving fast with AI powered context builtin. Go to monday.com/dev and see how your team can build without limits. This is a common issue I see as well in teams that have, product owners, let's say, who came from this Scrum type background. I feel like I, I work with this all the time where they're used to putting these things onto the backlogs and I see this issue where the engineers are lost. They're like, I'm not sure what I'm doing.

And it's because the product managers haven't built the context that you're talking about. Like, why are we doing this? Here's, here's the picture of the long term where we're going. Yep. All this stuff.

[00:09:04] Matt Watson: are we doing this and not that?

[00:09:05] Melissa Perri: Yeah, exactly the trade-offs. But also what is this gonna be at the end of the day rather than build this button, build this feature, and break it all down.

And it's interesting because I do see a bunch of product people out there not understand why that's so important for development. So can you tell us a little bit about, a story or what you've seen change with teams when they start to shift more towards a product driven approach and how it helps engineers be better at their jobs too?

[00:09:30] Matt Watson: I think software engineering is so much about the trade-offs, right? It's are we going fast or are we making something that's like military grade bulletproof, like we're shipping this code to Mars, right? And everywhere in between. There's a lot of different kinds of trade-offs, right? From performance, stability, speed, all these different things.

And, as software engineers, a lot of times we're navigating a lot of ambiguity. Like we get weird requirements. We don't understand why we're doing this. We don't understand how it's gonna be used. That may force us to over -engineer things 'cause we don't really understand do we need this fast?

Is this gonna support a million transactions a second? Is this just a demo for the CEO to show the board and it doesn't really matter, maybe we could have vibe coded this thing. It's all over the board, right? So if as engineering team, if I don't understand like why and what the purpose of this thing is. Lot of times they're gonna over-engineer things. And I think that's one of the challenges.

[00:10:25] Melissa Perri: So when a product manager is working with the, the engineers, like what do you think is a good practice or a good way tactically to start to get them up to speed on why we're doing this? What do they need to know?

[00:10:38] Matt Watson: As I mentioned earlier, I think it's that sort of tactical product vision. Just making sure that they understand like, why are we doing this specific thing? Why does this thing matter? And I think one of the other challenges in a lot of teams is the engineers get spooned fed too many of the details and don't time to think they're not part of they don't under, they don't understand the big picture. I think as a product team, it's important. It's important to tell them the what and the why, but be really careful about telling them how, because they need to engineer that part of it. And if you're going into too many details about the how things need to be done. Then they're just order takers, and maybe you could just tell AI to write the code anyways. At some point here, right? Like it should be their job to figure out the how.

And I think it's also important to, you know, we think about really want to build teams that have more ownership and autonomy in their work. You gotta leave a little bit of space with the team to feel like they're contributing to this, not just being told what to do all the time. Like even if you know what you want to get done, like 90% of the way, you can still have the conversations in a way of: Hey guys, this is what we're trying to accomplish, how do you think we should do it? And maybe nine times outta 10 they're gonna say what you wanna do anyways. But now they're more motivated to do this 'cause they felt like they actually had a voice and opinion.

[00:11:54] Melissa Perri: One of the questions that I get written into from Dear Melissa all the time, which I've answered a couple times on here, is from product managers who say, I try to involve my developers in the conversation about who our customers are, why we're building this or whatnot. And they're like, just gimme the spec, right? I just want the spec, don't don't bore me with this stuff. Like I just tell me what I'm supposed to do.

And there's this struggle where I feel like they're the product managers are like, I know I should be like giving them the context. I should be doing this. But they're pushing back on me and they're like, nah. I just wanna sit here and code. I don't wanna be bothered with those details. Where do you think some of that disconnect might be coming from? And what should a product manager or a developer who's been in those situations look into to figure out what's going on there?

[00:12:41] Matt Watson: I think, there's different developers that are all over the spectrum of this, right? Like we are always gonna have some software engineers think that way and and a team of 10 engineers, maybe a couple of 'em are that way. It's fine, right? But we also need people that have product thinking that take ownership of their work, that can lead do this higher level thinking is really for a team to more autonomous and have ownership. Because what you're describing is teams that very much are order takers, And you can have a couple of them on the team, but you can't have a whole team of them, or there will be like no ownership of, of whatever it is you're building. So I think it's all over the spectrum, but I, I feel like as aI is changing things. We're gonna have to have more and more people that have higher level product thinking because for these engineers that just wanna be straight order takers, that's what AI, AI is coming for your job. If I've gotta write requirements that are so detailed and so spec out, why don't I just ask AI to write the code and somebody else just review the pull request at this point.

[00:13:41] Melissa Perri: I could see in some companies as well, a lot of people pointing towards leadership and saying, they don't want me to think, they just want me to be an order taker. So if you, for the leaders out there. How do you get your team? It's funny actually to caveat that from the leaders, I hear the opposite.

They're like, my team doesn't take ownership. They don't take accountability. Like I want them to own it. And then the team's they don't let me do that. So as a leader, how do you like build a team of engineers, especially a technology leader too, right? How do you build this team and get them to want to take ownership, give 'em the space to do that? Like what does that look like?

[00:14:16] Matt Watson: Exactly the heart of what my book was about, product driven right, was about a model of how to do that, which started with vision, I mentioned earlier, but the five pieces of the model were vision, focus, ownership, and courage. And, we could talk through all five of those if you want, but I think it a hundred percent starts at leadership.

If you have to create a culture, and I never thought I'd write a book about culture, but a lot of this is culture. It's creating a culture where the engineers are allowed to speak up, they're allowed to have ideas, they're allowed to push back, but a lot of big companies, they're not, they're just order takers.

And one of the things I write about in the book is of times in engineers are so far down the stream. That for them to challenge the requirements or something feels like, the train is already moving, right? Like they're so far down, the sort of assembly line, which really sad that they, they don't have a voice.

And, And there are absolutely some of them, as you mentioned, that want to have more influence. They're, they get tired of stuff being crammed down to them of this is what you need you need to do it, and by the way, do it as fast as possible. Go, go, go, go, go, right? Where they want to have more creativity I just hired a CTO for one of our venture companies and she was very successful at a bank and all this stuff, but the, one of the main reasons she came to work for us, she's I want to have more impact on the product. I want to actually wanna build something, not just be told what to do all the time and engineer this, bank stuff. Like I wanna go create something, I wanna be innovative. And we stifle a lot of that and these big companies. And really what we're stifling is innovation and creativity.

[00:15:51] Melissa Perri: In what ways, if people are not even like recognizing that they're stifling stuff, what are some examples where you've seen leaders do that? What? What are the actions or the behaviors of leaders that you've observed that do stifle that creativity?

[00:16:05] Matt Watson: I think one of the biggest mistakes that software engineering leaders make is how they use daily status meetings. If they hand over the meeting to a product owner or a project manager who basically just gets status updates, they're missing a really critical opportunity to drive clarity where they could meet with the team and understand what everybody's working on, ask the probing questions, make sure everybody understands what they're doing, why they're doing it.

And I think their example of this is some people really like to work async and they don't even want these meetings, but I wanna be able to get somebody on a video call, say something to them, look them in the eyes and be like, do they understand what I just told them?

Do they understand what they're doing today and why they're doing it? Do they have any questions or do they just look confused? So much about software engineering is this type of collaboration. And these sort of daily calls to me are super powerful calls around clarity. Just make sure I understand.

Why are we doing this? This week, this project, this thing, here's the things to keep in mind. Do this, don't do this. We gotta make sure we don't span this API, we don't get blocked. This customer has this big issue, like it's all clarity, it's understanding the why and the big picture. But instead, most companies it's I don't know, here's a requirement.

Follow requirement. Where are we out on Jira ticket J 3 35? This is a pointless call.

[00:17:20] Melissa Perri: Yeah, and I, and there was this push, I think too for like in the daily standups and Scrum for a while where it was just like. Everybody goes around and says what they're working on today, but nobody actually discussed it. And then it'd be like, oh, if you need help, like this is a protected standup. It's only 15 minutes. So like you go talk about help later. Like we don't talk about it together even though it might affect a bunch of people, which I always thought was really weird.

[00:17:43] Matt Watson: Yeah. And that's so a lot of engineering leaders miss, don't necessarily like to run these meetings, but I feel like they're the most critical person to run the meetings because that's where I can check when they engineer and I can sense from my history and my background, it's do they know how to architect this thing? Do they know what they're doing? Do they seem like they're stuck? Do they need help?

I can like really listen in and ask those probing questions instead of just being totally passive to the meeting and totally checking outta the meeting. Nobody's paying any attention to anything, right? Everybody's just reading off, this is what I did today and nobody cares.

[00:18:12] Melissa Perri: You talked about in your model as well about ownership and courage. What does it look like there with the ownership and courage pieces, and how do you see that play out?

[00:18:21] Matt Watson: So courage came from full scale and I mentioned earlier. The best developers we have are the ones that ask a lot of questions. They'll validate assumptions, they'll push back, they'll bring ideas, right? That takes courage. Takes a lot of courage, right? It's a lot easier to just do what you're told, never speak up.

It takes courage to speak up and ask questions to push back, right? I work at this big company, I'm tired of them shoving stuff down my, ticket queue and all this stuff is dumb. Why are we working on this? The customers don't care about this. We should do this technical debt thing. The whole system's gonna meltdown 'cause we don't fix these things. It takes courage to say those things, right? It takes courage to speak up. But that starts with the sort of team culture of do I give people space to speak up and say those things? Or when they do speak up, do I ridicule them in, in, in front of the team and shut them down?

Is there psychological safety right within the team? Do I encourage people to bring ideas and speak up? Like it starts with that. So to me I think that's the fundamental thing of all this is like the team members have to have courage to speak up and you've gotta build a team culture that incentivizes it, rewards it, and allows it, or otherwise you're just gonna get a bunch of order takers.

[00:19:31] Melissa Perri: I see that a lot with product managers too when they get into the order taker mode, right? It's a, oh my, my boss told me that we're gonna go build this feature and gimme all the specs and stuff, and then I'm just gonna pass it to the engineers. And so many

[00:19:43] Matt Watson: that's the easier thing to do.

[00:19:45] Melissa Perri: It's easier, right?

Like you don't have to think, you just go, whoosh. And then they come and they say, oh I don't think we should be doing it, but I'm afraid if I bring it up, I'll get fired. And I'm like where's that fear actually come from? And sometimes it's unfounded. It's you just think you can't speak up.

Sometimes there is a culture of fear or something. But like I've had many people where once they, get that courage, they go back, they push back a little bit in the right ways, right? You're not gonna go scream at somebody that you're wrong and you shouldn't be doing this, blah, blah, blah, blah. But if they go back and push in the right ways, I've seen so many people be like, oh yeah, you're right. Thank you for bringing that to me. And they get promoted. They're the ones who get the bigger opportunities. And you are right though. There's, there is this lack of pushback sometimes where everybody thinks it's scary to go question things.

[00:20:31] Matt Watson: And that starts from a leadership perspective, right? We have to set the standard that's okay, and like we're hiring a executive assistant. And when I interviewed them, the first thing I told them, I'm like, your job is to pester me every day to do the things I need to do. You're supposed to pester me every day, and that's okay. That is literally your job.

[00:20:48] Melissa Perri: Yeah.

[00:20:49] Matt Watson: Chase me around because if you don't chase me around to do these things, it's like, why did I hire you? This is what I need you to do. But the other thing to keep in mind is you're dealing with, especially if you hire people globally, you're dealing with different cultures all around the world and different cultures around the world, or or, treat these things differently. Some people are very direct, some people are very indirect. Some people come in from coun countries and culture where you don't question your manager or, you don't question your superiors. So you really have to understand who you're working with and understand their culture and know how to help them along.

So it's hey, I know maybe you wouldn't normally do this, but I need you to speak up. I need you, you can push back. It's okay.

[00:21:26] Melissa Perri: This is okay here. How do you also create that space as a manager? What types of behaviors or habits should you put in place to let people know it is okay, or I do encourage you to do these things?

[00:21:37] Matt Watson: I think that's one of the best outcomes of doing one-on-ones with people and building real relationships with people where you have you feel like you have a working relationship with them, you have some rapport with them, so you're like, Hey, if I go back to them and tell them like, I don't think this is a great idea, or this is gonna fail, or maybe we should consider this like.

It feels okay to have that conversation versus I don't know, I always show up to these status meetings. I literally never say a thing and I don't talk to this person and I don't have any kind of rapport with them. It feels way more difficult, feels, way more overwhelming versus oh, I have some relationship with this person, I feel like I could go talk to them about this. So as leaders, like we have to make sure we build that relationship with people.

[00:22:15] Melissa Perri: Yeah. I see a lot of leaders that wanna just skip their one-on-ones because they think it's not important or, oh, That person's on track, it's fine. Let 'em just keep going.

[00:22:23] Matt Watson: That was me. I always hated one-on-ones. Hated doing.

[00:22:26] Melissa Perri: What made you go, I need to change this?

[00:22:28] Matt Watson: I think it's this kind of stuff. It's just understanding that if you want to scale, the goal is to scale a company to be more than you. And at some point in time in my career, and I wrote about this in a book, you realize like the most productive thing you can do is make everybody else more productive.

At some point in time at least for me anyways, not everybody, but for me, when I was younger in my career, I felt like I could just do everything and just put it all on my shoulder, all figure it all out. And if I can't figure it all out, I'm just a failure or whatever. Where eventually I get to the point where I can't do all this stuff.

I've gotta have a team. I gotta grow, I gotta scale. And this is how you do it. It's through one oh one-on-ones, it's through driving clarity, having these kind of meetings. Beating the drum every day of why are we doing this? So when they get stuck or they have questions, they're like, oh yeah, Matt talked about this thing the other day.

Yeah. I bet. I bet I know what he wants. So let's go do this thing, but that all just comes to a lot of communication. A lot of it's teamwork and leadership.

[00:23:20] Melissa Perri: I feel like if people are probably using their one-on one-on-ones ineffectively too. How do you do one-on-ones and what do you see work best there?

[00:23:27] Matt Watson: So currently I do them with three or four different people, and usually. Talking about what are we working on and different stuff, but also as an opportunity to give them that candid feedback. And I think one of the most important things is trying to identify those coachable moments.

Hey, something happened in the status meeting this week, or the retro meeting or whatever, and it's ah, when I talk to them again next week, I wanna go back to that moment and coach them on Hey, they could have done this differently, keep this in mind, whatever. I think it's about identifying those coachable moments and not forgetting about them and making the most out of 'em. Because that's where people can learn the most. You're like, oh yeah, I was involved in this thing. And so I really relate to the moment, right?

You can really coach them on what, what happened. I think that's one of the key things is trying to figure out those coachable moments.

[00:24:16] Melissa Perri: Yeah, and that's good. It keeps people apprised too, of what you're thinking about, what you care about as well.

[00:24:20] Matt Watson: And I think that's one of the, I think I mentioned that in the book too, it's as a leader, one of the most important things that, that we need to do is keep telling everybody why we think the way that we think, right? Because they're never gonna have the ownership or create that product thinking and higher level thinking if they don't think the same way, right?

So they're just, otherwise, they're just kind of order takers, right? So it's like you're always trying to explain to them what you're thinking. Why am I thinking this way? Why are we doing it this way? And just getting it out of our heads and as entrepreneur, that's super difficult. Because like I understand what I need to do and I have some natural intuition to it, or I have the product vision for it or whatever.

And it's really difficult to get that out of your head and tell it to other people. And it's super frustrating that they don't all just understand it. They don't all just see it is really hard.

[00:25:08] Melissa Perri: I've definitely been there too. And you have to remember, like it's, they don't have the same context that you do.

[00:25:12] Matt Watson: No. So we have to keep telling 'em.

[00:25:14] Melissa Perri: Yep. When you are thinking about an organization, and we talked about this a little bit, that's operating in the no ownership mode, everybody's an order taker and you are like listening to this podcast and you're like, I'm a leader who wants to turn this around, I want people to take ownership. I want 'em to be more product driven. I really wanna inspire my engineers.

Where do you start, right? Like how do you look around your organization and figure out like what, what needs to be fixed?

[00:25:38] Matt Watson: I think you gotta identify the team members and your team first that want to do this. They want to do more. They're more creative. They care more about the big picture. They care more about the why, right? You gotta start em with embracing those people and when you have meetings, ask them questions, get them to speak up, right?

Ask them for ideas. I think it, it starts with creating that sort of culture of everybody feels like they have a voice and they have an idea. And I think it's important to leave a little bit of space for people to make suggestions and bring ideas, right? Instead of just telling 'em like, Hey, we need to build this thing exactly this way, go do it. Ask the team how should we do it? I already know the answer, but I wanna hear you guys. How are we, how should we do this? I wanna hear you think, I wanna hear why you think this way. Because that's the only way you're gonna get them to coach, coach them through it and get them thinking, switching modes from being order taker to be like, oh, now I gotta show up to these meetings and actually think about what we should do. Like they're never gonna do it.

[00:26:31] Melissa Perri: Looking to level up your product management career? I started Product Institute to help you do just that. Trusted by over 15,000 students in Fortune 500 companies worldwide. Our seven courses cover everything from product foundations to advanced product strategy. Right now you can get our bundle of all courses for 40% off with code Learn2025.

Go to productinstitute.com to learn more about our options for individuals and teams.

In the age of AI too, there's been a lot of talk about how, a lot of the order taking pieces are gonna go away and it's gonna go back into judgment. What do you think our product and engineering teams are gonna look like in the future with AI? What should we be paying attention to?

[00:27:09] Matt Watson: So here's how I think about it. So we've had no code software development for a long time, I dunno, 30 years ago we had Microsoft Access, like basically the same thing, right? And we had Salesforce and Salesforce the same thing. You can customize it and do all this stuff, right? There's a lot of different things that have been no code for a long time.

And then we have, full stack software engineering, very low level, very complicated types of engineering. And the middle, we have low code, right? We have low code, on the no code side, it's all about understanding the business requirements and what needs to be done. You're like building a workflow, customize a screen, does this thing, whatever, like you're really very focused on the higher level product part of it, where software engineering usually is less focused on that.

A lot of times they're given the requirements and they just, they build the stuff, right? Low code is in the middle and has to do both. Like low code is the flex of the two, where it's I've gotta understand the business part of it enough. Because low code you're, it's not usually like huge teams. It's usually like very small teams.

And they've also gotta be technical enough to build out what needs to be done. I think that's where all engineering is going. I think all software engineering is slowly going to this middle ground where it's low code. Now we'll still have like deep engineering stuff that will be very low level and we'll still have that.

But a lot of just regular business enterprise, B2B sort of line of business apps, all that kind of stuff. Are basically becoming more low code. If you ask me if I can vibe code a vast majority of the code and I'm reviewing the code like I'm an engineer, I'm still reviewing the code, I still make sure the code works, it does what it needs to do, it's secure, it's performant, all this stuff.

But I also have to understand the product side of it because to move very quickly and tell the AI what to write, like I have to know what we're trying to do. That's how I at it.

[00:28:52] Melissa Perri: Yeah. And when you're thinking about like the skills are needed for people who like thrive in that low code area, we talked a little bit about understand the business skills. What else do you think people are gonna have to develop there?

[00:29:02] Matt Watson: It's the product thinking, right? It's the higher level of why are we doing this and understanding how to solve the business problems. And, I've talked to some others about this, where, you think back in my career and other people's career, like 20, 25, 30 years ago. Product teams didn't exist.

They were just software engineers. Like when I started my career, it's like you talk to software engineer and tell 'em what you're trying to do and they just figure it out. It's like when we added that layer of product management, they kinda became the gatekeepers, right? It's and the engineers were forced to do more of just the engineering work, which makes sense because software engineering was always the slowest and most expensive part.

But it's like we added all this complexity around engineering to basically take different pieces away from them, like product, project management, QA, DevOps, all the different things. And the engineer, like their scope of what they did got smaller and smaller, but then they just don't understand how it all fits together, right?

They're their role shrunk and shrunk. I think what we're seeing with AI is that's changing it all now. Now the engineers can do more and you got product people writing code. You got, we got people doing all sorts of crazy stuff, blurring all of it, but it ultimately all comes down to the product side. Comes to the product thinking.

[00:30:16] Melissa Perri: When you are an engineer and you're listening to this and you're saying, I do wanna get better at product thinking, and I'm in this organization, I've typically been an order taker. What's the first thing? Or like a good small step that they can take inside their organization to start getting better at product thinking.

[00:30:33] Matt Watson: In the book, one of the pieces of the model is clarity. And I feel like clarity is the fuel of software engineering. So at every step in software development, it's easy to get roadblock to be like, I don't know what to do, 'cause I don't know the answer to this question, like, why it matters to the customer, or is this thing in scope, or how is the customer gonna use this?

Or how are we gonna deploy it to production? Or how are we gonna test it? Like all these different things like clarity. To me is the fuel of a lot of it, right? And I feel like as leaders, our job is to ensure the teams have all of that clarity. And I think of clarity as three things. There's why are we doing this?

It's like the vision, like what is the vision of like why are we doing whatever the thing is? There's scope, what's in scope? What's not in scope? We're doing this, we're not doing this offs. And the third thing gets more of the technical okay, how are we actually doing this? As leaders, I think it's really important that our team members know all these types of clarity, and I think as an engineer theirselves, it's important for them to speak up and make sure they know it like they know, okay, why am I doing this?

Is this in scope? Is it on in scope? I've talked about the architecture. I've talked about how we're gonna test this thing, how we're gonna deploy to production, how do we know if it worked for the customer? I think it comes down to the engineers also caring and asking about those sort of higher level questions because, it's not really about them just checking in their code, right? I think it's redefining the definition of done. Done means we got it to the customer. We know if it mattered or not. Should be the definition to me.

[00:31:56] Melissa Perri: Yeah, that makes a lot of sense there. One of the things I was thinking about too is I have heard this a lot from product managers as well and engineers, right? Where many companies make the product manager that like single throats choke and that they're responsible for the product outcomes. Rather, the developers over here are just responsible for shipping. But like the product outcomes lay on the product managers. When you build these teams, do you have the whole team own those outcomes? Do you change the way that they're measured for success there?

[00:32:25] Matt Watson: I think as leaders, be it an engineering leader, a product leader, CTO, whoever, I think ultimately we're still driving like the higher level strategy and outcomes and goals, right? But if we try and do everything, we're the bottleneck, right? So it's great if I can go to the team and be like, Hey, this is what we're building.

This is what success looks like. This is how we know if we're winning or losing. You guys, go figure it out. You guys help figure out how we know if we're winning or losing and succeeding at whatever we're doing. Otherwise, as a leader, I end up being the bottleneck at all times, right? The team doesn't own any of this.

The product manager is the bottleneck, or I'm the bottleneck. Somebody's the bottleneck. Where can we get the team to take more ownership of Hey, you're supposed to build this feature and we're trying to improve this usage, improve this thing. You've engineer how to do that, and then you go figure out if it actually worked, and then let us know.

[00:33:13] Melissa Perri: And then the team then owns the success

[00:33:15] Matt Watson: Let the team own it.

[00:33:16] Melissa Perri: of that.

[00:33:16] Matt Watson: Yeah. Otherwise, the, as a CTO or any kind of leader, you end up dealing with all the weird crap, right? It's all the weird little things that need to be done because you never empower the team to figure those things out. If you really want to true team that drives ownership, you've gotta even give them all the weird little work.

Otherwise, it all just rolls back to you. You end up doing all the weird little work. Like how do we deploy this thing? How do we test it? How do I get feedback from the customer? Like all this kind of weird little things that come up, right? How do you drive more of that to the team?

But the team has to get outta the mode of thinking my, my only job is to write the code and check in the code. No.

[00:33:54] Melissa Perri: really the

[00:33:55] Matt Watson: where does that work? Go? It rolls back up to leadership, right? And leadership ends up doing all this other weird stuff.

[00:33:59] Melissa Perri: When you're thinking about the future of tech and how product drivenness can help us there, what? What are you excited about? What are you looking for in trends?

[00:34:08] Matt Watson: I think because of AI the engineers are gonna have to more, have more product thinking, right? I don't think there's any denying that. And I have a 16-year-old who wants to become a software engineer and sitting your think is like, what does the world look like for software engineering and my son is the prototypical engineer. He's very introverted. He hates other people. He doesn't like talking to other people. I'm like, I don't know if he can be an engineer anymore. We'll see, that's forever. Like I sit down with him and I tell him like, dude, you are wicked smart. You get all straight A's. You're brilliant. You're emotional intelligence is zero. Like you are terrible at dealing with other people. And one of the things I write about in the book is like the first step of this is having empathy. As a software engineer, it's having empathy for the customer, for the users, for your teammates, for everybody else, right?

And so there are a lot of people like my son that are, they're engineers, they're really brilliant, very smart, highly logical people. But lack the emotional intelligence part of it. And a lot of leaders are that way be, I'll be first admit I was that way when I was younger in my career. And so I think that's the challenge.

Like we've gotta have more of that emotional intelligence, collaboration. It's all these soft skills. It's like we can be really good at the logical, overly logical engineering part of it, and AI is doing more and more of that. But AI is also not probably gonna be very good at this emotional intelligence stuff either.

[00:35:33] Melissa Perri: Definitely not. That is not a strong suit.

[00:35:37] Matt Watson: Yeah

[00:35:38] Melissa Perri: Matt, it's been a pleasure to have you on the podcast. I've got one more question for you. If you could give your younger self one piece of advice, what would you give them?

[00:35:46] Matt Watson: I think it's realizing that everybody else is different than me. I think that was one of the hardest things in my career was, you know, I, smart guy can build a lot of things. I try and take ownership of everything, but realizing like everybody else is different than me. Everybody else thinks differently than me.

And I have to figure out how to leverage their skill sets, which are different than mine. And my goal is to make everybody else more productive. How do I help everybody else be more productive? And that started with me just understanding that they don't all think the way that I do. When I was really young in my career, people used to just frustrate me.

It's like just like my son, probably my 16-year-old, the same way. He just doesn't understand. Other people are different. Other people think different. You just think everybody thinks the same way you do, but they don't at all.

[00:36:27] Melissa Perri: I think that's great advice for people out there listening. Matt, thanks again for being on the podcast. If people wanna pick up Product Driven, where can they do it?

[00:36:34] Matt Watson: Yep. So you can go to productdriven.com, check out the podcast, the book's on Amazon. And it was a bestseller when it launched, which was pretty cool. And I think it's a unique book about bridges, the gap between the engineering and sort of the product and business side of it. It's not a technical book, it's a leadership book, but tries to bridge the gap between the two.

[00:36:52] Melissa Perri: Amazing. And we put all those links at our show notes at productthinkingpodcast.com. Thanks so much for listening to the Product Thinking Podcast. We'll be back next week with another amazing guest, and in the meantime, look out for the Dear Melissa episode that will be launching soon. If you have any questions for me, go to dear melissa.com and let me know what they are.

I'll answer them on an upcoming episode and make sure you like and subscribe this to this podcast so you never miss an episode. We'll see you next time.