Reviews
Part of 5 lessons worth learning about independent condiment brands
Tasting during condiment development: telling preference from description
Sensory work during development: separating descriptive panels from preference tests, benchmarking against the product you must beat, and validating your method.
What to take away
- Descriptive tasting and preference testing answer different questions. Do not mix them in one session.
- Benchmark against the product a customer would buy instead of yours, not against your last batch.
- Validate the method before trusting the result. An unvalidated tasting protocol produces confident nonsense.
- Decide in advance what result would make you stop. Development without a stopping rule runs forever.
Two different questions
Descriptive tasting asks what this product is like. Trained or semi trained tasters score defined attributes, and nobody is asked whether they like it. Preference testing asks whether people would choose it, and it needs untrained people who represent your buyer.
Founders routinely run one and interpret it as the other. A friend saying a sauce is nicely balanced is descriptive. A friend saying they would buy it is worth nothing at all, because they are your friend.
Benchmarking against the real competitor
Test your prototype against the product a customer would buy instead, usually a well made mainstream product, not another small maker.
Those are hard to beat for a reason. And the scale that makes a cheap bottle taste the same in March and September is a real achievement rather than a shortcut. Code both samples, present them in the same container, and score them on the same fields.
Ground your target in what people actually eat. USDA tracks the food supply available for consumption and examines consumer food preferences by age, income, region and whether food is eaten at home or away.
Those descriptive statistics help producers understand who consumes their commodities and how. A brief built on that evidence beats one built on the assumption that everyone eats like you do.
Validate the method, not just the product
Before a panel result decides anything, ask whether the method is sound. NIST's calibration method validation webinar covers method selection and validation requirements under ISO/IEC 17025, plus validation analyses and records to retain.
The idea transfers: state your method, show it gives consistent answers on known samples, and keep the records.
The practical version for a small developer:
Validate the method
- Include a blind duplicate in every set and check that it scores the same.
- Include a known reference sample whose score you already trust.
- Fix the serving temperature, portion size and carrier.
- Record who tasted, when, and under what conditions.
- Discard sessions where the duplicate check fails.
Order effects are large and easy to remove. Whichever sample is tasted first tends to score higher. Rotate the presentation order across tasters instead of serving everyone the same sequence.
Palate carryover works the same way: a sweeter or hotter sample leaves a shadow on the next. A rinse and a fixed pause between samples belong in the written method, not in somebody's habit.
The same controls work at a kitchen table, where a repeat sample entered under a second code is what tells you whether a session was worth recording.
Turning tasting into a decision
Write the decision rule before the session. For example: proceed only if the prototype is preferred over the benchmark by a stated margin among people who buy this category. Then follow it. The most common failure in development tasting is not bad data, it is good data that gets overruled by the founder's attachment to a formula.
The production side equivalent of this discipline is in our batch tasting guide, and the gate structure that decides when to run each kind of test is in the development process guide.
