If you are about to commission a conjoint study, the most useful hour you will spend happens before anyone writes a survey question. It is the hour where you write down, in one sentence, the tradeoff you are trying to decide. Most conjoint studies that disappoint do not fail in the analysis. They fail at the start, because the team never agreed on what it was choosing between.
What conjoint does
Conjoint analysis is a survey method that shows respondents a series of product options, each built from a set of features (attributes) at different settings (levels), and asks them to pick one. Because every option forces a tradeoff, the model can estimate how much each attribute and level drives choice, then simulate how customers would respond to configurations you have not launched yet. Choice-based conjoint, the most common form today, belongs to the broader family of discrete choice methods.
That is its strength: it measures what people give up, not just what they say they like. Ask customers whether they want more integrations, a lower price, and faster support, and they will say yes to all three. Conjoint makes them choose.
But the method only answers the tradeoff you build into it. That is where most of the trouble starts.
The attribute list is a symptom
A typical kickoff produces a long list of attributes: every feature the product team is debating, three pricing ideas, a few packaging options, contract length, support tier. Each item on the list has an owner who wants an answer.
A list like that tells you the team has questions. It does not tell you the team has a decision. When the study comes back, you get a ranking of attribute importance and a table of utility scores, and the readout turns into each owner pointing to the result that supports what they already wanted. The study answered ten questions shallowly and the one that mattered not at all.
Long lists also cost you in the data itself. Every attribute you add makes each choice harder to evaluate, and once options get hard to compare, respondents start taking shortcuts, such as choosing on price alone and ignoring everything else. Experienced practitioners keep the attribute count to a handful for exactly this reason.
Write the decision as a tradeoff
Before design starts, write the decision in this form:
We are choosing between A and B. A gives us X but costs us Y. We will choose A if customers value X enough to accept Y.
Two hypothetical examples show how this sharpens a study.
A SaaS founder is deciding whether to move integrations from the premium tier into the base plan. Moving them should lift conversion on the base plan. It also removes the main reason accounts upgrade. The tradeoff is adoption against revenue per account, and the study needs to show how much base-plan choice rises when integrations are included and how much premium-tier choice falls.
A consumer brand is deciding between a larger pack at a lower unit price and the current pack with a premium ingredient at the same shelf price. The tradeoff is value perception against quality perception, and the answer may differ by segment, which means the sample needs enough of each segment to compare them.
Once the tradeoff is written down, design gets easier. The attributes that belong in the study are the ones that bear on that tradeoff, plus the few that customers need in order to make a realistic choice. Everything else goes to a different study or to a few follow-up questions at the end of this one.
Four questions to answer before design
What options are actually on the table?
Levels should reflect configurations you would ship. Testing a price you would never charge, or a feature you cannot build this year, spends respondent attention on a scenario that will not happen.
Who is making the choice?
A prospect comparing plans on a pricing page is a different respondent from a current customer deciding whether to upgrade. If the decision is about upgrades, the sample has to include people in a position to upgrade. Who is in the sample matters as much as how many.
What is the choice made against?
Options are only meaningful relative to something: the current offer, a named competitor, or the option to buy nothing. For most pricing decisions, a "none of these" option belongs in the choice tasks, because walking away is a real outcome and leaving it out inflates demand for everything you test.
What result would change your mind?
Write down, before fieldwork, what you would need to see to pick A over B. For example: if including integrations raises simulated base-plan choice by more than the share we expect to lose from the premium tier, we move them. A decision rule written in advance keeps the readout from turning into a debate about interpretation.
Why this matters more for smaller companies
Large companies sometimes run conjoint as an exploratory exercise and treat the results as one input among many. A founder or a growing consumer brand usually cannot. The study is often the main evidence behind a pricing or packaging change that will show up in revenue within a quarter or two. A tightly framed study with five attributes that settles one decision is worth more than a sprawling one that informs several decisions a little.
It is also cheaper. Fewer attributes and levels mean a shorter survey, fewer respondents needed for stable estimates, and a readout your team can act on in one meeting.
How we start a conjoint project
Our founder's background includes a utility program evaluation study at Cadmus that tested discrete choice modeling against other methods for estimating how much of a customer's decision traced to a rebate versus a financing offer. The lesson carries over to any market: isolate the tradeoff first, then choose the method that measures it best. At ClearEdge, the first conversation about any conjoint project is about the decision, not the survey. If we cannot write your tradeoff in one sentence together, the study is not ready to design.