Use the Kano model as a force function for tech debt

For something that impacts performance at scale and stability, keeping on top of tech debt is harder than it should be.

For PMs, have a look at the Kano model as a force function to think about how features and non-functionals affect customer satisfaction – and they don't all affect it the same way. Super useful.

• Must-be. Customers expect these. Nobody thanks you when they work, and everyone notices when they don't. Think stability, performance at scale, smooth upgrades, security.
• Performance. More is better, in a straight line. Faster search, more integrations, lower cost.
• Delighters. Unexpected features that create genuine excitement. Customers don't ask for them, but they love them when they arrive.
• Indifferent. Customers don't care either way. Build it or don't, satisfaction doesn't move – and every sprint spent here is one not spent on your must-bes.
• Reverse. Some customers actively dislike these. More isn't better, it's worse. Think forced pop-ups, or complexity a few power users wanted and everyone else resents.

Must-be work is invisible right up until it fails – and trust me, that is not fun.

Kano helps avoid the trap in three ways:

1. It legitimises platform work. Scalability and reliability aren't "engineering's backlog". They're must-be product qualities, and when you fall below the line, no innovation compensates.
2. It changes the question. Stop asking "feature or tech debt?" Ask "are our must-bes above the line?" If not, that's the priority. If they are, invest in delight.
3. It explains why delighters decay. Today's wow becomes tomorrow's expectation. AI features are moving from delighter to must-be faster than anything I've seen. If your platform can't support that shift, your innovation has a shelf life.

A roadmap that is 90% delighters may well come back to bite you.