Afleveringen

  • Kent walks Clay Christensen's jobs-to-be-done lens on a food-delivery shared-cart ticket — three questions that turn a solution into a job statement, plus Wayne Allan's Australia flop and Aaron D. Francis on deciphering feature requests.

    (00:00) - Your backlog is full of solutions(01:27) - Jobs to Be Done(03:12) - Shared cart ticket(04:04) - When it goes wrong — Wayne(06:01) - Three questions before you estimate(06:40) - Question 1 — progress and circumstance(08:56) - Question 2 — what they hire today(10:09) - Question 3 — what would fired look like(11:22) - Aaron on solutions vs jobs(12:54) - The job statement(13:47) - Stack with Kano(14:40) - Big hire vs little hire(17:19) - The habit — what job is this for?(19:27) - Homework(20:12) - Books and close

    Better with Kent — durable skills for people who ship software.

    Your backlog is full of proposed solutions. Kent walks a shared cart / group ordering ticket (same food-delivery app as the Kano episode) through Clay Christensen's Jobs to Be Done framework — why the expensive mistake is building the wrong thing, not bad code.

    Three beats land early: a ticket is not a job, hire/fire/progress language, and the habit "What job is this for?" before the estimate, PRD, or agent prompt.

    When it goes wrong — Wayne Allan (*Become an Epic Product Engineer*) on building for every person in Australia logging in at once: ~1.2M AUD, zero users.

    Three questions before you estimate: progress and circumstance, what they hire today (group text, separate orders, Venmo as workaround), and what "fired" looks like.

    Aaron D. Francis on what users actually want vs the button they asked for.

    The job statement: *When our team orders lunch together, help us coordinate food and check out once — without a 40-message thread.*

    After you ship: little hire vs big hire, why metrics alone miss the emotional job, and stacking qualitative signal. Homework: one sentence — what is the job to be done?

    Links

    Wayne Allan — The right thing before the thing right (Become an Epic Product Engineer)Aaron D. Francis — Vertical slices, Solo, and empathy (Become an Epic Product Engineer)*Competing Against Luck* (Clay Christensen et al.)HBR — Know Your Customers' "Jobs to Be Done"*Jobs to be Done: Theory to Practice* (Anthony Ulwick)The Last Software Engineer (essay)How to Prioritize Software Tasks (Better with Kent — Kano episode)Better with Kent on kentcdodds.com
  • Kent walks the Kano model on a real food-delivery backlog: Must-be, Performance, and Delighter — why GPS was a wow in 2015 and a basic today, and why you cannot delight your way out of broken basics.

    Chapters

    0:00 The backlog fight1:39 What type of feature is this?2:15 Basics (Must-be)3:47 Performance needs5:38 Delighters6:32 GPS lifecycle reveal7:56 Why silence misleads teams10:00 Cannot delight out of broken basics10:36 AI and the junk drawer11:52 Prioritized build order14:25 Homework and close

    Better with Kent — Durable skills for people who ship software.

    You have five backlog items and everyone wants their feature first. Kent uses a food delivery app example and the Kano model (Must-be, Performance, Delighter) to show what type each feature is — and what to build first.

    Land three beats: broken confirmation email is a Must-be (fix before anything else), estimated delivery accuracy is Performance (more accurate = more satisfied), surprise discounts and group ordering are Delighters (fun to build, dangerous when basics are broken). The GPS reveal: tracking felt like magic in 2015; today missing GPS means users leave.

    Why teams get this wrong: silence in support is not proof basics work — most users leave without filing tickets. You cannot delight yourself out of broken basics. AI makes it worse when agents churn exciting Delighters while hygiene features rot.

    Homework: label five real backlog items, fix broken basics first, ask whether last year's Delighter became today's Must-be.

    Become an Epic Product Engineer guests cited: Wayne Allan, Sean Roberts, Swizec Teller, Don Norman, Dillon Mulroy, Dax Raad.

    Links

    Watch on YouTube
  • Zijn er afleveringen die ontbreken?

    Klik hier om de feed te vernieuwen.

  • Kent maps the durable skills that stay valuable as agents take more implementation: clarity, judgment, empathy, feedback loops, systems thinking, agent fluency, and ownership — with practical homework for each cluster.

    (00:00) - Intro: Google stat and durable skills(00:20) - Why now(01:08) - Durable skills map(01:25) - Clarity & judgment(03:40) - Wayne Allan: build the right thing first(04:28) - Practice: clarity & judgment(06:01) - User empathy & feedback(07:29) - Practice: empathy & feedback(08:56) - Systems thinking(12:22) - InfoWorld: AI coders need good engineers(18:52) - Agent fluency(20:14) - Practice: agent fluency(21:26) - Ownership(23:03) - Slow down on purpose(27:05) - What to deprioritize(28:04) - Homework

    Better with Kent — Durable skills for people who ship software.

    Episode 1 is the map. Agents can implement faster every month; the expensive mistake is building the wrong thing even faster. Kent walks through seven skills that were valuable decades ago and still matter in 2026: problem clarity, domain depth, judgment, empathy, feedback loops, systems thinking (including closing the agent loop), agent fluency, and ownership.

    Three clusters pair each skill area with concrete practice — stakeholder rooms, wiring daily feedback, building tests and CI so agents can iterate. Kent cites Become an Epic Product Engineer guests (Wayne Allan, Jack Ryan, Aaron Francis, Dillon Mulroy, Swizec Teller, Ruben Casas, and others), reacts to Matt Asay's InfoWorld piece on AI-generated code, and closes with homework you can do this week.

    Not a tool demo. Not a PM course. Not a framework checklist — just durable skills for people who ship software.

    Subscribe and comment with topics you want covered. Chats with Kent (Become an Epic Product Engineer) continues with guest interviews; Better with Kent is Kent thinking out loud on camera.

    Links

    InfoWorld — AI coders need good software engineers (Matt Asay)The Last Software Engineer (essay)Become an Epic Product Engineer (guest podcast)Better with Kent on kentcdodds.com
  • AI is accelerating change for software engineers. Kent introduces Better with Kent — solo episodes on durable skills, judgment, and knowing what to build — plus Chats with Kent guest interviews on Become an Epic Product Engineer.

    Better with Kent — Durable skills for people who ship software.

    The landscape is moving fast. Agents can implement more every month, which means the expensive mistake is building the wrong thing even faster. This series is Kent on camera — no guest — on judgment, accountability, problem clarity, and skills that stay valuable as implementation gets cheaper.

    Also continuing: Become an Epic Product Engineer with guests who blend technical depth and product judgment.

    Subscribe on YouTube, Spotify, Apple Podcasts, or wherever you listen. Comment with topics you want covered — Kent live-streams many recordings.

    Links

    Better with Kent on kentcdodds.comBecome an Epic Product Engineer (guest podcast)Kent on YouTube