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.
{{chapters}}
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
