Marketing research interpretation workshop / 5 MIN READ
Ask about a feature’s presence and absence before classifying it
Use a Kano study to investigate the pattern of response to a clearly defined feature, with a traceable interpretation.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-07
A feature category is only meaningful when participants understood the same capability in both versions of the question. Preserve the paired responses and their context before translating a classification into a roadmap.
What you will leave with: A Kano review brief covering feature definition, paired wording, classification evidence, audience differences and decision limits.
Use this when
- A product or service team wants to distinguish expected basics from attractive additions.
- A research report labels features must-have or delighter without showing how the labels were derived.
This is not a complete Kano scoring manual, a universal sample recommendation or proof that a feature will improve revenue or retention.
Define the feature at a usable level
Specify what the capability does, for whom and under which conditions. A feature described as “smart support” leaves participants to imagine very different services. A description such as a customer being able to see the status of an open repair is more concrete. Avoid including several independent benefits in one item when the team could build or remove them separately.
Prepare enough neutral context for people to understand the scenario. If a demonstration is needed, use the same version consistently and check that it does not advertise the desired answer. Ask a few participants to explain the capability before commissioning the full study. Record whether confusion comes from unfamiliar language, an unrealistic scenario or uncertainty about the underlying service.
Review both sides of the question together
Qualtrics describes Kano questionnaires using paired questions about having and not having a feature, with combined responses informing feature categories. This supports examining both judgments rather than assigning a label from a simple importance rating. The method’s categories summarize a research response pattern; they do not automatically specify a development order.
Have the researcher check that the two questions differ only in the intended feature state. “Helpful instant support” versus “slow unreliable support” changes several qualities and carries its own judgment. Decide what absence actually means: no capability, an alternative route or a reduced level. Make the distinction explicit and test how respondents understand it before interpreting the pair.
Preserve disagreement and ambiguous responses
Ask for the classification method, underlying response distribution and treatment of inconsistent or incomplete answers. A single winning label can hide substantial disagreement. Keep the research team responsible for the correct evaluation method rather than recreating a scoring table from a slide or silently discarding inconvenient responses.
Examine meaningful audience differences when the sample supports them. A capability expected by experienced users may be unfamiliar to newcomers. Do not invent a segment explanation after seeing a split; use follow-up evidence to understand it. If wording or comprehension problems are plausible, treat them as an unresolved design issue rather than calling the audience irrational.
Combine the classification with delivery judgment
Put customer evidence beside feasibility, operating cost, accessibility and any mandatory obligations. A low-excitement capability may still be essential to safe or dependable service. A highly attractive idea may be impossible to deliver honestly at the proposed price. Keep these decision inputs separate so a roadmap discussion can identify the real tradeoff.
Date the finding and record the market and product context. Expectations can change, and a feature description may no longer match the current implementation. Revisit the evidence when a material change occurs rather than treating a label as permanent. The useful outcome is a clearer explanation of the customer’s response, followed by a justified product decision with an owner and a way to learn from delivery.
Make the reasoning concrete.
A fictional service team labels “automatic updates” a delighter. Some respondents imagined useful progress notices; others imagined promotional messages they could not stop. The label is then used to approve a broad notification feature.
Build from the category alone
Opening: Treat the summary label as an unambiguous requirement.
Hypothesis: The roadmap receives a quick priority.
Risk: The feature being built may not match what respondents evaluated.
Resolve the feature meaning
Opening: Clarify the specific update, customer control and absence condition, then review the paired responses.
Hypothesis: The study can address one recognizable capability.
Risk: Further clarification or new fieldwork may be needed.
The team separates progress information from promotional messaging and tests the actual capability. It keeps mandatory customer controls outside any popularity-based decision.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
Feature
What single capability is being evaluated?
Absence
What exactly happens when that capability is unavailable?
Pair
Do the two questions change only the intended feature state?
Evidence
What distribution and uncertainty sit behind the category?
Decision
Which delivery, safety and cost considerations remain separate?
Watch for the wrong conclusion.
- Calling an importance rating a Kano classification.
- Using emotionally loaded wording in one half of the pair.
- Hiding substantial audience disagreement behind one label.
- Treating a delighter classification as proof of profitable demand.
Your next action
Read one feature’s presence and absence questions side by side and ask whether they describe the same capability under two states.
Sources & scope
Workflows, worksheets and hypothetical examples are original editorial analysis. Platform documentation supports only identified technical principles. No measured business result or named human reviewer is claimed.
- Qualtrics: Kano analysis, the Kano model explained →Primary research-software provider methodology guidance · Supports: Paired functional and dysfunctional feature questions and response-based categories. The review safeguards and roadmap decision process are original editorial analysis.