{
  "video": {
    "id": "_fHTqOs5wQA",
    "title": "Build the Right Thing: Product Engineering (Part 1) — Kent C. Dodds, EpicProduct.engineer",
    "duration": 3319,
    "upload_date": null,
    "channel": "AI Engineer",
    "source": "AI Engineer",
    "event_format": ""
  },
  "analysis": {
    "video_id": "_fHTqOs5wQA",
    "title": "Build the Right Thing: Product Engineering (Part 1) — Kent C. Dodds, EpicProduct.engineer",
    "one_liner": "When AI agents level the implementation playing field, the scarce skill becomes judging what is worth building, so engineers who only turn tickets into code \"look an awful lot like an agent.\"",
    "summary": "Kent C. Dodds argues that agents now work like homing arrows that can hit almost any target, so the engineer's lasting value is choosing the right target. He calls this product engineering: linking an understanding of what customers need to technical choices such as the data model, workflow shape, observability, constraints, failure modes and the smallest slice. He makes the case with quotes and stories from his podcast guests (Wayne Allen, Uncle Bob, Don Norman, Michael of WorkOS, Dax Raad, Rita Kozlov, Aaron Francis and others). He then starts on early idea validation with The Mom Test, using an audience-chosen example: the 'Just Get In (The Workshop)' app, prompted by the long line outside his own session. He says Jobs theory and the Kano model are still to come.",
    "key_points": [
      "Thesis (his 'take a photo of this' slide): when AI agents level the implementation playing field, building the right thing becomes the differentiator. The question moves from 'can we build it' to 'is it worth building', and this applies to enterprise internal features as much as to startups.",
      "Archer metaphor: agents are like homing arrows, so you can hit far more targets with ease. The targets are not equally valuable, and knowing which one to aim for is the skill. Aiming at all of them would also overwhelm users.",
      "Product engineer vs product manager: the product engineer stays in the system. They know its primitives and limits (for example an existing cron or queue system and its problems), make technical decisions (data model, workflow shape, observability, constraints, failure modes, smallest slice), and use their understanding of upstream requests to avoid painting themselves into a corner or overbuilding.",
      "Changing architecture is still expensive even if an agent can do it in 'a couple million tokens', because of the impact on the team and on users. Getting the primitives right the first time matters. Example: after talking to customers, WorkOS chose a hosted product over on-prem or open source because security fixes had to ship immediately rather than wait for npm upgrades.",
      "AI flips the old 'whittle to the smallest useful slice' picture: AI produces the whole thing and your job is to cut it down to the useful part. Instagram began as Bourbon, a Foursquare-like check-in app, and cut everything except photo sharing.",
      "The Mom Test: don't ask people to judge your idea or diagnose the problem, and don't ask about the future ('would you use/pay for this?'), because that just fishes for compliments. Ask about past behaviour: the last time it happened, what you did instead, what it cost, who was involved, how often it happens and how much effort the workaround takes. Heavy effort or spending on workarounds is 'gold'. Not remembering the last time is a negative signal you still want to hear.",
      "Wayne Allen's cautionary tale: an Australian real-estate team spent a year and AU$1.2M (about US$900k) building a microservices system scaled for everyone in Australia logging in at once, and nobody used it. He says they could have launched in two weeks and done the integration manually.",
      "Don Norman (who coined 'user experience' at Apple) concluded from Three Mile Island in 1979 that the operators weren't at fault; the system was. Hence 'user error does not exist'. Uncle Bob described riding along with a telephone-pole technician and immediately seeing about 30 things to improve in his software."
    ],
    "takeaways": [
      "Stop working purely to spec. If a feature request arrives without validation, ask the PM why it exists. Whether it is a one-off experiment or core to the business should change how much you invest and which technical trade-offs you make.",
      "Validate ideas with Mom Test questions about past behaviour (last time, workaround, cost, frequency), never with 'would you use or pay for this'.",
      "Get rough prototypes to early adopters quickly. If they push through the gaps anyway ('run through the glass'), the problem is worth solving. If paper cuts make them give up, take that as a signal too.",
      "Treat yourself as team lead of your agents. Build a good 'playground' (testing, architecture, clear primitives), take ownership of prototypes and be willing to throw them away and reimplement properly. Look at least one neighbouring team out, up and down so you don't rebuild primitives the organisation already has.",
      "In hiring, drop coding challenges that ban agents. Instead, ask candidates which questions they would use to find the core problem, then what that problem means for the system."
    ],
    "topics": [
      "product engineering",
      "ai agents",
      "idea validation",
      "mom test",
      "user research",
      "mvp",
      "software architecture",
      "career"
    ],
    "tools": [
      "OpenCode",
      "T3 Code",
      "WorkOS",
      "Cursor",
      "Cloudflare",
      "Slido",
      "Instagram",
      "Bourbon",
      "Foursquare",
      "React",
      "The Mom Test",
      "The Design of Everyday Things",
      "Design for a Better World",
      "Jobs theory",
      "Kano model"
    ],
    "quotes": [
      {
        "text": "When AI agents level the implementation playing field, which they are actively doing, then the differentiator becomes building the right thing.",
        "at": "10:54",
        "url": "https://www.youtube.com/watch?v=_fHTqOs5wQA&t=654s"
      },
      {
        "text": "guess what you look like when you're just taking a ticket and turning it into an implementation. If that's you, you look a awful lot like an agent to me.",
        "at": "17:09",
        "url": "https://www.youtube.com/watch?v=_fHTqOs5wQA&t=1029s"
      },
      {
        "text": "you can do the wrong thing incredibly fast and feel like you're making a ton of progress.",
        "at": "20:49",
        "url": "https://www.youtube.com/watch?v=_fHTqOs5wQA&t=1249s"
      },
      {
        "text": "The problem was the system. The system was wrong. User error does not exist.",
        "at": "30:21",
        "url": "https://www.youtube.com/watch?v=_fHTqOs5wQA&t=1821s"
      }
    ],
    "words": 12354
  },
  "summary_url": "/#_fHTqOs5wQA",
  "transcript": {
    "html": "/transcripts/_fHTqOs5wQA.html",
    "txt": "/transcripts/_fHTqOs5wQA.txt",
    "vtt": "/transcripts/_fHTqOs5wQA.vtt"
  }
}