The Root Causes of Product Failure by Marty Cagan at Mind the Product San Francisco

[@kimbfwhite]

1:22 There's a tremendous difference between how most companies work and how the best companies work 2:59 I wanna try to describe what I will bet money the vast majority in this room are actually doing and the 10 biggest reasons why that way of working is fundamentally flawed 5:35 Point 1: Everything starts with ideas 6:00 Two main sources of ideas: execs (internal leaders) and customers 10:11 So this is what I see in the vast majority of companies (ideas>biz case>roadmap>requirements(user stories)>design>build(agile comes in here)>test>deploy). Basically waterfall. 11:20 Why is this so bad. 10 key points 11:40 Reason 1: Source of ideas. Consistently the best source of your ideas: The engineers. 12:19 Best source of ideas... Your engineers! 13:18 Another source of ideas. Data. Customers don't know the data 14:30 Reason 2: The fallacy of business cases. You can't know. You have no clue how much money you'll make coz you don't know what your solution is. 18:40 Reason 3: Roadmaps. Number 1 on my list of why teams fail. The two inconvenient truths about products. First: At least half of the items on your roadmap won't work with customers. 21:40 Second inconvenient truth. Things that could work require iteration to work. Requires money and patience. 21:50 Jeff Bezos quote "Be stubborn on the vision, but flexible on the details". Roadmaps are the details 25:26 Reason 4: The Role of Product. Capturing requirements is not the role of product managers. That's project management. 28:17 Reason 5: The Role of Design. In this process, it's considered the lipstick on the pig form of design. "We need missionaries, not mercenaries" 32:32 If this is the way your company insists on working you might as well use a visual design agency. The reason we bring it in house is so that we don't work this way 33:00 Reason 6: The role of engineering. They're not just there to code 34:10 Reason 7: The role of agile. 35:20 Reason 8: Output Not Outcome. Output is easy. Results are hard. 37:57 Reason 9: Customer Validation Too Late. Nail in the coffin for the waterfall process. 39:10 Reason 10: Opportunity Cost. This way of working (waterfall) takes a lot of time and a lot of money. You can't get that back. 41:55 SOLUTION: Continuous Product Discovery. Ideas> Discovery> Delivery 44:15 Vision and OKRs. OKRs are the alternative to roadmap. OKRs tell us what problem to work on this quarter not solution 45:25 Run MVP tests in discovery and the idea is to get the product market fit. Those are the two most important concepts in product. MVP and Product Market Fit. 45:50 When we're in product discovery we need to make sure whatever were making is valuable for people. It also needs to be usable. Feasable is can we build it and would our stakeholders support it 46:55 Should we build it? Suggesting we add ethics to discovery 48:14 It's all about quickly getting that evidence, separating the good from bad, and making sure our developers are spending most of their time building production, building stuff we have evidence is going to move the needle.

[@prabhatsingh5234]

Great thanks just 1 correction, Source of idea is data 13:21

[@aaravkairavlogs7746]

Thanks for briefing

[@MuhammadWaseem-wh2vy]

He literally changed the mindset of millions of people out there. Thanks Marty

[@prabhatbhadouria]

Continuous Discovery and Delivery is the way to go forward instead of following the Waterfall(Agile) methodology of delivering solutions to your customers. The Waterfall(Agile) is time consuming, expensive, built on log of assumptions based on discussions with not so correct stakeholders. For more knowledge on this new way of building products we must give a read to this very nice book by Marty named as 'Inspired'.

[@jell6551]

I love Marty really knows the product game

[@onpointux]

He sounds like Ross from Friends

[@sreekanthchandramouli5489]

Wonderful insights!

[@shortsandshortsonly]

This is fantastic 🎉!! And I learnt a lot ! Off to finding a company which is at least believe in this

[@BalamuruganRathinavel]

This is one of the gem by Marty

[@_sonicfive]

The way he gasps for air at the beginning of his talk makes me think he is overwhelmed with so much he needs to say in so little time and we are about to drink water from a fire hydrant.

[@croccoilbrigante6621]

are the slides available? Thanks

[@samanmm]

Depends on the engineer. My engineers have no interest in learning about the business problems.

[@니모-b6w]

Moore Donald Martinez Frank Taylor Angela

[@beregu]

12:36 Engineers are dangerous. They dream a lot, but… 😅

[@mosta2]

too much talking about the problem no solution provided

[@MrTrentiusMaximus]

Well yeah, the subject of the talk was root causes of product failure not product success. His other talks are about how to do it right/better.

[@meiyorgold3774]

If you were patient to listen to the end he spoke about the better way to go about achieving product success. He titled that part Continuous Discovery and Delivery. The third and final segment of his speech.

[@franksaruhan]

I need a shorter way. For example a list of root causes is enough.

[@JulioReguero]

First lesson: It's impossible to please everyone all the time. If the speaker talks too much about the solution, then you most likely will complain about what's wrong with the traditional way of building products. Second lesson: If you work in the product space, you're probably not qualified enough if you say things like "too much talking" when you clearly don't have a better solution. Learn how to learn.