Objective Prioritisation: Kano

This is one of RoadmapOne’s articles on Objective Prioritisation frameworks .

The fatal mistake in product prioritisation isn’t choosing the wrong features—it’s choosing them in the wrong order. Teams chase delightful animations while critical workflows break. They build gamified sharing features while core functionality lags. They optimise for “wow moments” while customers churn because basics don’t work. Kano prioritisation solves this by sequencing features according to customer satisfaction psychology: Must-Haves first, Performance next, Delighters last. No matter how exciting your roadmap looks, if the fundamentals don’t work, nothing else matters.

Developed by Japanese quality researcher Noriaki Kano in 1984, the Kano Model categorises features based on how they affect customer satisfaction. But most teams use Kano wrong—they tag features by category and stop. Kano prioritisation takes the next step: it turns those categories into a priority sequence. Must-Haves are non-negotiable—ship without them and you have no viable product. Performance features scale satisfaction linearly—the better they work, the happier customers are. Delighters create disproportionate joy—but only after the basics function. The sequence is mandatory: basics, then performance, then delight. Reverse it and you build flashy products that frustrate users.

Sign up now to prioritise with Kano

The Three Kano Categories and What They Mean for Priority

Kano identifies three categories that directly impact prioritisation, plus two edge cases that rarely drive roadmap decisions.

Must-Haves (Basic Attributes): The Viability Threshold

Must-Have features are table stakes. Customers expect them. Their presence generates zero excitement—“of course the banking app shows my balance correctly.” But their absence generates rage. Miss a Must-Have and customers don’t just complain—they leave.

Must-Haves define product viability. A messaging app without message delivery is not an MVP—it’s a prototype. An e-commerce site without checkout isn’t minimal—it’s broken. A SaaS tool without login isn’t “focused”—it’s non-functional. If you ship without Must-Haves, you haven’t shipped a product; you’ve released a demo.

The prioritisation rule is absolute: Must-Haves come first, always. No exceptions. No “we’ll add security later.” No “login can wait until v2.” No “let’s launch with the exciting stuff and fix basics post-launch.” Must-Haves are the viability line. Cross it or don’t ship.

The trap is assuming you know what Must-Haves are without research. Product teams project their assumptions onto customers. “Obviously they need X” often means “I assume they need X.” Run customer surveys, interview churned users, analyse support tickets. Must-Haves reveal themselves through pain—customers don’t compliment their presence, but they churn over their absence.

Performance Features (One-Dimensional Attributes): Linear Satisfaction

Performance features scale linearly with investment. Faster load times increase satisfaction proportionally. More accurate search results improve experience incrementally. Broader integration coverage adds value per integration. More is better; less is worse.

Performance features sit between Must-Haves and Delighters in priority. You need some level of performance to be viable—a search engine that takes 30 seconds per query isn’t minimally viable. But once you’re over the viability bar, Performance improvements compete with Delighters for attention.

Kano prioritisation says: fund Performance features after Must-Haves are solid, and balance them with Delighters. Don’t optimise dashboard load time from 2 seconds to 0.5 seconds while Must-Have data accuracy sits at 85%. But once Must-Haves hit acceptable thresholds, Performance investments compound—each improvement lifts satisfaction measurably.

The discipline is avoiding Performance theatre. Teams obsess over micro-optimisations—shaving 50ms off API response time—while ignoring that the API returns wrong data 5% of the time. Performance matters, but only after correctness (a Must-Have) is achieved.

Delighters (Excitement Attributes): Disproportionate Joy

Delighters are unexpected features that create outsized delight. Customers didn’t ask for them. They don’t expect them. But when they encounter them, satisfaction spikes. Confetti animations on goal completion. A hand-written thank-you note in the first shipment. Dark mode before competitors offered it.

Delighters have non-linear impact: small investments yield disproportionate happiness. But Delighters also have a critical prerequisite: they only work after Must-Haves and Performance are solid. A beautifully animated onboarding flow doesn’t compensate for broken core functionality. Gamified badges don’t offset slow load times. Surprise and delight features are icing—delicious, but only on top of an actual cake.

Kano prioritisation ranks Delighters last—not because they’re unimportant, but because they depend on everything else working. Ship Delighters before basics and you’ve built a flashy disaster. Ship them after basics work and you create customer love.

The danger is Delighter addiction. Teams love building them—they’re fun, creative, low-risk. Executives love demoing them—they look impressive in presentations. But Delighters without solid foundations are lipstick on a pig. Kano forces honesty: Are your Must-Haves green? Are your Performance metrics hitting targets? If not, park the Delighters until they are.

Edge Cases: Indifferent and Reverse

Two additional Kano categories rarely drive prioritisation but worth understanding.

Indifferent features: Customers don’t care whether you have them or not. Adding them doesn’t increase satisfaction; removing them doesn’t hurt. These should be ruthlessly cut—they consume development capacity for zero satisfaction gain.

Reverse features: Features that actually reduce satisfaction. Microsoft Clippy is the canonical example—a “helpful” assistant that annoyed users so much its removal was celebrated. Reverse features are prioritisation traps: teams build them thinking they’re Delighters, but customers hate them. The fix is validation: test before shipping, and kill Reverse features fast.

Kano as Tagging vs Kano as Prioritisation

Kano appears twice in RoadmapOne’s framework toolkit: once as an objective tagging method , once as a prioritisation framework. Understanding the difference is critical.

Kano tagging categorises features by satisfaction type. You tag objectives as Must-Have, Performance, or Delighter to analyse portfolio balance. The question is: “Are we spending 80% of capacity on Delighters while Must-Have SLAs are red?” Tagging enables retrospective analysis—it shows how you spent resources.

Kano prioritisation sequences features by category. You rank Must-Haves first, Performance second, Delighters third, and fund in that order. The question is: “What should we build next?” Prioritisation enables prospective decisions—it determines what gets funded.

The two approaches complement each other. Use Kano tagging to diagnose portfolio imbalance. Use Kano prioritisation to enforce sequence discipline. If your tag analysis shows you’re starving Must-Haves for Delighters, Kano prioritisation fixes it by rejecting Delighter funding until Must-Haves hit target SLAs.

Kano Prioritisation in Action: Three Scenarios

Scenario A: Consumer Fitness App—Basics vs Delight

You’re building a fitness tracking app. Your backlog includes:

Feature 1: Activity Tracking Accuracy (Must-Have)

• Current state: Step counting accuracy is 75% (off by 25% compared to benchmark devices)
• Category: Must-Have
• Impact: Customers complain in reviews; churn among serious users is 12%
• Kano Priority: Rank 1 (Fix immediately—viability issue)

Feature 2: Social Sharing with Animations (Delighter)

• Allows users to share workout achievements with confetti animation
• Category: Delighter
• Impact: High engagement in demos; execs love it
• Kano Priority: Rank 3 (Park until basics work)

Feature 3: Workout Intensity Graphs (Performance)

• More detailed graphs improve workout insights incrementally
• Category: Performance
• Impact: Moderate satisfaction lift; requested by 30% of users
• Kano Priority: Rank 2 (After accuracy fixed, before animations)

Kano decision: Fund Feature 1 first—accuracy is a Must-Have; 75% accuracy means the product isn’t viable for serious users. Feature 3 ranks second—once tracking works, better insights scale satisfaction. Feature 3 ranks last—confetti is delightful, but shipping it while core tracking is broken creates a flashy toy, not a fitness tool.

Real outcome: Team deprioritised social sharing, fixed accuracy to 95%, launched intensity graphs. Churn dropped to 4%, NPS rose from 38 to 52. Social sharing shipped three months later as a reward for loyal users—by then, the product deserved delight features.

Scenario B: B2B SaaS Dashboard—Enterprise Must-Haves

You’re a B2B analytics SaaS. Enterprise customers are demanding features:

Feature 1: Single Sign-On (SSO) (Must-Have)

• Category: Must-Have (for enterprise buyers, not SMBs)
• Three £200k ARR customers blocked on renewals without SSO
• Kano Priority: Rank 1 (Viability for enterprise segment)

Feature 2: Customisable Report Scheduling (Performance)

• Category: Performance
• Better scheduling options improve user efficiency
• Requested by 40% of paying customers
• Kano Priority: Rank 2 (Improves satisfaction after SSO unblocks revenue)

Feature 3: AI-Powered Insights with Animated Reveals (Delighter)

• Category: Delighter (AI insights are Performance, animations are Delighter)
• Looks impressive in sales demos
• Kano Priority: Rank 3 (Delight after basics and performance)

Kano decision: SSO ranks first—it’s a Must-Have for the enterprise segment (even though SMBs don’t care). Without SSO, you can’t renew £600k ARR. Report scheduling ranks second—it’s linear satisfaction improvement. AI insights rank third, with animations deferred until the first two ship.

Strategic note: Kano categories are segment-specific. SSO is a Must-Have for enterprises, Indifferent for SMBs. Kano prioritisation requires defining “for whom”—enterprise Kano priorities differ from SMB priorities.

Scenario C: E-Commerce Platform—When Delighters Decay

You’re running an e-commerce platform. Features in question:

Feature 1: One-Click Checkout (Must-Have as of 2025)

• Category: Was a Delighter in 2015 (Amazon innovation), now Must-Have in 2025
• Customers expect it; absence increases cart abandonment by 18%
• Kano Priority: Rank 1 (Kano drift turned this into viability feature)

Feature 2: Real-Time Inventory Sync (Performance)

• Category: Performance
• More accurate inventory reduces customer frustration over out-of-stock surprises
• Kano Priority: Rank 2 (After checkout basics work)

Feature 3: Personalised Product Recommendations (Delighter/Performance)

• Category: Moving from Delighter to Performance (common in 2025)
• Increases basket size by 15%
• Kano Priority: Rank 3 (Nice to have after core commerce works)

Kano lesson: Features migrate categories over time. One-click checkout was a Delighter when Amazon pioneered it. By 2025, it’s a Must-Have—customers expect it. Kano prioritisation requires periodic recategorisation: yesterday’s Delighter is today’s Must-Have. Teams that don’t update categories end up treating Must-Haves as optional.

When Kano Is Your Best Weapon

Kano prioritisation excels in four contexts.

First: Consumer products competing on experience. When customer satisfaction drives retention and word-of-mouth growth, Kano prioritisation prevents teams from chasing delight while basics break. Consumer apps, B2C SaaS, e-commerce platforms—anywhere churn is voluntary and driven by satisfaction.

Second: Post-launch optimisation. When you have usage data, support tickets, and churn analysis, Kano categorisation becomes evidence-based. You can identify Must-Haves from churn patterns, Performance features from satisfaction surveys, and Delighters from viral moments. Kano shines when you have customer feedback to validate categories.

Third: Balancing engineering excitement with user needs. Engineers love building Delighters—they’re novel, creative, fun. Executives love demoing them. Kano provides a forcing function: show me the Must-Have SLAs are green before you fund that animation. It’s not “no” to Delighters—it’s “yes, after basics work.”

Fourth: Preventing feature bloat. Kano’s Indifferent category gives teams permission to cut. If research shows a feature is Indifferent—customers don’t care either way—delete it from the roadmap. Kano prevents “just in case” features that consume capacity for zero satisfaction gain.

When Kano Betrays You

Kano collapses in three scenarios.

First: When Must-Haves are invisible. Customers don’t articulate Must-Haves in surveys—they assume them. Nobody says “I need the app to not crash” because they expect that. Kano surveys ask functional and dysfunctional questions (“How would you feel if this feature existed? How would you feel if it didn’t?”), but customers struggle to imagine absence of things they take for granted. The fix is looking at churn data and complaints, not just surveys.

Second: When B2B contracts override satisfaction. In enterprise SaaS, contracts often demand specific features regardless of Kano category. If a £500k customer’s contract requires SCIM provisioning, it’s getting built—even if it’s a Must-Have for one customer and Indifferent for everyone else. Kano prioritisation assumes you optimise for broad satisfaction; enterprise deals often optimise for specific accounts.

Third: When feature drift outpaces recategorisation. Delighters decay into Performance features, then into Must-Haves, as competitors copy them and customer expectations rise. Dark mode was a Delighter in 2018; by 2025 it’s a Must-Have for many segments. Teams using outdated Kano categories misprioritise—they think they’re funding a Delighter when it’s actually a Must-Have. The cure is annual recategorisation: survey customers, analyse churn, and update categories.

Practical Implementation: From Survey to Roadmap

Step 1: Conduct Kano Surveys

Use functional/dysfunctional question pairs for each feature:

• Functional: “How would you feel if this feature existed?”
• Dysfunctional: “How would you feel if this feature didn’t exist?”

Answers map to categories: Must-Have (neutral if present, frustrated if absent), Performance (satisfied if present, dissatisfied if absent), Delighter (delighted if present, neutral if absent).

Survey 50-100 customers per segment. B2C and B2B may have wildly different Kano maps.

Step 2: Categorise Features

Analyse survey results to tag features by dominant category. If 70% of respondents show Must-Have patterns, tag it Must-Have. If responses split between Performance and Delighter, tag Performance (the more conservative priority).

Validate categories against churn data. If customers churn citing a feature’s absence, it’s a Must-Have regardless of survey responses.

Step 3: Set SLA Thresholds for Must-Haves

Define minimum acceptable performance for Must-Haves. Accuracy >95%. Uptime >99.5%. Core workflow success rate >98%. These thresholds define viability. Below them, the product isn’t shippable.

Step 4: Enforce Priority Sequence

Rank objectives:

1. Must-Haves below SLA threshold (viability failures)
2. Must-Haves at risk of falling below SLA (preventive maintenance)
3. Performance features (linear satisfaction improvement)
4. Delighters (only if Must-Have SLAs are green)

Draw the capacity line. If Must-Haves consume 100% of capacity, Delighters wait. This is Kano forcing discipline: basics before delight.

Step 5: Reserve Delighter Budget

Once Must-Haves stabilise, allocate 10-20% of capacity to Delighters. This prevents Delighter starvation—you need some joy to create love, not just functionality. But guard-rail it: if any Must-Have SLA drops to red, Delighter budget gets reallocated immediately.

Step 6: Recategorise Annually

Schedule quarterly or annual Kano surveys. Features drift categories. Yesterday’s Delighter is today’s Performance or Must-Have. Update tags, reprioritise, and ensure your roadmap reflects current customer expectations, not 2-year-old assumptions.

Kano and Strategic Balance

Kano prioritisation is a sequencing tool, not a portfolio strategy. Use it to enforce “basics before delight,” but overlay strategic filters. If your portfolio is 90% Must-Haves with zero Delighters, you’re shipping functional but unloved products. Kano says Must-Haves first, but mature products with solid foundations should fund Delighters to create differentiation.

RoadmapOne supports Kano-driven prioritisation by integrating Kano tagging with priority sequencing. Tag objectives by Kano category, set SLA thresholds for Must-Haves, and enforce priority order. The roadmap won’t let you fund Delighters while Must-Have SLAs are red—unless you explicitly override, acknowledging the trade-off.

The Uncomfortable Truth About Basics

The reason teams avoid Kano prioritisation isn’t ignorance—it’s that Kano forces uncomfortable prioritisation. Delighters are fun to build and impressive to demo. Must-Haves are boring infrastructure work that executives don’t celebrate. Kano says the boring work comes first. Always.

This is why consumer apps with flashy features and broken basics fail. This is why enterprise SaaS loses renewals despite impressive roadmaps. This is why startups with “delightful UX” and 30% crash rates don’t achieve product-market fit. Delight without viability is theatre. Kano prevents it.

If you take only three ideas from this essay, let them be:

1. Must-Haves Define Viability; Everything Else Is Enhancement. Kano’s iron law: ship Must-Haves first or don’t ship at all. No animations before accuracy. No gamification before reliability. No delight before basics work. This isn’t negotiable—it’s the definition of a viable product.

2. Delighters Only Delight After Basics Work. Confetti animations don’t compensate for broken workflows. Surprise features don’t offset missing fundamentals. Kano prioritisation ranks Delighters last—not because they’re unimportant, but because they depend on solid foundations. Build the cake before adding icing.

3. Features Drift Categories; Recategorise or Misprioritise. Yesterday’s Delighter is today’s Must-Have. One-click checkout, dark mode, real-time collaboration—all started as innovations, all became expected. Kano categories decay over time as competitors copy and customer expectations rise. Update your Kano map annually or you’ll fund “innovations” that are actually table stakes.

RoadmapOne enforces Kano-driven sequencing because the market punishes teams that ship delight before viability. Use Kano to prevent Delighter addiction, enforce basics-first discipline, and build products customers love—but only after you’ve built products that actually work.

Kano prioritisation won’t make your roadmap exciting. It’ll make it viable. And viable beats flashy every single time.

For more on Objective Prioritisation frameworks, see our comprehensive guide .