Condiment development: tasting that produces decisions

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

Put your prototype against the product a customer would buy instead. That is 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 the target in what people actually eat. USDA tracks the supply of food available for consumption and examines consumer food preferences by age, income, region and whether food is eaten at home or away, and it notes that these descriptive statistics help producers understand who consumes their commodities and how. Building a brief on that kind of evidence is better than building it 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 itself is sound. NIST's calibration method validation webinar covers the requirements for method selection and validation under ISO/IEC 17025, including the analyses that form part of validation and the documentation that has to be retained. The idea transfers directly: state your method, show it gives consistent answers on known samples, and keep the records.

The practical version for a small developer:

• 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 deserve a mention because they are large and easy to remove. Whichever sample is tasted first tends to score higher, so rotate the presentation order across tasters rather than serving everyone the same sequence. Palate carryover works the same way: a sweeter or hotter sample leaves a shadow on the next one, which is why a rinse and a fixed pause between samples belong in the written method rather than 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.

Common questions

How many tasters do I need? More for preference testing than for descriptive work. A handful of trained tasters can describe, but not predict.

Can I use staff? For descriptive work yes, with training. For preference testing they are the worst possible sample.

Should tasters know the price? No. Price expectation moves preference strongly.

What if the benchmark wins? That is the most valuable result you can get, and the cheapest one to act on.