Kano Model

Over the past year we have built a completely new product that enables content marketers to optimize paid amplification of their earned and owned media. We have built the product from the ground up and as it grows I use Kano model as one of the tools to track its progress. Kano model is a theory of product development that categorizes product features into threshold, performance, and excitement attributes and then explains how product features in each category influence customer satisfaction depending on the level of their implementation. Satisfying the basic user needs, that is, threshold attributes such as reports aggregation and campaign management, was a prerequisite that allowed us to enter the market. When I was collecting proposals what to include in the product development roadmap, I often heard remarks such as "Yes, you cannot be a Content DSP without such feature." Now that we have implemented a large part of the threshold attributes our focus has shifted to implementation of performance attributes which are directly related to the price the customer is willing to pay for the product. As the competition in our line of business heats up, performance attributes will be essential for us to remain competitive. What I find particularly interested is the permanent clash of threshold and performance attributes for the development resources that is taking place at the moment. Users missing some threshold attribute are extremely vocal in their complaints, but giving up to their requests would greatly reduce the amount of efforts invested in development of performance attributes and, consequently, our competitiveness in the market.

We're definitely not building just another product, but we want it to become world class. To have an exciting product we will have to build also some features which are not really expected by our customers but which, once implemented, can result in high levels of customer satisfaction since they often satisfy latent needs, that is, real needs of which customers are currently unaware. But once we will start considering also excitement attributes for our product development roadmap, I expect my life to become even more complicated as stakeholders will want to have engineering time dedicated to development of (obvious) threshold attributes and (required) performance attributes, while they will have hard time understanding why product development will be pushing for development of excitement attributes which are not required to solve immediate business needs but are essential for long term success of our endeavors.