If you ask survey respondents what they want in a product, they usually say they want everything, and they want it for free.
Direct rating scales rarely capture the reality of consumer behavior.
When every feature is marked "very important," product teams are left guessing what to actually build.
Conjoint analysis forces respondents to make the same hard trade-offs they make in the real world.
What is a conjoint analysis survey?
Conjoint analysis is an advanced survey methodology that determines how people value different components of a product or service.
Instead of asking respondents to rate individual features in a vacuum, a conjoint survey presents them with complete product profiles and asks them to choose the one they would actually buy.
To build a conjoint survey, researchers break a product down into two structural pieces:
- Attributes: The broad categories of features (e.g., brand, price, battery life).
- Levels: The specific options within each attribute (e.g., $49, $99, 12 hours, 24 hours).
The most common variation is Choice-Based Conjoint (CBC).
In a CBC survey, the software generates multiple product profiles by mixing and matching these levels based on an experimental design.
By tracking which combinations a respondent chooses and which they reject across multiple screens, the analysis calculates a "part-worth utility" score for every single level.
This mathematical output tells you exactly how much price sensitivity increases when you drop a specific feature, or which feature drives the most overall value.
How a feature tradeoff survey works in practice
To understand how this looks to a respondent, consider a software company pricing a new project management tool.
If they used a standard survey tool, they might ask: How important is a calendar view?
Most users will simply select Very Important and move on.
In a choice-based conjoint survey, the respondent instead sees a screen presenting three distinct subscription plans side-by-side, plus a fallback option.
Each option mixes different levels of their defined attributes:
- Option A: 5 users, list view only, basic support, $15/month
- Option B: 10 users, calendar view, basic support, $25/month
- Option C: 5 users, calendar view, priority support, $30/month
- Option D: I wouldn't buy any of these
The respondent picks their preferred package, and the survey immediately generates a new screen with a different combination of those exact same variables.
This cycle repeats for anywhere from 8 to 15 screens.
Expert tip: Cap your attributes at five or six per survey. When you force a respondent to process too many variables on a single screen, cognitive load spikes and they start ignoring attributes entirely just to get through the task.
Conjoint vs. MaxDiff: Understanding the difference
Teams often confuse conjoint analysis with Maximum Difference Scaling (MaxDiff).
While both methods force respondents to make choices rather than relying on rating scales, they measure fundamentally different things and require different survey designs.
| Methodology | What it measures | Output data | Best used for |
|---|---|---|---|
| Conjoint Analysis | Trade-offs between multi-attribute packages | Utility scores showing the exact value of specific feature/price combinations | Pricing strategy, packaging tiers, predicting market share |
| MaxDiff | Relative preference from a single, flat list of items | A ranked list of items with distance scores showing preference magnitude | Prioritizing a backlog of 20+ features, testing marketing claims |
Use MaxDiff when you need to narrow down a long list of standalone ideas or marketing messages.
Switch to conjoint when you need to know how those specific ideas interact with price and packaging.
When should research teams skip conjoint analysis?
Because conjoint provides such rich, predictive data, it is tempting to use it for every product decision.
In practice, it is often overkill.
Conjoint requires specialized statistical software, careful experimental design, and a highly engaged respondent pool.
Dedicated market researchers typically recommend skipping a conjoint study if you face any of the following constraints:
- Small sample sizes: Conjoint requires a robust sample to achieve statistical significance. If you only have access to 50 beta users, the resulting utility scores will be too noisy to trust.
- Early-stage discovery: If you do not yet know which attributes matter to your market, you are not ready for conjoint. You must know the exact features you want to test before building the mathematical model.
- Limited budget: Standard survey platforms do not support true conjoint analysis logic. You will need to pay for dedicated conjoint software licenses or hire a specialized agency to run the study.
- Simple decisions: If you just need to know whether users prefer a dark mode or a light mode, a standard poll is faster, cheaper, and perfectly adequate.
Simpler alternatives for measuring product preferences
When a full conjoint study is too heavy for your timeline, you can still force trade-offs using lighter methods.
These alternatives fit comfortably into standard survey tools and do not require complex utility calculations on the back end.
Constant-sum scales: Give respondents 100 points and ask them to allocate the points across five features based on importance. This prevents the "everything is important" problem by enforcing a strict mathematical budget.
Standard ranking: Present a list of five to seven items and ask the user to drag them into their preferred order. Keep the list short to avoid respondent fatigue.
Direct trade-off questions: Pair two competing features against each other and ask the respondent to pick one.
❌ Weak: Rate the importance of processing speed and data accuracy.
✅ Strong: If you had to choose, would you prefer a tool that is 100% accurate but takes an hour, or 90% accurate but finishes in seconds? Why it works: The direct choice forces the user to reveal their true priority rather than rating both highly.
Build-your-own (BYO) logic: List features with assigned dollar values and ask respondents to check the boxes they want, provided they stay under a stated budget constraint.
FAQ
How many respondents do you need for a statistically valid conjoint analysis?
For a standard choice-based conjoint study, aim for a minimum of 300 completed responses. If you plan to segment the data by different user personas or demographics, you generally need about 200 respondents per subgroup to maintain statistical reliability. Running a conjoint with fewer than 150 people drastically increases the margin of error, making the resulting utility scores risky to use for major pricing decisions.
What is the difference between choice-based conjoint and menu-based conjoint?
Choice-based conjoint (CBC) presents respondents with complete, pre-configured product profiles and asks them to pick the best overall package. Menu-based conjoint acts more like an a la carte menu, allowing respondents to build their own ideal product by selecting individual features and upgrades at specific price points. CBC is better for evaluating fixed subscription tiers, while menu-based conjoint is ideal for highly customizable products like enterprise software or custom vehicles.
Can you build a conjoint analysis survey using basic form tools?
No. True conjoint analysis requires complex experimental design to ensure respondents see the right mix of attributes, followed by statistical regression to calculate utility scores. Basic form builders cannot generate these dynamic choice screens or perform the necessary back-end math. You can fake a simple trade-off question in a standard form, but you cannot run a real conjoint study without specialized software.
If your research requires straightforward constant-sum questions, ranking tasks, or direct trade-offs rather than a complex conjoint model, standard forms are often the better path. You can draft your trade-off questions in a text document and use Doc2Form to handle the survey PDF to Google Form conversion instantly. Keeping the methodology simple ensures you get actionable data without over-engineering the research process.
