The Product Experience · Mind the Product

How to build a product-driven engineering team - Matt Watson (Founder, Full Scale)

December 17, 2025·41 min·3 clips

Matt Watson reveals why shipping code without feedback should be terrifying, not a goal.

1. The Product Experience hosts Randy Silver and Lily Smith interview Matt Watson, founder of Full Scale and author of 'Product Driven,' on how to build engineering teams that think like product people. 2. Matt Watson describes himself as a 25-year software engineer who identifies more as a product and business person than an engineer; he has founded four tech companies and currently runs Full Scale, which provides engineering services to 80 clients with 250-plus engineers based in the Philippines. 3. The episode's thesis is that most software engineers have been culturally trained to think only about code—not customers—and that reversing this requires deliberate leadership and a new definition of 'done.' 4. Watson traces the origin of the problem to the period between 2005 and 2010, when the growth of Agile, product managers, product owners, business analysts, and DevOps teams progressively insulated engineers from customers and told them to keep their heads down. 5. He cites the opening chapter of his book: early in his career, shipping code with no feedback was considered success—but he now argues this should be terrifying, because silence means nobody cared about what was built. 6. He tells the story of a 20-year architect who, after reading the book, messaged him at 11pm to say it had never occurred to him that he should care about the customer when writing code—a reaction Watson found both hilarious and illustrative of how common the disconnect is. 7. Watson argues that product managers are not going away, but they need to expose as much customer context as possible to engineers—rather than writing requirements so detailed that AI could just execute them—so engineers feel connected to the product vision. 8. His definition of 'start' and 'done': start means engineers understand the requirements from the very beginning; done means they care what happens after their code is deployed and verify it in a real user's account. 9. He argues that organizational friction—not lack of skill—is the primary reason engineers get stuck: they cannot make trade-off decisions alone because they lack clarity, so they wait for standups, for product managers, for approvals. 10. Watson presents his five-component product-driven model: vision (tactical clarity on why this specific thing matters today), focus (explicit trade-offs: we chose this over that because), clarity (daily context to prevent getting stuck), shared ownership (distributed accountability, never one person), and courage (psychological safety to ask questions and push back). 11. He explains that courage was the founding insight: engineers at Full Scale who were struggling most needed the confidence to ask why, suggest alternatives, and refuse the 'code monkey' role. 12. Lily Smith describes finding an engineer who had printed a 'coding monkey' picture and put it on his desk, saying the product team never listened to him—Watson uses this as a direct example of what happens when courage and psychological safety are absent. 13. On keeping teams externally focused, Watson argues that without deliberate effort teams turn inward, optimizing for technical debt and rewrites they find interesting rather than customer outcomes; he gives the example of engineers wanting to rewrite everything in Rust after reading Hacker News. 14. He says even necessary maintenance work—Python version upgrades, cloud migrations—must be tied back to customer value to avoid becoming pet projects that compete with meaningful work. 15. On 10X developers, Watson redefines the concept: not innate genius, but a good engineer with zero organizational friction, full ownership, and enough clarity to make trade-off decisions without asking anyone—startup founders being the canonical example. 16. He argues that AI tools like Claude Code are amplifying this dynamic: people who can provide clear product direction to AI can now move at what was previously considered 10X speed, making clarity and ownership more valuable than raw coding skill. 17. Watson recommends that product managers record short Loom videos—three minutes—to give engineers context on why a feature matters, arguing this prevents weeks of misdirected work and is a trivial time investment. 18. The conversation is informal and practical, with both hosts contributing from their own product and engineering experience, and some friendly disagreement on the nature of 10X developers. 19. Engineering leaders, CTOs, and product managers who want to understand why their engineers feel like code monkeys and what structural changes could unlock better work will get the most from this episode. 20. Listeners looking for specific Agile ceremony recommendations, sprint planning frameworks, or tooling comparisons will not find those here.

As heard by us

Engineering works better when it starts with product context, not just code.

Matt makes a steady case that engineering teams do better when product context is treated as necessary, not optional. He keeps coming back to a simple point: strong developers ask questions, think past the code, and understand why the work matters.

Read the full review in PlayNext →

Why you'd press play

You want engineers who think about the customer, not just the code.

Read the full recommendation in PlayNext →

Listen to the show on

Apple Podcasts Spotify

Play clips from this episode More from The Product Experience