Client Project Disclosures
The Kano Model and how it impacts specifications and customer satisfaction is just one facet of the conversation.
The area below Threshold could be content the development partner failed to implement. But there is another story. This is often content the client assumed was known but wasn’t. It often isn’t in the specification or perhaps the development partner didn’t understand the words. Because the client lives within their context they don’t realize it is there. This information is largely disclosed over time. Clients are suddenly reminded or disclosure happens when an issue is raised. This can be painful.
The Delighters area then has to be content the client doesn’t know about yet which is discovered along the way. We know that many great product features fit into this category. When the scope is fixed it is more difficult to pick up these additions. What we find is the Performance line is really Customer Expectation whether communicated and understood or not. Agile methodologies have been applying these ideas to the development phase for decades (see Jeff Patton’s “Unfixing the Fixed Scope Project: Using Agile Methodologies to Create Flexibility in Project Scope”).
Shinkle’s presentation suggested that we design experiments to discover product features, test assumptions and resolve/realize risk.
Can we design something to promote client disclosure?