Notes from 'Root Causes of Product Failure' by Marty Cagan


I took a LOT of notes during Marty Cagan's The Root Causes of Product Failure talk. Highly recommended. Here are the highlights…

  • “There's a tremendous difference… between how most companies work and how the best companies work.” (1m)

  • “The vast majority of product efforts fail.” (2m)

  • Vast majority of companies: Ideas > “biz case” > roadmap > requirements > design > build > test > deploy. This is waterfall. Incredibly ineffective. (6m, 10m)

  • Two big reasons companies like roadmaps. Know they're working on the highest priority things. And some level of predictability. (7m)

  • Biz cases drive roadmap priority, based on two inputs. How much money we'll make, and cost to build. “You have no clue how much money you are going to make” b/c you have no idea how good solution will be. All we have is an idea. And no idea how much it'll cost to build. (8m, 14-17m)

  • Engineers are best source of ideas. Execs and customers are least valuable. Why? Engineers work with tech every day. Best position to see what's just now possible. Product = matching real customer need/pain with what is just now technically possible. Magic! (12m)

  • It's a huge lost opportunity not to include engineers at ideation stage. (12m)

  • Data is other best source of ideas, but often not in hands of those doing ideation. (13m)

  • Customers are awesome. But not good for coming up with product ideas. They don't know what's technically possible. And “they don't know what they want until after they see it”. (13m)

  • Running smart tests is only way to know how much money you might make from a roadmap item. Most features contribute zero value. (16m)

  • T-shirt sizing (for estimating effort to build) is “corporate silliness”. (18m)

  • Roadmaps are #1 on list for reasons teams fail. “Two inconvenient truths about product”. 1) At least half roadmap items will not deliver customer value. 2) The half that could work will take several (3, 4, 5) iterations before they work well enough to make money. (19-22m)

  • Iterations take a long time. Startups run out of money. Larger orgs run out of management patience. There is so much orphaned software! (22m)

  • “What matters is not time-to-market in our business, it's time-to-money (time-until-valuable)” (23m)

  • At almost every company, putting something on a roadmap is a commitment, then we're locked in to delivering. (24m)

  • On product - job of “product” should not be just to “gather requirements”. Should not be merely project managers. (27m)

  • On design - design is brought in too late, lip-stick on a pig. Working on things “where a lot of bad decisions have already been made”. (28m)

  • On engineering - “If you are just using your developers to code, you are only getting about half their value.” (33m)

  • On agile - this process is not agile. Maybe agile in delivery, but only 10% of the value of agile. This process is not flexible on the details (Jeff Bezos quote - be stubborn on vision, flexible on details) (34m)

  • Focus on outcome, not output. Easy to get output, hard to get results. (36m)

  • Customer feedback happens way too late. This is the opposite of “lean startup”. “This is the slowest, most expensive way to validate our ideas.” (38m)

  • Opportunity cost. This way of working is slow and expensive. (39m)

  • Best teams = continuous discovery and delivery. Many more sources of ideas. Use product discovery techniques to quickly separate good and bad ideas, quickly iterate to a solution, then build production-quality software (42m)

  • Good teams try out many more ideas. Deliver on solutions where they have evidence to support them. (44m)

  • OKRs and vision as favorite alternative to roadmap-driven process. OKRs tell us what to work on this quarter, what problems to solve, not solutions. (44m)

  • Main way to get evidence is to run MVP tests. MVP is not a product. It's an experiment, a test. Idea is to get to product-market fit. 3 key areas when in discovery-mode: is it valuable, usable, feasible? Also ethical? (46m)

  • All about “[m]aking sure our developers are spending most of their time building production, building the stuff we have evidence is going to move the needle.” (48m)

  • Learn more > read his book (Inspired - How to Create Product Customers Love) and get free newsletter at svpg.com.