Gaining Stakeholder Buy-in by Prioritizing User Satisfaction

Matthew J. Smith
4 min readJan 15, 2021

--

As we sit down with clients to kick off a new project or optimize an existing one, we’re often presented with an extensive list of ‘required’ features the client is certain (they think) they need for their site.

So how do we sift through these requirements and pinpoint the ones that are must-haves and which shift to backlog?

At C2, one of the tools we use to validate these requirements, and gain stakeholder buy-in, is the Kano Model. This is a critically important step, because if everyone isn’t in agreement about what’s best for the project and its users, it’s much more difficult to be successful.

First, what is the Kano Model?

The Kano Model is a set of ideas that help us determine our customers’ satisfaction with product features. This theory was written by Japanese researcher and consultant, Noriaki Kano, and published in 1984. In short, Kano believed that not all features of a product were equal in the eyes of the customer, and that some will lead to higher levels of customer satisfaction and loyalty than others.

Second, how does this work?

The Kano Model grades feature categories on two dimensions:

  1. Satisfaction (Y-axis): which scales from Frustration to Delighted.
  2. Functionality (X-axis): which scales from None to Best. This can also be viewed as performance or investment as these often go hand-in-hand.

These two dimensions put together are the basis of the Kano Model and determine how our customers feel about our product’s features. Features are placed into four categories, depending on how we anticipate customers will react to the provided level of functionality.

Performance: These features behave as we expect basic satisfaction to work: the more we provide, the more satisfied our customers become. Each increase in functionality correlates to increased satisfaction. It’s also important to note that the more functionality we add, the bigger the investment we have to make. As we’ll see next, this may be a basic understanding of creating a satisfying product, but it doesn’t always guarantee success.

Example: The more features that get added, the more likely it is a satisfying product gets delivered. It’s also more likely for the project to run over budget, threatening overall success.

Expected (or must-haves): Some features are simply expected. If we leave these out it will be considered incomplete or bad. Here’s the catch, we need to have these, but that won’t make our customers happy. They just won’t be frustrated. These are the features that must be prioritized first because no matter how amazing other features are, users won’t be likely to use it.

Example: A customer’s expectation is that it will be easy to find a product’s detail page and add the product to their cart for checkout.

Attractive (or delighters): These are the features that, when the user experiences them, lead to a positive reaction. These don’t have to be cutting edge technology or blow our user’s minds. They just have to be an unexpected positive.

Example: Working in commerce, we’ve delivered a ‘guided sell’ feature that allows customers to narrow in on their product-hunt with multiple selectable classifications.

Indifferent: Some features users just won’t care about. They don’t improve the experience or hurt it. It’s important to think about a feature from a user’s perspective. If it won’t provide value, or isn’t a “must-have”, then it’s best avoided as waste of time and effort.

Example: A client may think it’s beneficial to put VR within their site for their customers to experience ‘try before buy’, although customers may already know exactly what they’re coming to purchase.

The Kano Model is a simple, yet powerful tool to involve stakeholders in during the prioritization process. We use this model to help organizations understand their customer needs better than their customers understand their own needs. If Stakeholder “A” is dead set on a Feature “X”, but everyone can agree that it’s not a “must-have”, we can put it into the backlog for later development. This helps stakeholder “A” feel heard but also understood that there’s a better use for their investment at that point in time.

--

--