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