Conjoint Analysis: What Do Customers Actually Trade Off?

Your product team wants to add premium support, extended analytics, and API access to your SaaS platform. Development cost: $150,000. Marketing insists all three features are "must-haves" because customers mentioned them in interviews. Here's the problem: when you ask customers what they want, they say everything. When you force them to choose between features at different price points, you discover premium support is worth $45/month, extended analytics is worth $8/month, and API access actually decreases willingness to pay by $12/month because it signals complexity.

This is what conjoint analysis does. Before you spend six months building features nobody will pay for, run an experiment that forces real trade-offs. A $2,000 conjoint study can save $150,000 in wasted development. Let's set up the experiment properly.

The $150K Mistake Conjoint Analysis Prevents

A B2B analytics company ran focus groups and heard consistent feedback: "We need more integrations." They spent nine months building integrations with 15 platforms. Adoption rate: 8%. Customers had confused "nice to have" with "willing to pay for."

Before the next product cycle, they ran a conjoint study with 300 customers. The design tested:

• Integrations: 5 platforms vs 15 platforms vs 25 platforms
• Data refresh rate: Daily vs Hourly vs Real-time
• Historical data: 90 days vs 1 year vs 3 years
• Price: $99/month vs $149/month vs $199/month vs $299/month

The results surprised everyone. Part-worth utilities (the relative value customers assign to each feature level):

• Real-time data refresh: +$67/month in willingness to pay
• 3-year historical data: +$42/month
• 25 integrations vs 15 integrations: +$3/month (not significant)

They killed the integrations roadmap and built real-time refresh instead. Revenue per customer increased 34% and development costs dropped by half. This is the ROI of proper experimental design in product development: test preferences before you test code.

How Conjoint Analysis Actually Works

Conjoint analysis decomposes overall preferences into part-worth utilities for each attribute level. Instead of asking "Do you like Product A?" you show respondents multiple product profiles and ask them to choose or rate. From their choices, you back-calculate how much value they assign to each feature.

The experimental design requires three components:

1. Attribute Selection (3-6 Attributes Maximum)

Choose attributes customers actually trade off in purchase decisions. Common mistake: including attributes that are hygiene factors (everyone expects them) or attributes customers can't meaningfully evaluate.

Good attributes for a CRM system:

• Number of users included (5 / 20 / Unlimited)
• Email automation (Basic / Advanced / AI-powered)
• Support level (Email / Chat / Dedicated rep)
• Price ($49 / $99 / $149 / $249 per month)

Bad attributes:

• Security (everyone wants maximum security — no trade-off)
• Uptime guarantee (99.9% vs 99.99% — customers can't evaluate this meaningfully)
• Number of API calls (too technical for most buyers to value accurately)

2. Level Selection (2-4 Levels Per Attribute)

Levels must be realistic, distinguishable, and span the plausible range. For price, include your current price, a realistic lower bound, and a realistic upper bound. Don't test $10/month vs $1,000/month — nobody believes that choice.

The range matters for part-worth calculation. If you test support levels of "Email" vs "Email + Chat" vs "Email + Chat + Phone," you're estimating marginal value of each channel. If you test "Email" vs "White-glove concierge," you can't decompose which elements drive the preference.

3. Profile Generation (Fractional Factorial Design)

With 4 attributes × 3 levels each, you have 81 possible product configurations. You can't show respondents all 81 profiles — survey fatigue destroys data quality after 10-12 tasks.

Use a fractional factorial design to select a balanced subset. The design ensures:

• Each level appears equally often (orthogonality)
• Attributes aren't correlated (you can separate the effect of price from the effect of features)
• Sufficient variation to estimate all main effects

Standard software generates these designs automatically. For a 4-attribute study, you typically need 12-16 profiles. Show each respondent 8-12 profiles in randomized order.

Choice-Based vs Ratings-Based: Pick the Right Method

Two dominant conjoint methodologies exist. Your choice affects data quality, analysis complexity, and how well results predict actual behavior.

Choice-Based Conjoint (CBC)

Show respondents 3-4 product profiles per task and ask "Which would you buy?" Optionally include a "none" option to measure baseline demand.

Advantages:

• Mimics real purchase decisions (you don't rate products in a store, you choose one)
• Handles price more realistically (price interacts with features in choice contexts)
• Forces trade-offs (you can't choose all of them)
• Less susceptible to response bias (harder to game or "look good")

Disadvantages:

• Requires 1.5-2× the sample size of ratings-based (choice data has less information per task)
• More complex analysis (multinomial logit models vs OLS regression)
• Longer survey time (need 12-15 choice tasks vs 8-10 rating tasks)

Ratings-Based Conjoint

Show respondents one product profile at a time and ask "How likely are you to purchase this on a scale of 1-9?"

Advantages:

• Smaller sample size required (200 respondents vs 300+ for CBC)
• Simpler analysis (OLS regression gives you part-worths directly)
• Faster fielding (8 rating tasks vs 15 choice tasks)

Disadvantages:

• Scale usage bias (some respondents only use 5-7, others use 1-9)
• Less realistic (nobody rates products in real life, they choose)
• Price effects less accurate (rating high price profiles low doesn't reveal willingness to pay)

When to use which: For pricing studies and final product configuration decisions, use choice-based conjoint. For early-stage exploration with 5-6 attributes or when budget limits sample size, ratings-based works. If you're testing whether to build a feature at all, CBC gives you a clearer answer. If you're exploring which variations of a feature resonate, ratings-based is sufficient.

Sample Size: Calculate Before You Field

Here's what happens when you run a conjoint study with 100 respondents: your part-worth estimates have confidence intervals wider than the effects you're trying to measure. You can't tell if premium support is worth $40/month or $10/month.

Minimum sample sizes for stable part-worth estimates:

• Ratings-based conjoint: 200 respondents minimum for aggregate analysis
• Choice-based conjoint: 300 respondents minimum
• Segmented analysis: Add 100-150 respondents per additional segment

The calculation depends on:

• Number of attributes and levels (more levels = more parameters to estimate)
• Expected effect size (small differences in part-worths need larger samples)
• Desired precision (do you need to distinguish $40 from $45, or $40 from $20?)

For a typical 4-attribute × 3-level choice-based study, 300 respondents gives you standard errors around ±$5-8 for part-worth estimates. If your features differ by less than $10 in value, you need 500+ respondents to detect the difference reliably.

Analyzing Part-Worth Utilities: What the Numbers Mean

After you collect responses, regression analysis decomposes overall preferences into part-worth utilities for each attribute level. For ratings-based conjoint, run OLS regression with dummy variables for each level. For choice-based conjoint, use multinomial logit or hierarchical Bayes models.

Example output from a SaaS pricing study (choice-based conjoint, 350 respondents):

Attribute: User Licenses
  5 users:       -$23  (baseline = 0)
  20 users:       $18
  Unlimited:      $47

Attribute: Support Level
  Email only:    -$15
  Email + Chat:    $8
  Dedicated rep:  $52

Attribute: Data History
  90 days:       -$12
  1 year:          $9
  3 years:        $31

Attribute: Price
  $99/month:      $67
  $149/month:     $18
  $199/month:    -$28
  $299/month:    -$71

How to interpret these numbers:

Part-worth utilities are relative. A part-worth of +$47 for "Unlimited users" means customers value unlimited users $47/month more than the baseline (5 users at -$23). The absolute numbers within an attribute sum to approximately zero — it's the differences that matter.

Cross-attribute comparisons reveal trade-offs. Unlimited users (+$47) is valued almost the same as a dedicated support rep (+$52). If adding unlimited users costs $15/month in server costs but a dedicated rep costs $80/month in labor, the ROI calculation is clear: give them unlimited users.

Price part-worths convert to willingness to pay. The steep drop from $149 (+$18) to $199 (-$28) suggests the optimal price point is around $150-160/month. Above $200, you lose customers faster than revenue increases.

Negative part-worths aren't bad features. "Email only" support has a part-worth of -$15, but that doesn't mean you should remove email support. It means customers prefer chat or dedicated reps if price is equal. If email-only support lets you charge $99 instead of $149, customers might still choose it.

Market Simulation: Which Product Wins?

Part-worth utilities let you simulate market share for different product configurations. Add up the part-worths for each attribute level, apply a choice model, and predict which percentage of customers choose each product.

Example simulation using the SaaS utilities above:

Product A: 20 users + Email/Chat + 1 year history + $149/month
Utility = $18 + $8 + $9 + $18 = $53

Product B: Unlimited users + Dedicated rep + 3 years + $299/month
Utility = $47 + $52 + $31 - $71 = $59

Product C: Unlimited users + Email/Chat + 1 year + $199/month
Utility = $47 + $8 + $9 - $28 = $36

In a choice model, Product B captures the highest share despite the $299 price point because the combination of unlimited users, dedicated support, and extended history creates $130 in value ($59 utility at $299 price vs $53 utility at $149 price). Product C, the "premium features at mid-tier price" offering, loses to both — customers who want unlimited users will pay for dedicated support, and customers optimizing for price will take Product A.

This is the strategic value of conjoint analysis in product development: you can test configurations before you build them. Marketing wanted Product C. The data says it loses.

ROI Calculation: When Does Conjoint Pay for Itself?

A properly fielded conjoint study costs $2,000-$5,000 for 300 respondents (survey platform + incentives + design time). The ROI case is simple: does it prevent one bad product decision?

Scenario 1: Feature Prioritization

You have budget to build two of four proposed features. Each feature costs $80,000 in development. Building the wrong two features means $160,000 spent on low-value additions while high-value features wait another quarter.

Conjoint study results:

• Advanced reporting: +$38/month willingness to pay
• Mobile app: +$22/month
• Custom branding: +$6/month
• Workflow automation: +$51/month

Build workflow automation and advanced reporting. Expected revenue increase: $89/customer/month. With 400 customers, that's $35,600/month or $427,200 annually. The conjoint study cost $3,500. ROI: 122× in year one.

Scenario 2: Pricing Strategy

Your product team believes you should charge $199/month for the premium tier. Marketing believes $249 is feasible. Sales wants to test $279. Each $50 difference is $600/year per customer.

Conjoint analysis with price as an attribute reveals:

• At $199: 34% of respondents choose premium tier
• At $249: 28% choose premium tier
• At $279: 19% choose premium tier

With 1,000 total customers:

• $199 pricing: 340 premium customers × $2,388/year = $811,920
• $249 pricing: 280 premium customers × $2,988/year = $836,640
• $279 pricing: 190 premium customers × $3,348/year = $636,120

The $249 price point generates $24,720 more annual revenue than $199 and $200,520 more than $279. A pricing A/B test would take 3-6 months to reach significance and would leave revenue on the table during the test period. The conjoint study gave you the answer in two weeks for $4,200.

Scenario 3: Avoiding Development Waste

The most valuable ROI is the money you don't spend. An enterprise software company planned to build a complex admin dashboard for multi-user management. Estimated cost: $220,000 over 8 months. Marketing insisted it was a must-have for enterprise sales.

Conjoint analysis among 400 enterprise decision-makers showed the admin dashboard had a part-worth utility of +$3/month — essentially zero. What enterprise customers actually valued:

• SOC 2 compliance: +$73/month
• SSO integration: +$48/month
• Dedicated support: +$67/month
• Admin dashboard: +$3/month

They killed the dashboard project and fast-tracked SOC 2 compliance. Cost saved: $220,000. Revenue impact from SOC 2: 43% increase in enterprise deal closure rate. The $5,000 conjoint study saved $220,000 in wasted development and unlocked $1.2M in annual revenue from enterprise upgrades.

Common Mistakes That Destroy Conjoint Validity

Most conjoint studies fail not because the math is wrong but because the experimental design is flawed. Here are the errors that make your $5,000 study worthless:

Mistake 1: Too Many Attributes

You want to test 8 different features, 3 service levels, 2 contract lengths, and 5 price points. That's 12 attributes. Respondents mentally check out after the 4th choice task and start clicking randomly.

The data looks fine — you get part-worth utilities for all 12 attributes. But the standard errors are massive and the results don't replicate. What happened? Cognitive overload. Respondents can't meaningfully evaluate 12-dimensional trade-offs.

Fix: Limit to 4-6 attributes maximum. If you have more, run multiple studies or use hierarchical conjoint (screen attributes in phase 1, deep-dive on top performers in phase 2).

Mistake 2: Unrealistic or Unbelievable Levels

Testing price points of $10, $50, $100, and $500 when your current price is $99. Respondents know something is wrong. They assume the $10 option is a trial or has hidden costs. They assume the $500 option includes features you didn't list. The choice behavior doesn't reflect real preferences.

Fix: Keep price variation within 3-4× range. Test $79, $99, $129, $159 if your current price is $99. For features, only include levels that could plausibly launch in the next 12 months.

Mistake 3: Non-Randomized Respondent Assignment

You send the conjoint survey to your email list. 83% of respondents are existing customers. They already chose your product once, which means they systematically overvalue the attributes you currently offer and undervalue the attributes competitors offer.

Your conjoint study says customers love your current feature set and don't care about the integrations your competitor just launched. Meanwhile, you're losing deals to that competitor. The sample was biased.

Fix: Recruit respondents who match your target market, not just your current customer base. If you're testing features for enterprise sales, survey enterprise buyers, not SMB customers who might upgrade someday. Did you randomize? Check your sample demographics against your target market before you trust the results.

Mistake 4: Ignoring the "None" Option

Choice-based conjoint shows 3 product configurations per task. Respondents must pick one. But in real markets, customers can choose not to buy. Forcing a choice inflates willingness to pay because you've eliminated the outside option.

Your conjoint study says 72% of respondents prefer the $249 premium tier. You launch it and get 11% uptake. What happened? In the study, they had to choose something. In real life, they chose "wait" or "competitor" or "free trial extension."

Fix: Include a "none of these" option in each choice task. This calibrates your market simulation to reality. It will reduce predicted market share by 30-50%, but those predictions will be accurate instead of optimistic.

Mistake 5: Survey Fatigue and Straight-Lining

You designed 20 choice tasks to maximize statistical power. Respondents mentally check out at task 12 and start picking the first option every time. Your data shows a strong left-side bias. The part-worth utilities are nonsense.

Fix: Limit to 8-12 choice tasks for CBC, 8-10 rating tasks for ratings-based. Monitor response times — if median time per task drops below 4 seconds, respondents aren't reading. Better to get clean data from 10 tasks than noisy data from 20.

Limitations: What Conjoint Can't Tell You

Conjoint analysis measures stated preferences in a controlled experiment. It doesn't measure actual purchase behavior in chaotic markets. Here's what it can't do:

Limitation 1: Stated vs Revealed Preference Gap

Respondents say they'd pay $45/month for premium support. When you launch premium support at $45/month, 38% of those respondents don't upgrade. The stated preference was real — they do value premium support at $45 — but revealed preference includes factors conjoint doesn't capture: switching costs, budget approval processes, inertia, competing priorities.

The gap between stated and revealed preference is typically 20-40% for B2B purchases and 30-50% for consumer purchases. Use conjoint for relative rankings and trade-offs, not absolute demand forecasting.

Solution: Calibrate conjoint results with actual behavior data when possible. Run a small-scale A/B test to validate pricing or feature preferences before full rollout. Use conjoint to narrow options, then test finalists experimentally.

Limitation 2: Context Effects and Framing

Conjoint studies present product profiles in isolation. Real purchase decisions happen in context: competitor offerings, sales conversations, peer recommendations, economic conditions, recent news.

Your conjoint study says customers value "AI-powered insights" at +$31/month. Three weeks after launch, a competitor's AI tool makes a major error that gets press coverage. Suddenly "AI-powered" is a liability, not an asset. The conjoint study wasn't wrong — the market context changed.

Solution: Re-run conjoint studies every 12-18 months. Preferences shift as markets mature, competitors innovate, and customer sophistication increases. A 2024 conjoint study on data privacy features will give different results than the same study in 2026.

Limitation 3: Innovation and Category Creation

Conjoint analysis tests trade-offs between known attributes. It doesn't identify breakthrough innovations customers can't imagine yet. If you ran a conjoint study on smartphones in 2006, it wouldn't have revealed that customers wanted a touchscreen with no keyboard — they'd never used one.

For incremental improvements and feature prioritization, conjoint works brilliantly. For category-creating innovation, you need different tools: prototype testing, qualitative research, visionary bets.

Solution: Use conjoint to optimize within an existing product category. Use ethnography, prototype testing, and small-scale experiments to explore category-creating innovation. Don't ask customers to rate features they've never experienced.

Segmentation: When Averages Lie

Aggregate part-worth utilities hide critical variation. Your study shows "Advanced analytics: +$18/month" on average. But that average combines two segments:

• Data-driven organizations: +$74/month (34% of sample)
• Casual users: -$8/month (66% of sample)

If you price advanced analytics at $18/month, you undercharge the segment that values it and confuse the segment that doesn't. You need two product tiers or targeted positioning.

Standard segmentation approaches:

A Priori Segmentation

Collect demographic or firmographic data (company size, industry, role, usage frequency) and analyze part-worths separately for each segment. This works when you know the relevant segmentation variable before the study.

Example: SaaS company segments by company size. Small businesses (1-20 employees) value ease of use and low price. Enterprises (500+ employees) value integrations and compliance. Mid-market (50-500 employees) falls in between. You design three product tiers optimized for each segment's part-worth utilities.

Latent Class Segmentation

Let the conjoint data reveal segments. Latent class analysis clusters respondents based on similar part-worth patterns. You discover segments you didn't know existed.

Example: B2B software study reveals three segments that don't align with company size or industry:

• Feature maximizers (28%): High part-worths for every advanced feature, price-insensitive
• Value seekers (51%): High price sensitivity, only value features that directly save time
• Support-dependent buyers (21%): High part-worths for support and training, moderate feature needs

This segmentation reshapes your entire go-to-market strategy. Feature maximizers need proof of depth (integrations, customization, API). Value seekers need ROI calculators and case studies. Support-dependent buyers need customer success stories and service guarantees.

Validation: How Do You Know the Results Are Real?

You've run the study, calculated part-worths, and simulated market share. Before you commit $500K to product development based on these results, validate the findings.

Internal Validation Checks

Holdout tasks: Include 2-3 extra choice tasks that weren't used to estimate part-worths. Predict how respondents will answer these tasks using the estimated utilities. If hit rate is below 50%, your model doesn't predict well.

Logical consistency: Do higher prices have negative part-worths? Do "premium" features have positive part-worths? If your model says customers prefer higher prices, something is wrong (probably correlated attributes in the design).

Segment stability: Run latent class analysis with different starting seeds. Do you get the same segments? If segment membership changes drastically with different random starts, the segments aren't robust.

External Validation

The gold standard: test conjoint predictions against actual behavior.

A/B test pricing: Conjoint says optimal price is $149. Run an A/B test with $149 vs current $129 pricing. Does conversion rate match the conjoint prediction?

Launch and measure: Conjoint says Feature A will increase willingness to pay by $23/month. Launch Feature A and measure actual upgrade rate and revenue impact. Did it deliver?

Competitive benchmarking: Conjoint says your product should capture 34% market share against competitors B and C. Does your actual market share match? If you're at 18%, either the sample was biased or revealed preference differs from stated preference.

One e-commerce company runs quarterly conjoint studies on product attributes (shipping speed, return policy, product range, price). They validate results by comparing predicted market share to actual sales data for similar product configurations. Over 24 months, their conjoint predictions had a mean absolute error of 4.2 percentage points — close enough to guide product decisions, but not precise enough for financial forecasting.

When to Use Conjoint Analysis vs Other Methods

Conjoint analysis isn't the right tool for every question. Here's when it works and when to use alternatives:

Use Conjoint When:

• You need to understand trade-offs between 3-6 product attributes
• Pricing decisions require understanding willingness to pay for feature bundles
• Feature prioritization needs quantitative backing for roadmap decisions
• Multiple stakeholders disagree on what customers value (conjoint settles the debate with data)
• You're designing product tiers and need to optimize configurations

Use A/B Testing When:

• You want to measure actual behavior, not stated preferences
• The decision is binary (one feature on vs off) and you can run a live test
• You have sufficient traffic to reach significance in 2-4 weeks
• Real-world context effects matter (competitor actions, seasonal demand, etc.)

Comparison: Conjoint tells you what customers value and by how much. A/B tests tell you whether a change increases your target metric. Use conjoint for exploration and prioritization. Use A/B tests for validation and optimization. For more on experimental design and hypothesis testing, see our guide to CSV analysis workflows and systematic analysis design.

Use MaxDiff When:

• You have 8-15 items to rank (too many for conjoint)
• You need importance rankings, not trade-offs with price
• Cognitive load is a concern (MaxDiff tasks are simpler than conjoint)

Comparison: MaxDiff asks "Which of these 4 features is most important and which is least important?" repeatedly until you have a ranking. It doesn't measure willingness to pay or simulate product configurations. Use MaxDiff for narrowing 15 features to a top 5, then use conjoint to optimize the configuration of those 5.

Use Van Westendorp Price Sensitivity Meter When:

• You only need to test price, not feature bundles
• Sample size is limited (works with 100-150 respondents)
• You need a quick directional answer on acceptable price range

Comparison: Van Westendorp asks direct questions ("At what price would this be too expensive?" / "At what price would you question the quality?"). It's faster and cheaper than conjoint but doesn't reveal feature-price trade-offs. Use it for simple pricing questions. Use conjoint when price interacts with features.

Setting Up Your First Conjoint Study

Here's a step-by-step checklist for a properly designed conjoint experiment:

Phase 1: Define Research Objectives (Week 1)

1. Identify the decision. What will you do differently based on the results? "Should we build Feature A or Feature B?" "What price point maximizes revenue?" "Which product configuration wins against competitors?"
2. List candidate attributes. Brainstorm 8-12 possible attributes. Include price.
3. Narrow to 4-6 attributes. Keep attributes customers can evaluate and that affect purchase decisions. Remove hygiene factors everyone expects.
4. Define levels. 2-4 levels per attribute, spanning realistic range.

Phase 2: Design the Experiment (Week 2)

1. Generate fractional factorial design. Use software (Sawtooth, Qualtrics, R package 'support.CEs') to create orthogonal design.
2. Create choice tasks. 8-12 tasks per respondent. For CBC, show 3-4 profiles per task plus "none" option.
3. Add holdout tasks. Include 2-3 tasks for validation that aren't used in estimation.
4. Randomize task order. Each respondent sees tasks in different order to prevent order effects.
5. Write clear descriptions. Define each attribute level unambiguously. "Premium support: Response within 2 hours via phone or chat" vs "Standard support: Response within 24 hours via email."

Phase 3: Sample and Field (Week 3-4)

1. Calculate required sample size. 200+ for ratings-based, 300+ for choice-based, +150 per additional segment.
2. Define target population. Match the market you're selling to, not just current customers.
3. Choose fielding method. Panel provider ($3-8 per complete), customer list (free but biased), paid ads ($5-15 per complete).
4. Set quality controls. Speeders (completing in <40% of median time), straight-liners (same answer every task), attention checks.
5. Pilot with 20-30 respondents. Check for confusing language, task difficulty, completion time. Adjust before full launch.

Phase 4: Analysis (Week 5)

1. Clean data. Remove speeders, straight-liners, failed attention checks. Expect 5-15% removal rate.
2. Estimate part-worths. Run regression (ratings-based) or logit model (choice-based). Check standard errors and significance.
3. Calculate feature importance. Range of part-worths for each attribute ÷ sum of ranges across all attributes.
4. Run market simulation. Test 3-5 product configurations and predict market share.
5. Validate with holdout tasks. Do predictions match actual choices in holdout tasks?

Phase 5: Action (Week 6)

1. Identify winning configuration. Which product maximizes utility at target price point?
2. Estimate revenue impact. Predicted market share × customer base × price.
3. Prioritize feature development. Build high part-worth features first.
4. Set validation plan. How will you test conjoint predictions with real behavior?

The Bottom Line: Test Preferences Before You Test Code

Product development without preference research is expensive guessing. You spend $150,000 building features customers mention in interviews, then discover they won't pay for them. You price at $199 when customers would have paid $249. You add integrations when customers wanted real-time data.

Conjoint analysis forces the trade-offs that happen in real purchase decisions. When you ask customers to choose between Feature A at $149 and Feature B at $199, they reveal what they actually value. The $5,000 conjoint study prevents the $150,000 development mistake and finds the $50 of mispriced value you're leaving on the table.

Before you commit to a product roadmap, run the experiment. Set up proper randomization. Calculate required sample size. Force real trade-offs. Validate with holdout tasks. Then build what customers will actually pay for.

Correlation between what customers say they want and what they choose is interesting. Causation requires a proper experiment. Did you randomize?

Frequently Asked Questions

What sample size do I need for conjoint analysis?

Minimum 200 respondents for stable part-worth estimates. For each additional segment you want to analyze separately, add 100-150 respondents. A 3-attribute × 3-level design with 2 segments needs approximately 350-400 respondents.

How is conjoint analysis different from survey questions asking "What features do you want?"

Direct survey questions suffer from social desirability bias and lack trade-off forcing. Respondents say they want everything. Conjoint analysis forces real choices: if you add this feature, you lose that one or pay more. This reveals true preferences, not wishful thinking.

Can I use conjoint analysis to predict actual purchase behavior?

Conjoint predicts stated preferences, not actual behavior. Use it for relative rankings and trade-offs, not absolute demand forecasting. Validate findings with A/B tests on real purchase decisions whenever possible. The gap between stated and revealed preference can be 20-40%.

What's the ROI of running a conjoint study before product development?

A $2,000-$5,000 conjoint study can prevent $150,000+ in wasted development costs on features customers don't value. One SaaS company avoided building a complex reporting feature that scored -$12 in part-worth utility, saving 6 months of engineering time.

Should I use choice-based conjoint or ratings-based conjoint?

Choice-based conjoint (CBC) better mimics real purchase decisions and handles price more realistically. Ratings-based conjoint is faster to field and easier to analyze but suffers from scale usage bias. For pricing and feature trade-offs, use CBC. For early-stage exploration with many attributes, ratings-based works.