02:38
product management
Product management, design, and engineering should work together as one unit rather than in sequential handoffs, because the risks of value, usability, and feasibility have to be resolved simultaneously, not one after another.
Traditional org structures work in handoffs: a CEO tells a director who tells the product manager who tells the designer who tells the engineer what to build — a cascading, waterfall-style sequence.
Collaborative teams instead work together: product teams tackle risk around value, design teams ensure people can use it, and engineering teams ensure it can be built, walking as one unit.
Together these teams identify and define problems, then discover, design, validate, test, and deliver the solution as one process.
Big companies with more hierarchy, layers, levels, committees, governance, and top-down approvals reinforce sequential, handoff-based work.
There is risk involved in everything: you can find the best idea that customers love but can't build, or build great technology that nobody wants — these risks must be addressed together, not separately.
Teams should stay together and stay close, 'rubbing ideas together,' to find something that can be built, that people will buy, that people will use, and that generates revenue, all at the same time.
Handoffs/sequence are often why most roadmaps are challenging, because value is assumed rather than tested in a roadmap.
Example: an executive says to build integration with Stripe, and because the executive is the boss it's assumed to be a good idea, so it gets built without testing for value — resulting in no signups.
The best product work comes from the constant grind and iteration of teams exchanging ideas, validating, and testing things together.
The critique of roadmaps is structural: value gets assumed rather than tested specifically because organizational hierarchy grants authority (the executive's rank) as a substitute for validation, so the Stripe example isn't really about a bad idea but about a broken decision process.
The risk framing splits ownership by discipline — product owns value risk, design owns usability risk, engineering owns feasibility risk — but the argument is that none of these can be resolved in isolation from the others, since solving one without the others still produces failure (buildable-but-unwanted, or loved-but-unbuildable).
Committees, governance, and approval layers are named as mechanisms that actively reinforce sequential handoff work, framing the problem as embedded in company structure rather than just individual team habits.
«it's kind of calling out that they don't work in handoffs»
— 00:00
«the product teams who are tackling the risk around value the design teams who are ensuring people can use it and the engineering teams who are ensure that we can build it walk as one unit to kind of identify and Define the problems they want to solve to discover design validate test and deliver that solution together»
— 00:32
«there's risk involved in everything we do you don't want to say we found the best idea all the customers love it but we can build it you know oh we know the best thing we can build we have this great technology but nobody wants it»
— 01:14
«it's often why uh most roadmaps are challenging because value is assumed in a roadmap»
— 01:57
«some executive told you to build integrate with stripe like it must be a good idea the executive is the boss you know and so you don't test test for Value you just go ahead and build it and then you're like why are we not getting any sign ups nobody using stripe»
— 02:03
«the best product work comes from that constant grind and iteration of teams exchanging ideas validating and testing things together»
— 02:26
Reception
No comments are available, so audience reception cannot be determined.
A tight, practitioner-oriented statement of a common product philosophy — collaborative, risk-based teamwork over waterfall handoffs — grounded in a relatable roadmap anecdote, but at under three minutes it stays at the level of a stance rather than a step-by-step method.
02:38