Prioritisation Chaos:Your ‘Perfect’ Research Isn’t Perfect

Why perfect surveys can still produce confusing results, and how to get clarity with context, segmentation, and critical thinking.

Feb 04, 2026

In this post I’ll cover:

The textbook version of KANO analysis for prioritisation
Prioritisation framework limitations from a research perspective
Practical guidance and examples on how to use research rigour to your advantage (and no, it doesn’t take ages)

I recently worked with a product team who recently conducted their KANO analysis. They’d followed the textbook process perfectly: created functional and dysfunctional questions, recruited users, classified responses, visualised the data. Everything looked clean and methodical.

Then we looked at the results together. No clear must-haves. Too many features classified as delighters. Weak alignment with actual usage patterns they were seeing in their analytics. The team was confused. They’d done everything right, so why did the insights feel... off?

This is a pattern I see constantly. Teams follow frameworks to the letter and end up with misleading insights anyway. The problem isn’t KANO itself. The problem is treating any research framework like a recipe you can execute without thinking about what you’re actually measuring.

Recent research shows that prioritisation is a real challenge for product teams. A 2024 Product Focus survey found that complex prioritisation decisions are among the top three challenges facing product managers today, yet only 23% have a formal process for prioritising features. PMI’s 2024 report goes further, showing that 44% of projects fail due to lack of structured decision-making. Common choices for the teams that do use frameworks are weighted scoring, KANO, RICE, value vs complexity etc.

But here’s what these surveys don’t capture: how many teams are using these frameworks poorly, generating data that looks rigorous but leads to bad decisions (or leaves them confused).

In the age of vibe-coding, where new products appear everyday, understanding how to use these frameworks for the problem at hand is crucial.

So I want to walk through how I actually use KANO in practice, and why critical thinking matters more than following instructions blindly.

The Textbook Version

The KANO Model is a product development framework that helps teams understand how different features affect customer satisfaction. The core insight: not all features increase satisfaction in the same way.

Teams use it for prioritising features for new products, deciding what to build next, improving satisfaction beyond basics, balancing innovation versus fundamentals, and avoiding over-investment in features users don’t care about.

The framework categorises features into five types:

Must-be (M): Basic features customers expect. Their presence doesn’t increase satisfaction, but their absence causes major dissatisfaction.
One-dimensional (O): Performance features where more is better. Satisfaction increases proportionally with quality.
Attractive (A): Delighters that cause excitement and differentiate your product from competition.
Indifferent (I): Features customers don’t care about either way.
Reverse (R): Features that actually cause dissatisfaction for some users.

This tells teams where to invest (one-dimensional, attractive), maintain (must-be), or cut (indifferent, reverse).

The standard process goes like this:

Step 1: Choose features to evaluate (8-15 is a good number).

Step 2: For each feature, create two questions:

Functional: “How would you feel if the product had this feature?”
Dysfunctional: “How would you feel if the product did NOT have this feature?”

Users rate each using specific options: I like it, I expect it, I am neutral, I can tolerate it, I dislike it.

Step 3: Recruit users and run the survey.

Step 4: Classify each response using the KANO matrix.

Step 5: Aggregate results per feature and count responses in each category.

Step 6: Turn results into decisions based on which category dominates.

Anyone who’s done this analysis before knows it is tedious work. This is why I just vibe-coded a tool where you can upload your survey data and get the categories, coefficients, and helpful data visualisation quickly, so you can focus on the really important parts (coming below). Leave a comment with “KANO” if you want the link.

KANO Is One Piece of a Puzzle

I’ve seen misleading insights appear when teams use KANO in isolation. Many teams lack proper integration of UX research insights and other data points into their product development strategy. They also make mistakes in how they frame the features being examined and how they analyse the data.

Let’s start with the feature selection, which can very easily go wrong. A good KANO study does not start with a backlog. It starts with evidence.

☀️ Use Multiple Data Sources, Not Opinions

Before selecting features, synthesise insights from:

User interviews: Recurring needs, frustrations, unmet expectations
Past surveys: Features with high importance but mixed satisfaction
Support tickets and complaints: Issues users assume should just work
Usage analytics: Underused features, drop-off points, workaround behaviour
Sales and onboarding feedback: Objections, deal blockers, time-to-value friction
Business goals and metrics: Revenue impact, retention drivers, conversion blockers, strategic priorities

Features that appear across multiple sources are strong candidates for KANO evaluation.

For example, if “exporting data” appears in interviews (”I need this weekly”), support tickets (”How do I export?”), and sales calls (”Do you support CSV?”), that’s a signal this feature deserves evaluation.

☀️ Focus on User-Perceivable Outcomes

Avoid technical or bundled feature descriptions that users can’t evaluate meaningfully.

🚩Poor feature definition: “Advanced analytics module”

✅ Strong feature definition: “View weekly trends and export reports as CSV or PDF”

If a user can’t imagine experiencing the feature, they can’t evaluate it reliably.

The Imagination Problem

Yes, I said imagine and this is where classic KANO is limited from a research perspective. When you ask users “How would you feel if the product had this feature?” they need to speculate about things they’ve never experienced.

Research in human-computer interaction shows that users struggle with imagining context. And context is exactly what’s missing in many research studies that fail to provide meaningful insights. (I wrote more about this in my piece on Netflix’s redesign and context in usability testing.)

This hypothetical bias often leads to no clear must-haves, too many delighters, and weak alignment with real usage patterns.

So how can we add context? Here are a few approaches I use (adapted to each challenge):

1. Segment Your Users Wisely

User recruitment matters more than we think. Target your right audience for your goal, and segment when analysing data. Filter by role, plan, experience level, usage frequency or whatever makes sense for your product. Let’s take a habit-tracking app KANO analysis I worked on as an example.

The team wanted to evaluate a feature: “Set custom reminder times for each individual habit.” When we looked at aggregated results across all users, it came back as Indifferent with some Reverse responses mixed in. The team almost deprioritized it entirely.

But when we segmented the data by usage frequency, a different story emerged:

Power users (tracking 5+ habits daily): 78% classified it as Must-be or One-dimensional. They needed granular control because they were tracking multiple habits throughout the day (morning meditation, lunch-time walk, evening journaling). Generic reminders didn’t work for their complex routines.

Casual users (tracking 1-2 habits): 65% classified it as Indifferent or Reverse. They found too many customisation options overwhelming. A simple daily reminder was enough.

New users (less than 2 weeks): 82% classified it as Reverse. They weren’t even sure which habits to track yet, let alone when to schedule them. The feature felt like premature complexity.

Without segmentation, we would have concluded “users don’t care about custom reminders.” With segmentation, we understood that this was a must-have for engaged users but created friction for new users. The solution: make it optional and progressively disclosed. New users get simple defaults. Power users can customise when they’re ready.

This is the value of segmentation. It doesn’t just tell you what different groups want, it helps you design features that serve multiple user needs without forcing everyone into the same experience.

2. Collect Data on Problem Framing

For every feature, add an open question: “What problem does this solve for you?”

This gives you data on user problems rather than solutions. Use this to get qualitative data on your tested feature. I’ve seen features where users didn’t actually know what problem they were solving, which is valuable information in itself.

3. Capture Usage Context

Add a question that captures context: “When would you use this?”

This helps identify features that are must-haves for rare but critical moments, delighters for frequent workflows, or reverse for users who never encounter the scenario.

4. Check for Prior Experience

Ask: “Have you used something like this before?”

This explains expectation gaps without guessing. A feature might be a must-have because users have encountered it elsewhere and now expect it. The same feature could be a delighter for users who’ve never experienced it before.

There are many more ways to complement your KANO analysis and find clarity based on your product’s unique features and scope. These are examples you can use as inspiration. Ask yourself: what additional data would help my KANO analysis make more sense?

How to Actually Use This

The most important part: context should explain KANO results, not override them.

When calculating scores and categories, keep your core KANO data clean. Then group your additional context data per feature and do thematic analysis (or whatever analysis suits your question type) to make sense of the context data.

Use the visualisations together with your contextual insights when making decisions with your team.

What I typically do with teams is also track business priorities, cost, effort, and feasibility using Quality Function Deployment or multi-criteria scoring. Then you’re genuinely prepared to conduct a prioritisation session that considers both user needs and business constraints and turns chaos and question marks into structure and confidence.

The Main Takeaway

Any research method has limitations and potential for bias.

This is why rigour matters even in fast studies.

Rigour doesn’t have to mean slow. It means good quality, correct, and meaningful insights. When you understand a framework’s limitations and adapt it to your context, you get insights that actually inform better decisions. When you follow it blindly, you get data that looks scientific but doesn’t reflect reality.

Have you ever perfectly followed a framework and ended up confused? I want to hear your story, drop it below ☺️

🚀 Hi! I’m Andreea, an academic HCI researcher (gesture recognition and virtual reality interfaces) turned UX researcher that helps various businesses build products users actually love. I conducted hundreds of research studies for tech companies seeking clarity and I started this newsletter to share real examples and stories from my experience, so teams can do better research.

If you found this article helpful, I would be super grateful if you shared it with others.

I also love great discussions and debates, so I’m excited to hear your thoughts in the comments.

Discussion about this post

Ready for more?