Conjoint analysis is a survey-based method for measuring how customers trade off between competing product features. Instead of asking "how important is price?" (everyone says "very"), you show respondents realistic combinations of features and watch which combinations they pick. The math then teases apart how much each feature contributed to the decision.

It's the standard tool for product feature prioritization, pricing studies, and concept testing.

When to use conjoint

Pricing decisions. What's the willingness-to-pay for adding feature X?
Feature prioritization. Of the 12 things engineering could build next quarter, which 4 actually move purchase intent?
Product configuration. What's the optimal default bundle?
Brand-feature trade-offs. How much brand premium do customers actually pay?
Concept testing. Which of these three product concepts wins, and why?

When not to use conjoint

Tiny attribute sets. With only 2–3 attributes, a simpler ranking question works.
Hypothetical features customers can't imagine. Conjoint assumes respondents can evaluate the trade-offs realistically. If the attribute is "an entirely new category they've never seen," you may need qualitative work first.
Sample sizes under ~150. Choice-based conjoint needs respondent counts to estimate utilities reliably.

Choice-based conjoint (CBC) — the standard

The most common form. Respondents see ~10–14 choice tasks, each presenting 3–4 product profiles. They pick the one they'd most likely buy. From the pattern of choices, the model estimates a "part-worth utility" for each level of each attribute.

Example tasks for a streaming service:

	Profile A	Profile B	Profile C
Library size	5,000 titles	50,000 titles	20,000 titles
4K	Yes	No	Yes
Ads	Ad-supported	Ad-free	Ad-free
Price	$5/mo	$15/mo	$10/mo

Repeat with shuffled profiles. Done well, you get utilities that say things like "removing ads is worth $4.20/month to the average customer, but $7.10 to the under-25 segment."

Attribute design — the part most people get wrong

The quality of conjoint output depends almost entirely on the attribute design.

3–6 attributes. More than 6 and respondents fatigue, less than 3 and you don't need conjoint.
2–5 levels per attribute. Price is the exception (often 4–6 levels).
Realistic combinations. Don't ask people to evaluate "$2 for the premium feature" if it's never going to be priced that way.
Balanced design. Each level should appear roughly equally often across tasks.

Sample size

Rule of thumb: ~300 completes for a national-population CBC, more if you need segment-level utilities. The Sample size calculator gives a ballpark. For tight subgroup utilities (e.g., "high-income, urban males"), aim for ~200 completes per subgroup.

How Tabular Pro runs conjoint

Native conjoint question type with attribute and level configuration
Automatic balanced design generation
Export utilities to Excel for stakeholders