> ## Content Index > Fetch the complete content index at: https://productengineers.com/llms.txt > Use this file to discover other available public pages before exploring further. # Why AI Makes Empowered Engineers More Important Than Ever | Marty Cagan (SVPG founder) - URL: https://productengineers.com/episodes/season2/why-ai-makes-empowered-engineers-more-important-than-ever-marty-cagan-svpg-founder/ - Published: 2026-10-20T08:39:59.000Z - Updated: 2026-10-20T08:39:59.000Z - Description: What happens to engineering judgement when AI makes building software faster? Marty Cagan, founder of Silicon Valley Product Group and co-author of EMPOWERED: Ordinary People, Extraordinary Products, explains why engineers need a voice in deciding what to build. - Author: Marty Cagan - Tags: #season-2 What happens to engineering judgement when AI makes building software faster? Marty Cagan, founder of Silicon Valley Product Group and co-author of EMPOWERED: Ordinary People, Extraordinary Products, explains why engineers need a voice in deciding what to build. We explore what separates an empowered product team from a feature factory, and why automating delivery can leave a company shipping unsuccessful ideas faster. Marty describes how engineers can contribute to discovery through customer conversations and prototype reviews, while continuing to build reliable software. We also discuss the difference between empowerment and autonomy, how AI could change team dependencies, and practical steps engineers can take when their organisation still works from a fixed roadmap. --- Listen on [YouTube](https://youtu.be/QA4zYfqeyPQ?ref=productengineers.com), [Spotify](https://open.spotify.com/episode/21TE3M1YmSQm1RbOFThbUE?si=SweCpIdiQTqGseGNU4drmA&ref=productengineers.com) or [Apple Podcasts](https://podcasts.apple.com/us/podcast/why-ai-makes-empowered-engineers-more-important-than/id1836853484?i=1000797222137&ref=productengineers.com) --- ### In our conversation, we discuss: 1. Why engineers can be your strongest source of product innovation 2. Why using AI to speed up a feature factory can deliver failed products faster 3. How engineers can make time for discovery and help shape prototypes before a solution is decided 4. How empowerment differs from autonomy, and why smaller AI-assisted teams could reduce dependencies 5. How to start changing a feature factory from within through customer contact, usage data and small experiments ### Where to find Marty Cagan: - Silicon Valley Product Group: [svpg.com](https://www.svpg.com/?ref=productengineers.com) - Marty's writing and contact details: [Marty Cagan at SVPG](https://www.svpg.com/team/marty-cagan/?ref=productengineers.com) - LinkedIn: [https://www.linkedin.com/in/cagan/](https://www.linkedin.com/in/cagan/?ref=productengineers.com) --- ### Lessons Learned - **Start with a problem and a measure of success.** In the product model Marty describes, a team receives a problem to solve and an outcome to achieve. It then discovers a solution and delivers it. A roadmap of predetermined features removes much of that responsibility. Completing the work tells you that something shipped; it does not tell you whether the customer or business problem was solved. - **Bring engineers in before sprint planning.** Engineers work with the enabling technology every day, which gives them a chance to see possibilities other people miss. Marty argues that a team loses that contribution when engineers first encounter an idea at sprint planning. Include them while approaches are still being explored, so their knowledge can change the solution rather than only its implementation. - **Understand all four product risks.** A solution needs to be valuable, usable, feasible and viable for the business. Marty assigns feasibility to engineers, usability to designers, and value and viability to product managers. Those responsibilities still leave room for everyone to contribute. An engineer may uncover an idea that creates customer value, while needing a colleague's expertise to understand its commercial constraints. - **Ask why a solution deserves to be built.** Engineers should challenge an idea when its purpose is unclear. The idea may be weak, or the product manager may have important context that has not reached the team. Either way, asking helps establish a shared reason for the work. Marty sees this as an essential responsibility of a tech lead: build because the team believes in the solution. - **Use AI gains to improve the outcome.** Faster delivery does not fix a process that chooses the wrong things to build. Marty describes companies accelerating their existing project model and getting failed products faster. His argument is to use AI within a way of working that discovers what will help customers and the business. Assess the result of the work as well as the speed of producing it. - **Give prototypes and production software different goals.** Marty calls discovery building to learn and delivery building to earn. A prototype helps the team assess whether a solution is worth pursuing. A production product also needs reliability, performance and the other qualities required to sell and support it. AI can accelerate both activities, but a convincing prototype still leaves engineering work and product questions to resolve. - **Make discovery part of an engineer's day.** Marty suggests about half an hour for activities such as joining a customer call or exploring the latest prototypes. Most of the day can still go towards production software and managing agents. Regular exposure gives engineers a developing understanding of the problem and the proposed approach, rather than requiring them to reconstruct that context from a specification later. - **Try the prototype and look for a better approach.** Engineers do not have to create every discovery prototype to make a valuable contribution. Playing with it helps them understand the proposal, spot feasibility concerns and suggest alternatives. A technical insight might eliminate a step or derive information the design asks a customer to enter. Those suggestions matter most while the team can still change its approach. - **Keep the solution open when handing over a prototype.** Giving engineers generated code and asking them to make it production ready can repeat the same feature factory pattern. A prototype communicates an idea, but engineers also need the opportunity to question and improve it. If the only remaining decision is how to implement someone else's solution, the team is missing the innovation Marty expects engineers to contribute. - **Learn how your customers differ from you.** Building tools for developers can make it easier for engineers to understand their users. Other domains bring unfamiliar needs and business constraints, including sales, finance and compliance. Marty also warns against assuming customers want to assemble their own AI workflows. Having the tools available does not mean people want to use them; understand the job they actually need to do. - **Separate empowerment from autonomy.** Empowerment gives a team room to find the best solution. Autonomy concerns how far it can deliver that solution without coordinating with other teams. Marty sees the possibility of smaller AI-assisted teams taking on broader scope and reducing dependencies. That is a prediction, and it does not make every dependency undesirable: shared infrastructure and platform teams can still provide useful foundations. - **Show a small experiment from within.** Leaders decide much of an organisation's operating model, but engineers can ask to try a different approach with one team. Start by seeking customer contact, usage data and business context from product colleagues or sales. Turn a promising alternative into a prototype, show it to colleagues and, where possible, learn from a potential customer. Concrete evidence gives the proposed change something people can assess.