The Product Porch
Why do so many teams still misunderstand what product management is actually for? In this episode, Joe, Ryan, and Todd take on a question that keeps showing up in the age of AI: if engineering can build faster than ever, do we still need product managers? The answer is yes, but probably not for the reasons a lot of people think. They dig into why product so often gets treated like project management, ticket writing, or an expensive wrapper around engineering, and why that misses the point. This conversation is really about the value of product management. Not speed. Not ceremonies. Not pushing features through the system. Real product work is figuring out what is worth solving, asking better questions, and connecting customer value to business outcomes. If you’ve ever had to explain your role, push back on feature factory thinking, or help your company see product more clearly, pull up a chair on the porch, challenge a bad assumption, sharpen how you talk about your work, and listen in. **Welcome to the Porch** [00:00] Build vs outcomes - Todd jokes that building 100 products is easier than hitting a revenue target [00:29] Core question - Joe frames the episode around why companies still need product managers **Why This Question Is Back** [01:28] AI speeds delivery - The team explains why faster engineering makes leaders question product’s role [02:13] Building is not the hard part - Todd argues the real challenge is choosing the right problems [02:42] Misunderstood function - Product is often framed as project management or message carrying **What Product Gets Mistaken For** [03:28] “The fixer” story - Ryan shares a customer meeting that exposed a bad read on product’s purpose [04:36] Giant waste of money - Todd says if product only relays requests, the function should not exist [06:04] Wrong metrics - Measuring product by speed and output sets up the wrong expectations **AI, Claude Code, and the Feature Factory Trap** [07:08] Prototype to production gap shrinks - Joe explains how AI makes execution feel much closer [08:21] Decoupling headcount from growth - Ryan shares how leaders are pushing for more output with fewer people [09:48] Building gets easier - Todd says coding is now the easiest part of the job [10:19] Build trap warning - More product can be built than ever, but that does not create value by itself **Game Segment: What Product Is Not** [12:16] On-time delivery confusion - Getting projects done on time should not define the PM role [13:12] Managing engineers - Product works with engineers, but engineering managers lead engineers [13:36] Business case inputs - PMs help shape the case, but the case itself should be built with the team [14:56] Sales requests are not strategy - Product is not there to blindly build what sales asks for [16:38] Ask why - Real product work starts when PMs move past order taking and investigate the problem [18:23] Budget tradeoffs - PMs need to understand budgets without owning project control [18:38] Quality role - Product has a role in acceptance and validation, but not sole ownership of QA [19:16] Escalation trap - Ryan pushes back on product being treated like the default complaint handler [20:12] Execution wrapper - Joe sums up the anti-pattern as an expensive wrapper around engineering **The Hammer Analogy** [21:40] Wrong tool, wrong job - Todd compares product to a hammer being misused to cut branches [22:37] Ticket writers at risk - Joe connects the analogy to AI and the feature factory model [23:08] What survives - PMs who decide what is worth solving stay valuable **What Product Is Actually For** [23:15] Customer value to business outcomes - Todd defines the real job of product in one line [23:57] Blast radius of every bet - Every product decision affects sales, marketing, support, and success [24:45] Find the right yes - Great PMs work through the no’s to place better bets and align the company **How to Change Perception** [26:04] Take the harder path - Todd says PMs have to choose real product work over easy order taking [26:50] Hold yourself to outcomes - Measure value even when leadership only asks for features and velocity [27:46] Know your audience - Ryan says product has to show stakeholders it cares about what they care about [28:35] Start where the company is - Todd explains why product change has to happen in increments [29:47] Solve a shared business problem - Ryan argues this is how product earns credibility across functions **Change Management and the Product Blueprint** [32:41] Show, do not declare - Joe frames this as change management, not just a process announcement [33:15] Execution friction vs thinking friction - AI speeds shipping, but not judgment or strategy [33:52] Product blueprint - Todd describes mapping the full product job so leaders see how small development really is [34:29] Business skills matter - Ryan argues it is easier to teach PMs AI than to teach engineers deep business context **Homework and Closing Takeaways** [35:13] Keep it simple - Ryan says product is still misunderstood, so PMs need to explain their value clearly [35:51] Leadership homework - Joe tells listeners to ask leadership what they think product owns [36:18] Product reconciliation - Todd says PMs need to understand themselves before others will understand them [38:41] Optimistic ending - The best parts of product work are the parts most likely to last Help keep the Product Porch lights on by giving at https://www.patreon.com/TheProductPorch Join our email list and never miss an episode at theproductporch.com [https://www.theproductporch.com/email-signup]
55 episodios
Comentarios
0Sé la primera persona en comentar
¡Regístrate ahora y únete a la comunidad de The Product Porch!