Posts Tagged With: customer satisfaction

Kano and perception minus expectations

For many years, my personal e-mail signature has been a quote from David Maister’s book on professional service management: “Customer satisfaction = Perception – Expectations“. This formula simply but elegantly captures how we feel when our expectations are either exceeded (or the opposite) when acquiring a product or receiving a service.

The Kano model provides a theory for product development and customer satisfaction. In an earlier article, I tried to connect this model and project management, but having just experienced an example of how past experiences can impact expectations and perceptions, I felt a follow up piece on Kano was warranted.

As a refresher, Kano’s original model provided four broad categories for product features: Must-be, attractive, one-dimensional and indifferent. I will describe these and provide examples from the personal automotive industry.

  • Must-be attributes are sometimes referred to as hygiene factors as they must be part of a product or service but gold-plating won’t result in greater satisfaction. Seat belts on a car are one example of these.
  • Indifferent features are those which don’t positively or negatively impact customer satisfaction regardless of their presence or absence. Fuzzy dice hanging from the rear-view mirror would likely fall into this category for the majority of car owners.
  • One-dimensional attributes are those which demonstrate a linear relationship to customer satisfaction. Seating surfaces in a car are one example of these. While I will be happier having leather seats than cloth seats, I am not likely to be exponentially happier.
  • The final category is attractive which are often referred to as delighters. These are those attributes which are unexpected but will excite or delight a customer. Heated steering wheels for purchasers in colder climates were an example of these a couple of years back.

While this categorization is helpful and can be used to support product feature decision making, the theory also suggests that over time, attributes we used to find attractive become one-dimensional and might even drop into the must-be category.

I spent the past week relaxing at a Caribbean resort. This was my third trip to the same resort and a contributing factor in the decision to return a third time as well as the reason I had strongly promoted this resort to others was the magnitude of recognition I had been shown upon my second visit last year. This recognition far exceeded any expectations I might have had so the specific nature of the recognition clearly fell into the attractive category.

Given how far my perceptions had exceeded my expectations on my second visit you can understand why I would have similar expectations for a third visit. The attractive had now become a one-dimensional. Unfortunately, reality fell short of expectations and while my overall experience at the resort was pleasant, I still felt let down.

Past perceptions set expectations.

If you delight your customers once but fail to do so on subsequent transactions, don’t be surprised if they are dissatisfied with otherwise acceptable levels of service.

Categories: Project Management | Tags: , | 1 Comment

Essentialism is agile

I’m reading Greg McKeown’s book Essentialism: The Disciplined Pursuit of Less and many of the lessons within it echo the tenth principle from the Manifesto for Agile Software Development which is “Simplicity–the art of maximizing the amount of work not done–is essential“.

In the past, I’ve mostly considered this principle as it relates to how we deliver value to our customers. It provides a constant reminder that practices, ceremonies, tools and artifacts are just a means to an end, and shouldn’t be elevated as an end unto themselves. Minimal sufficiency should be our goal when expending effort on anything which doesn’t create business value for our stakeholders.

But we can also apply this principle to our products.

While Greg’s book provides a lot of insights, there’s one line which really resonates with me: “If it isn’t a clear yes, then it’s a clear no.”

Greg provides an example of the company Vitsoe which applies this filter when hiring new staff, but the same principle could be applied when deciding what to include in product backlogs. Let’s consider the example of the mice provided with the first Apple Macintosh computers. The design team at Apple could have added multiple buttons and scroll wheels the way future generations of PC mice were designed, but a single button sufficed to allow a user to effectively use the Macintosh graphical user interface.

This principle is key when defining Minimum Viable Products (MVP). A good MVP should generate empirical evidence to support or refute a hypothesis and adding features which won’t directly support that learning is waste.

But minimal sufficiency could be applied beyond MVPs to general releases. By doing so we can reap some of the following benefits:

  • Reducing learning curve. One of the attributes of well designed products is that they can be used with minimal instruction.
  • Reducing ongoing maintenance costs. To quote Scotty from Star Trek III: The Search for Spock – “The more they overthink the plumbing, the easier it is to stop up the drain
  • Reducing ongoing regression testing efforts. As system complexity grows, the points of interdependence between seemingly unrelated components makes it almost impossible to avoid regression defects.
  • Focusing development teams on core capabilities.

To quote Greg, the next time you are considering whether or not to add a feature, ask yourself the question “Is this exactly what I am looking for?



Categories: Agile | Tags: , , | 1 Comment

Have courage!

When we think of the characteristics of a good team player, we tend to come up with attributes such as demonstrating selflessness, possessing empathy, or being a good communicator. While these are all critical to creating a high performing team, one trait of effective project managers and team members is the ability to do things which take them outside of their comfort zone. In other words, courage.

Why do I consider courage to be so critical?

Courage won’t guarantee that right decisions will get made, but it might prevent some bad ones.

Presented with an unrealistic deadline to deliver fixed scope with fixed resources and budget, if no one demonstrates courage by raising concerns or by negotiating for a feasible commitment, the team might have just signed up for their very own real-life Kobayashi Maru scenario.

Perhaps a sponsor or other senior stakeholder is pushing for the use of a particular delivery approach for political reasons. If it is not the best fit for the needs of the project, it’s rare that the accountability for this bad decision would fall on that stakeholder but it’s more likely that the team will bear the brunt of the issues.

Maybe the business case for your project is no longer attractive. It might be safer to keep your head down and continue to deliver according to approved baselines, but wouldn’t it be better for your company, your team and your own career if you were to bring this concern to the sponsor or other appropriate governance body?

Maybe your organization’s project management methodology requires the completion of a particular artifact. No one on your team believes it adds any delivery or risk control value. If you don’t have the courage to ask “Why?” or to seek an exemption, you’ve likely lost some credibility with your team members.

Courage preserves integrity by enabling us to operate with transparency

It’s hard to tell your customer that there is a unrecoverable variance or other critical issue with their project. But if we candy-coat this message, or worse, avoid telling the customer entirely, the truth will out, and the fall out is likely to be much worse than if we’d summoned the courage to break the bad news in a timely manner.

Maybe one of your fellow team members is behaving in a manner which is irritating others. If we don’t have the courage to provide coaching or constructive feedback sensitively but directly to that team member and give them an opportunity to respond, we aren’t demonstrating respect for that team member or our team.

Courage enables us to grow

Whether your project is being delivered using an adaptive or a deterministic life-cycle, team members and your company as a whole will benefit if they occasionally work on activities which fall outside of their core specialization, if doing so benefits the team. Developing generalizing specialists will take support from both functional managers and from one’s peers, but it also requires a healthy dose of courage for us to try something for the first time, knowing that we might fail. This applies not only to the activities performed by team members, but also the types of projects or work assignments we ourselves take on.

Courage is the most important of all the virtues because without courage, you can’t practice any other virtue consistently.” – Maya Angelou


Categories: Project Management | Tags: , , , , | Leave a comment

Blog at

%d bloggers like this: