Giving Your Users a Well-Lit Path With Matt Watson ![rw-book-cover](https://share.snipd.com/share-image/resize?url=https%3A%2F%2Fimg.transistorcdn.com%2FjWinFBOdCsk_uouTFPIaKFoiPINazJ2uKEubLYthLNg%2Frs%3Afill%3A0%3A0%3A1%2Fw%3A1400%2Fh%3A1400%2Fq%3A60%2Fmb%3A500000%2FaHR0cHM6Ly9pbWct%2FdXBsb2FkLXByb2R1%2FY3Rpb24udHJhbnNp%2Fc3Rvci5mbS9zaG93%2FLzEwNTI5LzE2NTY1%2FMTIwMDAtYXJ0d29y%2Fay5qcGc.jpg&width=512&height=512) šŸ”— **Source:** [Giving Your Users a Well-Lit Path With Matt Watson](https://share.snipd.com/episode/c201560d-a68c-458d-8622-e0ec4a75ef0c) ## Highlights - **Developer Versus Engineer Distinction** - Matt Watson distinguishes software engineers who primarily type code from software developers who solve customer problems. - He credits early consulting-style work for forcing developers to talk to customers and own problem definition. Transcript: Matt Watson Yeah, so I'm currently the CEO of a company called Full Scale, which is a software development for other people. We have about 80 clients that we work for. I have 350 employees that work in the Philippines for all of our clients in software development. But my background is really as a software developer. More as a product guy than anything else that just happens to be a software developer. I've always, you know, I write in my book that I was really lucky. My first job I ever had, I had to go talk to people and figure out what to build. I did not sit in a cubicle somewhere and be told what to do. So I had the different experience than most software developers from the very beginning. And so that's why I guess I have a different perspective because I've spent my whole career talking to people and understanding the problems, which most software engineers, I'll be Honest, don't know how to do. ([TimeĀ 0:01:03](https://share.snipd.com/snip/5e5a7f30-e57b-4563-a87f-00e50b8929ec)) - **AI Forces Engineers To Think Like Product People** - AI makes typing code trivial, so Watson says engineers must elevate into product-minded developers who understand users and architecture. - He stresses remaining roles like security, quality and production remain crucial as coding becomes faster. Transcript: Matt Watson So i think everything you've just described is true but it's a giant spectrum right and it really depends on the company their industry how complicated their software is and all this Kind of stuff right and so i i think the simple answer is i think every software engineer has to become a software right? And the first and foremost, the problem is like when I started my career like 25 years ago, as a software developer, it was much more of a consulting job, right? It's like talk to the customer, understand the problem, figure out how to architect the solution, go build it, make sure it works, give it to them, make sure it works, learn something From it, right? Like that was the whole job. But what happened is we added product managers and project managers and QA and all business analysts, all these other roles. And we slowly stripped all of that away from the developer. So literally all they did was type code. You're just a coder now, right? And now Claude Code does that part of the job. And all of a sudden, everybody's scrambling for it. Whoa, I got to figure out how to do all these other things because I got to elevate myself and provide more value, which I think is the reality, right? Like software engineers have to go from being like a coder to a higher level developer. Now that doesn't discount other things that they do. Like we still need people to understand how to architect software and quality and get things to production and security. Like all of that is still really important and it's becoming more and more of the job, right? Like if the actual typing the code becomes less of the work, all those other things become more of the work, right? But I definitely agree with you that everybody has to think more about the customer and the product, who the user is, having empathy for the user, focusing on, like, why are we building This thing? ([TimeĀ 0:04:07](https://share.snipd.com/snip/f9003d9f-1810-4fc3-9792-c970d9494af2)) - **Give Engineers Ownership Not Orders** - Give engineers ownership so they can solve problems instead of being order-takers. - Matt Watson recommends leaders hire smart people, trust them, and ask how to support their work rather than dictating tasks. Transcript: Matt Watson Well, I think really what it comes down to is the leader of the team. Whoever is the leader of the team, the goal is to build ownership in the team, right? Because for somebody to be much more productive in what they do, they've got to have ownership of what it is that they're doing, right? Because if they're just sitting around waiting for somebody to tell them to do, that's the problem that we're in. The only way to solve that is to build a team. And as a leader, it's your job to help build that in your team, right? To be like, I'm going to give space for Matt to own this thing and figure out how to solve this problem. I'm not going to tell him what to do. I'm going to tell him you're in charge of solving the problem. You're going to be the expert at this problem. Go figure it out. And that's the only way we're going to grow. Right? Because if we just hire a bunch of order takers, and I got to give them perfect requirements, we're not going to grow and bigger companies have figured this out a long time ago, right? You have people like Microsoft and Spotify and everybody else that builds pods or different, you know, groups and figure out how to scale. Where this usually falls apart is in really small companies that never get past having one or two engineering leaders that are the bottleneck, because they're the hero and the bottleneck, And they never figure out how to like grow and scale a team. Bigger companies had to figure some of this out. Now, they have their own challenges, but they had to figure that out. They couldn't have one person making every decision. And the only way you do it is by hiring smart people you can trust, giving them ownership of the problem and figuring it out, and then just asking, how do I support you? ([TimeĀ 0:06:34](https://share.snipd.com/snip/23b93bb3-a4ba-445d-bd45-d102eae0efde)) - **Ship A Well-Lit Path Not Feature Sprawl** - Prioritise a well-lit path: remove irrelevant features so the product feels designed for a specific user. - Watson warns a crowded UI loses trial users who leave within minutes if value isn't immediately visible. Transcript: Matt Watson So I want to give two, I want to give two answers to this. I think the first thing that's important as a user, when I use a product, I naturally like a product more if it feels like the product was designed for me. Right. And inevitably that means removing all the crap that doesn't matter to me. Right. So if I log in your product and I'm trying to solve whatever my is if it's like a well-lit path to solve that problem i'm going to be happy and i'm going to use the product but if it seems like The product was built for somebody else or it has a whole bunch of features a whole bunch of confusion to it i'm just going to quit i'm like i looked at this for three minutes i'm like i don't Really see how to get it to do what i want to do i'm out like that's what the i mean that's what happens when a trial something's up for sign up for trial. I play with it for a minute. And if I immediately see that it solves what I want, I'm probably going to buy it. But if I don't, then I'm just out. You lost that person. They're gone. Right. And so that is the reality of this. Now that's different. If, if you're building software in-house and you like force people to use it, they don't really have a choice. You've got to use this thing all day. Or it's an enterprise product or whatever. It's a different scenario. But if you want user adoption, that's the thing. You want a product that feels like it was made for them and what they want to do. And a lot of times that means simplifying it. You're absolutely right. But I think the other answer to your question is the most valuable skill we have now is judgment, right? It's the judgment to know, should I do this thing or not do this thing? And especially if you can just do all the things, right? Like, I think I wrote in one of my articles, like, the product backlog shouldn't exist anymore, right? If you have a backlog of 100 things, can I just have cloud code all 100 of them today? Worst case scenario, I delete the pull request because I decided I didn't want to do it, right? ([TimeĀ 0:09:27](https://share.snipd.com/snip/b9691602-073c-4f72-a22f-66a65138fc28)) - **Ask What If We Don't Do This** - Ask 'What if we don't do this' to force disciplined choices and avoid unnecessary complexity. - Watson used an internal caching example where skipping caching kept the system simpler with no impact on needs. Transcript: Matt Watson And stick to that vision. Not everybody's going to agree with them. But like, we're really good at what we do because we're really good at this one thing and this one vision. And everybody else keeps trying to, you know, take it off track. Somebody has to have like a critical vision that says no and i think my my feedback and i actually write about this in the book the key question to ask i always feel like is what if we don't Do this that's the question it's not yes or no it's what if we don't do this? Because that helps push it back to the other person and be able to explain why we're actually doing this. Because everything sounds like a great idea and that's the problem, right? Everything sounds like a great idea. And we had this internally just this morning, I was on a call, we're building an MCP server and the team's like, oh, we're gonna add caching around this thing, like a call tool calls, we're Gonna gonna add caching and they're like but now we got to figure out how to invalidate the cache and all this stuff i'm like what if we don't add caching oh that would make it a lot simpler Okay let's just not add caching because there's like this is for internal use like there's no performance or scalability concerns. What if we just don't do the thing? Like, oh yeah, that would make it easier. Okay. ([TimeĀ 0:12:57](https://share.snipd.com/snip/4dedc602-e6d7-44e6-a769-d066f2170790)) - **Your Main Competitor Is Doing Nothing Or DIY AI** - Customers' alternative is often doing nothing or cobbling solutions with AI, so your real competitor is non‑purchase. - Watson notes Claude CoWork and cheap agents let teams assemble Frankenstein solutions cheaply. Transcript: Matt Watson What if we don't make this purchase yeah and that is usually your biggest competitor yep yeah they don't have to buy your product people can survive without it and that's one of the hardest Things about being an entrepreneur is you think you've built like the best product in the world and everybody's going to want your product, but it's like somehow or another, they were Alive yesterday without it. So yeah, they don't have to buy it. Emily O'Meara Absolutely. And I think the key that sometimes some people don't think about is it's not just they don't have to buy your product. They don't have to buy one of your competitors either. Not necessarily. They can just do nothing. Matt Watson And we're increasingly getting to, they could use AI and cobble some crap together that make your product irrelevant. You know, I mean, I've been talking a lot about Claude Cowork and MCP servers and stuff like that over the last month because it has dramatically changed the game. You know, it lets you cobble together some Frankenstein solutions of things with your own custom business logic, even if these other products don't do what you want them to do. I can just kind of cobble it together with some, my own agent now with Claude Cowork for 20 bucks a month. ([TimeĀ 0:14:26](https://share.snipd.com/snip/e2eba885-5088-44f2-8b5e-22b6ac661ade)) - **AI Recommendations Accelerate Winner Take All** - AI recommendations will consolidate tool choices, driving winner-take-all effects for frameworks and tools. - Watson predicts local LLMs and standardised AI-recommended stacks (eg Tailwind) will further entrench winners. Transcript: Matt Watson Well, I think it depends on type of tool that you're talking about. For sure, the other thing is AI is just going to make suggestions, right? You're like, I need to build a prototype of something, and it automatically picks certain JavaScript frameworks or certain CSS frameworks. And I think we're seeing the explosion of some of them, like Tailwind or some of those frameworks, because it's just what AI is recommending to everybody, right? For some of it, right? Some of those tools are just taking off like crazy. But I, so I actually built a developer tool-related company. I had a developer tool-related company. And my feedback is most developers don't spend money on anything. And I have 300 employees that work for me today. And if they all came to me and said, Hey, I need to spend an extra $200 a month or something. I'd be like, I don't have $60,000 a month in the budget for that. Sorry. Where it's already a big enough challenge figuring out, okay, how do we pay for AI related stuff and everything, right? So a lot of developers just don't pay for tools. I mean, it's, that's the reality. Now, AI is forcing that, right? And all of a sudden, it's like, everybody's got to figure out how to spend 100 $200 a month on on that. But honestly, I feel like all that is a very, very short lived thing. I'm not very bullish on Anthropic and OpenAI for this segment of the market because we're all just going to run local LLMs. It's going to happen. Give it five years from now, we will all have 128 gigs of RAM and a good enough video card. We will be running all this stuff locally. Like that is all, it's all going to happen, right? It's already happening slowly. ([TimeĀ 0:19:30](https://share.snipd.com/snip/3b0fa6a7-e55d-42c5-99b5-4bf618f51c8f)) - **Invest In Product People Not More Coders** - Hire more product people because faster code increases the need for judgement and product direction. - Watson warns product managers are scarce and untrained, yet now you need more of them to decide what to build. Transcript: Matt Watson So what, so we have about 350 employees and we do work for 80 different companies, including AMC theaters is one of our customers, the largest movie theater company. And we have more work to do than we've ever had to do. Like we're growing as of today when we're recording this, we have 18 open positions to hire for. We see a lot of demand from our clients. That said, I also understand the market and the labor market is more difficult in some places. Some people are struggling to find a job. So it's all over the board. And as you mentioned earlier, I think we're all trying to figure out, how do we build software now? Do we need more PMs? Do we need more developers? Do we need to change what developers do? I think we need more product managers than ever before, right? Problem is product managers don't exist and there's no training for them. There's, there's no career path for that. Like you don't go to college to be a product manager that's like it's a whole other podcast topic about the problems of that but it's like we need more of more of them than ever before right Because it's like before you could have one developer i mean one product manager for like four or five developers right but all of a sudden if you're can write the code dramatically faster It's like you need more product people. So the whole market is shifting. ([TimeĀ 0:23:34](https://share.snipd.com/snip/22bb623e-3a27-497a-adb2-9c576b1db906)) - **Measure Customer Value Not Commit Velocity** - Output metrics like commits or PR velocity are meaningless unless customers value the change. - Watson emphasises measuring whether customers cared and getting customer feedback is the real hard work. Transcript: Matt Watson That's almost asking, like, does a roofing company make more money if they use more nails? Right? Like, it's not about how many lines of code that we ship. It's about, can we deliver value to the customer? Emily O'Meara I totally agree with you. But I feel like this is a point that gets lost, or that has gotten lost recently. But maybe, I don't know if you think that that's true. Matt Watson Like how many commits did we do? How many pull requests? How fast did we approve them? How fast did we ship to production, right? People are so focused on those sort of output measures because they're easy to see and understand and control, right? Where it's really difficult to be like, okay, yeah, we shipped that thing last night, but I haven't talked to the customer yet. I don't know if they liked it. I don't know what their feedback was. I don't know if I can even get them on the phone. I don't know when I'm going to get that feedback. So I don't know what to do next. So instead, I'm just going to go build something else. Right? Like getting that feedback is difficult and hard. But that's really the job. The job is to like, make sure our customers cared about what we built and did it provide value to them? Not like how many commits did we do? ([TimeĀ 0:27:19](https://share.snipd.com/snip/6b56bd95-c364-47b3-b93f-d157e2954a75)) - **Be The Best Known Not The Best** - Aim to be best known for a clear capability rather than trying to be objectively the best at everything. - Watson advises investing in visibility and marketing so customers actually know what you do. Transcript: Matt Watson One of my favorite pieces of advice is the goal in life is never to be the best at what you do. And this goes in line with just what we were just talking about is to be the best known for what you do. That's, that's my, you know, we can build the best software, but if nobody knows that we built the software at all, it doesn't really matter. Right. And so that's my best, my best advice. ([TimeĀ 0:33:42](https://share.snipd.com/snip/e0639b76-f15f-445a-8a38-852f5b188833))