In short: Both methods force respondents into real trade-offs instead of rating scales on which everything ends up important. The difference lies in what is being studied: MaxDiff prioritises individual, self-contained items (features, messages, claims, benefits) and returns a clean ranking. Conjoint evaluates whole product concepts assembled from attributes and levels, and returns utilities, preference shares and willingness to pay. Rule of thumb: you have a list → MaxDiff. You have a configuration with a price → conjoint.
The problem both of them solve
Ask ten customers on a five-point scale how important faster support, a lower price, more features and better data protection are to them. You will get "very important" four times. That is not respondent carelessness, it is the logical answer to a question that costs nothing: on a rating scale, everything can be important at once.
In reality it cannot. In reality there is a budget, a roadmap and a finite amount of space on the packaging. Both methods build that scarcity into the question: respondents have to choose, and many small choices add up to a ranking that actually discriminates. The difference is what they choose between.
MaxDiff: ranking a list
In MaxDiff (maximum difference scaling, also known as best-worst scaling) each screen shows a small subset of your full list, typically four or five items, and you pick the most important and the least important one. The next set follows with a different combination, and so on across several choice sets.
Every set therefore carries more than one piece of information: the "best" item beats every other item in the set, the "worst" one loses to all of them. Across many sets and many respondents this produces a reliable scale for the entire list, including items that never appeared on the same screen.
What MaxDiff is for: feature prioritisation for the roadmap, selecting advertising messages and claims, ranking purchase motives or brand associations, prioritising assortment ideas. Whenever the items are independent of one another and you want to know which ones come out on top.
What DataLion computes from it: three estimation methods on the R engine: count (best minus worst, the simple subtraction), aggregate logit for stable overall scores and random-parameter logit for individual-level utilities per respondent. Those individual scores are what you need if you then want to build segments or check whether a message works in one target group and not in another. Details on the MaxDiff analysis page.
Conjoint: the value of single attributes inside the whole package
In choice-based conjoint (CBC) you do not see individual items but two to four complete product concepts side by side, each described by the same attributes at different levels, and you choose one. In other words, the situation in which a purchase decision actually happens.
A plan might be built from the attributes price (€29 / €49 / €79), contract term (monthly / 12 months), support (email / phone) and data storage (EU / worldwide). From the decisions across many such choice tasks, the model works backwards to determine how much each individual level contributed to the choice.
What conjoint is for: pricing and price steps, bundling and plan design, configuring product variants, simulating competitive scenarios. In other words, wherever attributes occur together and are traded off against each other, above all against price.
What DataLion computes from it: DataLion generates a balanced choice design from your attributes and levels, fields the choice tasks through the native survey and estimates the part-worth utilities in R (logit/MNL, aggregate or mixed – no hierarchical Bayes). You then pit concepts against each other in the preference simulator and read off the preference shares; if the design contains a price attribute, DataLion reports willingness to pay. The full workflow is described on the Conjoint & MaxDiff page.
The differences at a glance
| MaxDiff | Choice-based conjoint | |
|---|---|---|
| Object of study | Individual, independent items of a list | Attributes with levels, combined into concepts |
| Respondent task | Pick the best and worst item in the set | Pick one complete concept out of several |
| Result | Ranking and importance of the items | Utilities per level, attribute importances |
| Can price be modelled? | Only as a list item, without price-volume logic | Yes, as its own attribute with price steps |
| Simulation | No | Yes: preference shares, scenarios, willingness to pay |
| Typical list size | 15 to 40 items work well | 4 to 6 attributes with 2 to 5 levels each |
| Design effort | Low: word the list carefully | Higher: define the attribute space and the design |
| Length for respondents | Short, usually a few minutes | Longer, cognitively more demanding |
Which method when – four concrete cases
"Which five features do we build next?" → MaxDiff
You have 25 candidates from the backlog. They are independent, there is no price involved, and you need an order. Exactly the case MaxDiff was built for; with 25 items a conjoint design could not sensibly be constructed anyway. Starting point: our MaxDiff feature prioritisation template.
"What should the premium package cost and what goes into it?" → conjoint
Here everything is connected: the acceptable price changes with the scope of features, and the impact of a feature depends on what it costs. That can only be modelled jointly. Starting point: Conjoint product preferences.
"Which claim goes on the homepage?" → MaxDiff
Eight text variants, no price, no combinatorics. MaxDiff gives you the ranking, and the individual-level utilities also show whether a claim polarises within a target group, something a mean-based ranking would hide.
"What happens if a competitor cuts prices?" → conjoint
A what-if question about market shares. It needs a model in which concepts can be pitted against each other, i.e. the preference simulator. MaxDiff structurally cannot do this: it knows no competing products, only a list.
Special case: only the price matters
If all you want to know is willingness to pay for a fixed product, conjoint is overkill. Van Westendorp or a Gabor-Granger price test will do; both are set up in a quarter of an hour and are far less taxing for respondents.
Combining the two – the overlooked route
The question does not have to be either/or. A very efficient approach in practice runs in two stages:
- MaxDiff as the funnel. You start with 30 possible features or service components and have them prioritised. Result: a reliable ranking.
- Conjoint for the top end. The five or six strongest items become attributes of a conjoint design, plus price. Result: bundling, price steps and simulation.
The advantage is study economics: conjoint designs quickly become unusable if you force too many attributes into them: the number of required choice tasks rises and data quality drops, because at some point respondents are only guessing. Running MaxDiff first reduces the attribute space to a justified selection, instead of somebody deciding in a workshop which five attributes make it into the design.
Common mistakes in both methods
- MaxDiff with dependent items. If "mobile app" and "push notifications" both appear in the list, they compete with each other even though one is a precondition for the other. Items have to stand on their own.
- Mixing levels of abstraction. "Better support" and "a reply within two hours" in the same list bias the result systematically: the concrete item almost always wins.
- Too many attributes in the conjoint. Beyond roughly seven attributes the task turns into guesswork for most respondents. Fewer attributes and a clean design beat an overloaded one.
- Unrealistic levels. A price range far below real market prices produces utilities that look good in the simulator and mean nothing in reality.
- Reporting results without looking at segments. The overall ranking is often the compromise between two opposing target groups. Only a comparison across banner columns plus a significance test shows whether a difference holds.
Conclusion
MaxDiff answers "what matters most?", conjoint answers "what is it worth – and what will people choose if we build it like this and price it like that?". If you are unsure: look at whether your object of study is a list or a configuration. That decides the method more reliably than any rule of thumb about sample size.
In DataLion both methods run in the same system: fielded through the native survey, estimated on the R engine, results delivered as an interactive dashboard with PowerPoint export. If you want, start directly from a MaxDiff or conjoint template.
Run both on your own data: DataLion designs the choice tasks, fields them, estimates the utilities and turns them into a dashboard you can filter, GDPR-compliant and hosted in Germany. See Conjoint & MaxDiff in DataLion or try DataLion for free.