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

Поділитися
Вставка
  • Опубліковано 26 вер 2024

КОМЕНТАРІ • 20

  • @kimbfwhite
    @kimbfwhite 2 роки тому +86

    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.

  • @MuhammadWaseem-wh2vy
    @MuhammadWaseem-wh2vy Рік тому +4

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

  • @prabhatbhadouria
    @prabhatbhadouria 4 роки тому +12

    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'.

  • @sreekanthchandramouli5489
    @sreekanthchandramouli5489 5 років тому +9

    Wonderful insights!

  • @onpointux
    @onpointux 4 роки тому +16

    He sounds like Ross from Friends

  • @jell6551
    @jell6551 3 роки тому +3

    I love Marty really knows the product game

  • @shortsandshortsonly
    @shortsandshortsonly Рік тому +1

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

  • @_sonicfive
    @_sonicfive 2 роки тому +2

    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
    @croccoilbrigante6621 4 роки тому

    are the slides available? Thanks

  • @니모-b6w
    @니모-b6w 11 днів тому

    Moore Donald Martinez Frank Taylor Angela

  • @beregu
    @beregu Рік тому

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

  • @mosta2
    @mosta2 4 роки тому +5

    too much talking about the problem no solution provided

    • @MrTrentiusMaximus
      @MrTrentiusMaximus 2 роки тому +8

      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
      @meiyorgold3774 Рік тому +4

      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
      @franksaruhan 9 місяців тому

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

    • @JulioReguero
      @JulioReguero 7 місяців тому +1

      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.

  • @BalamuruganRathinavel
    @BalamuruganRathinavel Рік тому

    This is one of the gem by Marty

  • @samanmm
    @samanmm 8 місяців тому +1

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