Skip to content
Sign in
Artwork for Better with Kent
Better with Kent · June 3 · 16 min

How to Prioritize Software Tasks

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 fight 1:39 What type of feature is this? 2:15 Basics (Must-be) 3:47 Performance needs 5:38 Delighters 6:32 GPS lifecycle reveal 7:56 Why silence misleads teams 10:00 Cannot delight out of broken basics 10:36 AI and the junk drawer 11:52 Prioritized build order 14: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

0:00-16:11
Play in
Transcript file

transcript

No transcript — this publisher did not publish one.

show notes

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 fight
  • 1:39 What type of feature is this?
  • 2:15 Basics (Must-be)
  • 3:47 Performance needs
  • 5:38 Delighters
  • 6:32 GPS lifecycle reveal
  • 7:56 Why silence misleads teams
  • 10:00 Cannot delight out of broken basics
  • 10:36 AI and the junk drawer
  • 11:52 Prioritized build order
  • 14: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

links1

more episodes

All episodes