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

Summary

---

Product Thinking Podcast – Episode 245

Building Product Thinking in Engineering Teams with Matt Watson

Host: Melissa Perri
Guest: Matt Watson, Founder & CEO of Fullscale, author of Product Driven
Date: September 17, 2025

---

Overview

In this episode, Melissa Perri sits down with Matt Watson to explore how fostering product thinking in engineering teams leads to real ownership, creativity, and business impact. Drawing from Matt’s experience as a founder, CTO, and executive leader of a nine-figure exit company, the conversation delves into the dangers of an “order taker” culture, balancing roles between product and engineering, and practical ways to cultivate autonomy, courage, and cross-functional vision. Matt shares key insights from his new book, Product Driven, offering an actionable model for leaders aiming to unlock their teams’ full potential.

---

Key Discussion Points & Insights

1. The "Product Driven" Model: Moving Beyond Order Taking

Timestamp: [00:00], [04:53], [14:16]

• Vision First:

  • True product thinking for engineers starts with vision—not a generic mission statement, but a clear answer to “why are we doing this?”
  • “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.” —Matt Watson [00:29]

• Order Takers vs. Product Owners:

  • The highest-impact engineers are engaged, curious collaborators—not just executors of specs.
  • Teams become “order takers” when they lack context, clarity, and psychological safety.
  • “You've got to build a team culture that incentivizes it, rewards it and allows it. Otherwise you're just getting a bunch of order takers.” —Matt Watson [01:22]

---

2. Engineers Practicing Product Thinking

Timestamp: [04:53], [06:17], [09:30], [10:38]

• Defining Product Thinking:

  • Distinguished as outward (customer/product/business) vs. inward (just code, tools) focus.
  • “Nobody cares about your code. They care about what your code does… They care about the higher level purpose of this.” —Matt Watson [05:11]

• Engineers & Product Managers: Different Lenses, Shared Context

  • Product sets strategic direction; engineers need clarity on tactical vision.
  • “We all need access to the same information, but some of it's just through different lenses… The engineering team may also know way more than the product team does.” —Matt Watson [06:22]
  • Balancing technical debt and new features is a joint effort.

• Too Much "How", Not Enough "Why"

  • Over-specifying “how” turns engineers into cogs, undercuts motivation and innovation.
  • “As a product team, 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.” —Matt Watson [10:46]

---

3. Team Culture: Psychological Safety, Ownership & Courage

Timestamp: [12:41], [14:16], [18:21], [19:32]

• Courage and Psychological Safety

  • Speaking up, challenging assumptions, and advocating for customer needs requires psychological safety and leadership support.
  • “It takes courage to speak up and ask questions, to push back. But that starts with team culture… Do I give people space to speak up and say those things?” —Matt Watson [18:32]

• Leadership’s Role

  • Culture—more than process—enables creativity and innovation.
  • “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.” —Matt Watson [14:19]
  • Order-taker cultures stifle product innovation.

• Encouraging Ownership

  • Empowering teams to weigh in on scope, outcomes, and tradeoffs improves engagement and real outcomes.
  • “As a leader, I end up being the bottleneck at all times… Where can we get the team to take more ownership…” —Matt Watson [32:54]

---

4. Tactics: Clarity, One-on-Ones, and Effective Standups

Timestamp: [16:05], [21:37], [23:27], [30:33]

• Product Vision & Clarity

  • Clarity around "why", "what", and "how" is fuel for high-performing software teams.
  • “Clarity is a fuel of software engineering… As an engineer themselves, it's important for them to speak up and make sure they know it…” —Matt Watson [30:33]

• Daily Meetings & One-on-Ones

  • Effective status meetings aren’t for mere status—they’re a venue for surfacing uncertainty, clarifying purpose, and removing blockers.
  • “I think one of the biggest mistakes software engineering leaders make is how they use daily status meetings…They’re missing a really critical opportunity to drive clarity.” —Matt Watson [16:05]
  • One-on-ones foster relationships, enable candid feedback, and empower direct conversations.
  • “Building real relationships with people…as leaders, we have to make sure we build that relationship with people.” —Matt Watson [21:37]
  • Coachable moments—referencing retros or meetings—are opportunities for growth.

---

5. Adapting to the Age of AI & Changing Skills

Timestamp: [27:09], [29:02], [34:08], [35:02]

• The Shift to Low-Code and Product Collaboration

  • Routine “order taking” will be automated. Product-thinking skills will be at a premium.
  • “As AI is changing things, we're going to have to have more and more people that have higher level product thinking…AI is coming for your job.” —Matt Watson [12:56]

• Engineers Need Empathy & Soft Skills

  • Emotional intelligence, collaboration, and customer empathy are critical.
  • “The first step of this is having empathy. As a software engineer, it's having empathy for the customer, the users, your teammates…” —Matt Watson [34:56]

---

Notable Quotes & Memorable Moments

• On the Importance of Courage in Teams
  • “It takes courage to speak up and ask questions, to push back, right?...That starts with sort of team culture.” —Matt Watson [00:53], [18:32]
• On Culture and Ownership
  • “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.” —Matt Watson [14:20]
• On Product Managers as Gatekeepers
  • “A lot of times companies hire these product managers…The product managers don't really know anything...Or maybe the engineers even know way more.” —Matt Watson [07:05]
• On the Evolution of Engineering Work with AI
  • “I think all software engineering is slowly going to this middle ground where it's low code. Now we will still have like deep engineering stuff…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.” —Matt Watson [27:34]
• On Defining Success and Ownership
  • “Definition of done means we got it to the customer. We know if it mattered or not should be the definition to me.” —Matt Watson [31:49]

---

Practical Takeaways for Leaders & Teams

• Foster a culture where questions, challenges, and ideas are welcome and rewarded
• Prioritize clarity—share “why” and “what”, not just “how”
• Use one-on-ones and status meetings for real communication and coaching, not just status
• Encourage engineers to take ownership of not just code, but customer outcomes
• Prepare for AI and low-code shifts by developing product thinking, empathy, and business understanding in technical teams

---

Timestamps for Key Segments

• [00:00–01:22] — Vision, Culture, and Courage in Teams
• [02:45–04:40] — Matt’s Background & Motivation for Product Driven
• [04:53–07:57] — Defining Product Thinking for Engineers and PMs
• [09:30–11:54] — Tradeoffs in Engineering; Overcoming Over-Specification
• [12:41–14:16] — Order Taker Mindset & Leadership’s Role
• [16:05–18:12] — Effective Meetings and Leadership Behaviors
• [19:32–23:27] — Building Ownership, Courage, and Relationships via One-on-Ones
• [27:09–30:16] — AI, Low-Code, and Future Product/Engineering Skills
• [30:33–33:57] — Clarity, Outcome Ownership, and Metrics for Success
• [34:08–36:33] — Emotional Intelligence, Empathy, and Career Advice

---

For more from Matt Watson, check out his book Product Driven at productdriven.com, and for ongoing product management insights, visit Product Thinking Podcast.

Transcript

[Matt Watson]

We need product managers and higher level executives to help drive strategy, 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 going to jump in and start doing all that kind of stuff. But the engineers need to understand at a lower level, 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. And I don't mean hr, slogan, vision, statement, whatever. I mean the vision of like, why are we doing this thing, 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 done. 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, you know, meltdown because 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 a fundamental thing of all. This is like the team members have to have courage to speak up and you've got to build a team culture that incentivizes it, rewards it and allows it. Or otherwise you're just getting a bunch of order takers.

[Melissa Perry]

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 think like a great product leader. This is the Product Thinking Podcast. Here's your host, Melissa Perry.

Hello and welcome to another episode of the Product Thinking Podcast. Today I'm excited to introduce Matt Watson, the founder and CEO of Fullscale 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.

[Matt Watson]

Well, that's just the way I started my career. It's like, go talk to me and figure out what they need done, go build it. That's how it started. Right.

[Melissa Perry]

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?

[Matt Watson]

So the 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 going to sell you? Trying to figure that out. I ended up rewriting a Visual Basic 6 like Microsoft Access Database for this guy. And this was like 25 years ago, but that was my first experience in software development. I literally went to a car dealership, sat down next to the guy and it's like, this is the report I need, I need to do this thing. It was very much product thinking from the beginning. That's how I started my career. And 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.

[Melissa Perry]

That's really inspiring because 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?

[Matt Watson]

Yeah. So today I have over 250 engineers that work for me, over 70 clients we do work for. And really consistently we hear from our clients that, that the engineers that they love are the ones that ask all the questions. They valid 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. You 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. And about a year ago, summer 2024, I went and did a, a keynote speech at a dev conference officially And I decided to do it on this topic, about how software engineers need to think outside the code. They need to think more about product and 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.

[Melissa Perry]

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, to do product thinking?

[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 we love tools, 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, like focusing inwards versus outwards. If you're not focusing outwards on the customer, you're focusing inwards, which is just business, 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. And as a leadership, we've got to 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.

[Melissa Perry]

In 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 a little 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?

[Matt Watson]

I think we all need access to the same information, but some of it's just through different lenses, right? Like 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 going to jump in and start doing all that kind of stuff. But the engineers need to 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. And 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 voice and everybody's vote. But we're going to have to make the decisions.

[Melissa Perry]

Your dev team is shipping faster than ever, but your tools, they are still stuck in 2012. Monday.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 built in. 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 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 a picture of the trade offs where we're going.

[Matt Watson]

Yep, why did, why are we doing this and not that.

[Melissa Perry]

Yeah, exactly, the trade offs, but also what is this going to be at the end of the day? Rather than build this but and 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?

[Matt Watson]

Well, I think software engineering is so much about the trade offs, right? It's are we going fast? Are we making something that's like military grade, bulletproof, like we're shipping this code to Mars, right. And everywhere in between it's, 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 going to be used. So that may force us to over engineer things because we don't really understand do we need this fast? Is this going to 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 it's engineering team, if I don't understand like why and what the purpose of this thing is, a lot of times they're going to over engineer things and I think that's one of the challenges.

[Melissa Perry]

So when a product manager is working with the engineers, 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?

[Matt Watson]

As I mentioned earlier, I think it's that sort of tactical product Vision, just making sure they understand 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 spoon fed way too many of the detail and don't have time to think. They're not part of it. They don't understand the big picture. I think as a product team, 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, you know, 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 for 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 out of 10 they're going to say what you want to do anyways. But now they're more motivated to do this because they felt like they actually had a voice and an opinion.

[Melissa Perry]

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 give me the spec, right? I just want the spec. 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 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 want to sit here and code. I don't want to 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?

[Matt Watson]

I think there's different developers that are all over the Spectrum of this, right? Like we're always going to have some software engineers think that way and a team of 10 engineers, maybe a couple of them 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 and 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, right? And you can have a couple of them on a 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, as AI is changing things, we're going to have to have more and more people that have higher level product thinking. Because for these engineers that just want to be straight order takers, that's what AI. AI is coming for your job. If I've got to write requirements that are so detailed and so specked out, why don't I just ask AI to write the code and somebody else just review the pull request?

[Melissa Perry]

At this point 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 speaker. 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 teams, 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 them the space to do that? Like what does that look like?

[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 and courage. And we could talk through all five of those if you want. But I think it, it 100% 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 a lot of times engineers are so far down the stream that for them to challenge the requirements or something feels like the train is already moving.

[Interviewer/Host or Podcast Participant]

Right?

[Matt Watson]

Like they are 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. 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. And I just hired a CTO for one of our venture companies and she was very successful at a bank and all this stuff. And. But 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 want to build something, not just be told what to do all the time and engineer this bank stuff. Like, I want to go create something. I want to be innovative. And we stifle a lot of that in these big companies. And really what we're stifling is innovation and creativity.

[Melissa Perry]

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 are the actions or the behaviors of leaders that you've observed that do stifle that creativity?

[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 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 a great example of this is some people really like to work Async and they don't even want these meetings. But I want to 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 my understands 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 got to make sure we don't spam this API. We don't get blocked. This customer has this big issue. It's all clarity. It's understanding the why and the big picture. But instead, most companies, I don't know. Here's a requirement. Follow the requirement.

[Interviewer/Host or Podcast Participant]

Where are we?

[Matt Watson]

Out on Jira, ticket J3.35. This is pointless calls.

[Melissa Perry]

Yeah. 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.

[Matt Watson]

No.

[Melissa Perry]

And then I'd be like, what's the point? Oh, if you need help, like, this is a protected standup. It's only 15 minutes. So you go talk about help later. We don't talk about it together, even though it might affect a bunch of people, which I always thought was really weird.

[Matt Watson]

Yeah. And that's. So a lot of engineering leaders 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 with my engineer and I can sense from my history and my background, 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 where I can, like, really listen in and ask those probing questions instead of just being totally passive to the meeting and totally checking out the meeting? Nobody's paying any attention to anything.

[Interviewer/Host or Podcast Participant]

Right.

[Matt Watson]

Everybody's just reading all this I did today, and nobody cares.

[Melissa Perry]

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?

[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.

[Interviewer/Host or Podcast Participant]

Right.

[Matt Watson]

That takes courage. Takes a lot of courage.

[Interviewer/Host or Podcast Participant]

Right.

[Matt Watson]

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.

[Interviewer/Host or Podcast Participant]

Right.

[Matt Watson]

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, you know, melt down because we don't fix these things. It takes courage to say those things.

[Interviewer/Host or Podcast Participant]

Right.

[Matt Watson]

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 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 a fundamental thing of all this is like, the team members have to have courage to speak up, and you've got to build the team culture that incentivizes it, rewards it and allows it, or otherwise you're just getting a bunch of order takers.

[Melissa Perry]

I see that a lot with product managers, too, when they get into the order taker mode. Right. It's a, oh, my boss told me that we're going to go build this feature and give me all this specs and stuff, and then I'm just going to pass it to the engineers and so many of them.

[Matt Watson]

That's the easier thing to do.

[Melissa Perry]

Yeah, 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, like, 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're right, though, there's. There is this lack of pushback sometimes where everybody thinks it's scary to go question things.

[Matt Watson]

And that starts from a leadership perspective.

[Interviewer/Host or Podcast Participant]

Right.

[Matt Watson]

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. Like, you're supposed to pester me every day. And that's okay. That is literally your job. Yeah, 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 are treat these things differently. Some people are very direct, some people are very indirect. Some people come in from 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. 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.

[Melissa Perry]

Like, yeah, 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.

[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 going to 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.

[Melissa Perry]

Yeah, I see a lot of leaders that want to just skip their one on ones because I think it's not important.

[Matt Watson]

That was me.

[Melissa Perry]

Oh, that person's on track. It's fine. Let them just keep going.

[Matt Watson]

That was me. I always hated one on ones. Hated doing it.

[Melissa Perry]

What made you go, I need to change this?

[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 the 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. I'll figure it all out. And if I can't figure it all out, I'm just the failure or whatever. Where eventually I get to the point where I can't do all this stuff. I've got to have a team, I got to grow, I got to scale. And this is how you do it. It's through 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. 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.

[Melissa Perry]

I feel like 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?

[Matt Watson]

So currently I do them with three or four different people and usually, you know, 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 a status meeting this week or the retro meeting or whatever and it's ah, when I talk to them again next week, I want to go back to that moment and coach them on, hey, they could have done this differently. And 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 them 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.

[Interviewer/Host or Podcast Participant]

Right.

[Matt Watson]

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.

[Melissa Perry]

Yeah. And that's good. It keeps people apprised too of what you're thinking about, what you care about as well.

[Matt Watson]

And I think that's one of the, I think I mentioned that in the book too. It's. There's a leader. One of the most important things that we need to do is keep telling everybody why we think the way that we think.

[Interviewer/Host or Podcast Participant]

Right.

[Matt Watson]

Because they're never going to have the ownership or create that product thinking and higher level thinking if they don't think the same way. So they're just, otherwise they're Just kind of order takers. 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.

[Melissa Perry]

I've definitely been there, too. And you have to remember, like, it's. They don't have the same context that you do.

[Matt Watson]

No. So we have to keep telling them. Yep.

[Melissa Perry]

When you're 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're 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 them to be more product driven. I really want to 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?

[Matt Watson]

I think you got to identify the team members in 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.

[Interviewer/Host or Podcast Participant]

Right.

[Matt Watson]

You got to start with embracing those people. And when you have meetings, ask them questions, get them to speak up.

[Interviewer/Host or Podcast Participant]

Right.

[Matt Watson]

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 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 want to hear you guys. How. How should we do this? I want to hear you think. I want to hear why you think this way. Because that's the only way you're going to get them to coach. Coach them through it and get them thinking. Switching modes from being order taker to be like, oh, now I got to show up to these meetings, actually think about what we should do.

[Interviewer/Host or Podcast Participant]

Right.

[Matt Watson]

Like, they're never going to do it.

[Melissa Perry]

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 going to go away and it's going to go back into judgment. What do you think our product and engineering teams are going to look like in the future with AI? What should we be paying attention to?

[Matt Watson]

So here's how I think about it. So we've had no code software development for a long time. I don't know, 30 years ago we had Microsoft Access, like basically the same thing, right? Yeah. And we had Salesforce and Salesforce the same thing. You can customize it and do all this stuff.

[Interviewer/Host or Podcast Participant]

Right.

[Matt Watson]

There's a lot of different things. Have been no code for a long time. And then we have full stack software engineering, very low level, very complicated types of engineering. In the middle we have low code.

[Interviewer/Host or Podcast Participant]

Right.

[Matt Watson]

We have low code on the no code side. It's all about understanding the business requirements and what needs to be done. Building a workflow, customize the screen, does this thing, whatever. 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 got to understand the business part of it enough. But because low code, it's not usually like huge teams, it's usually like very small teams. And they've also got to 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 will 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, 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 look at it.

[Melissa Perry]

Yeah. And when you're thinking about like the skills that 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 going to have to develop there?

[Matt Watson]

It's the product thinking.

[Interviewer/Host or Podcast Participant]

Right.

[Matt Watson]

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, like you talk to the software engineer and tell them what you're trying to do and they just figure it out. It's like when we added that layer of product management, they kind of became the gatekeepers.

[Interviewer/Host or Podcast Participant]

Right.

[Matt Watson]

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.

[Interviewer/Host or Podcast Participant]

Right.

[Matt Watson]

Their role, trunk and trunk. I think what we're seeing with AI is that's changing at all now the engineers can do more. And you got product people writing code, you 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.

[Melissa Perry]

When you are an engineer and you're listening to this and you're saying, I do want to 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?

[Matt Watson]

In the book, one of the pieces of the model is clarity. And I feel like clarity is a fuel of software engineering. So at every step in software development, it's easy to get roadblocked, to be like, I don't know what to do because I don't know the answer to this question, like why it matters the customer or is this thing in scope, or how is the customer going to use this? Or how are we going to deploy it to production? Or how are we going to test it? Like all these different things, like cloud clarity, to me is the fuel of a lot of it. Right. And I feel like as leaders, our job is to ensure that 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 trade 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 themselves, 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 not in scope? I've talked about the architecture, I've talked about how we're going to test this thing, how we're going to 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.

[Interviewer/Host or Podcast Participant]

Right.

[Matt Watson]

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.

[Melissa Perry]

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 throat choke and that they're responsible for the product outcomes, rather the developers over here are just responsible for shipping. But 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?

[Matt Watson]

I think as leaders, be it an engineering leader, product leader, cto, whoever, I think ultimately we're still driving 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.

[Interviewer/Host or Podcast Participant]

Right.

[Matt Watson]

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 engineer how to do that and then you go figure out if it actually worked and then let us know.

[Melissa Perry]

And then the team then owns that. Yeah, yeah.

[Matt Watson]

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 a true team that drives ownership, you've got to 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 out of the mode of thinking. My, my only job is to write the code and check in the code.

[Melissa Perry]

No, it's about really, then where does that work go?

[Matt Watson]

It rolls back up to leadership.

[Interviewer/Host or Podcast Participant]

Right?

[Matt Watson]

And leadership ends up doing all this other weird stuff.

[Melissa Perry]

When you're thinking about the future of tech and how product drivenness can help us there, what are you excited about? What are you looking for in trends?

[Matt Watson]

I think because of AI, the engineers are going to have to have more product thinking. 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 here thinking, it's 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. Your 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.

[Interviewer/Host or Podcast Participant]

Right.

[Matt Watson]

And so there are a lot of people like my son that are 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. 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 got to 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 going to be very good at this emotional intelligence stuff either.

[Melissa Perry]

Definitely not. That is not a strong suit.

[Matt Watson]

Yeah.

[Melissa Perry]

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?

[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, I 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.

[Melissa Perry]

I think that's great advice for people out there listening. Matt, thanks again for being on the podcast. If people want to pick up Product Driven, where can they do it?

[Matt Watson]

Yep. So you can go to productdriven.com check out the podcast, the books 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.

[Melissa Perry]

Amazing. And we put all those links at our show [e-mail] 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 dearMelissa.com and let me know what they are. I'll answer them on an upcoming episode. And and make sure you like and subscribe to this podcast so you never miss an episode. We'll see you next time.