Taste Emulation Heuristic

Taste Emulation Heuristic

Purpose

When building costs approach zero, an AI system can produce "good enough" for almost any brief — the differentiator shifts to who can reliably tell "good enough" apart from "genuinely excellent" for a specific audience, before spending weeks validating it the slow way. This skill treats taste not as an innate, mystical trait but as a learnable, trainable judgment capability: running a mental simulation of a defined group's reaction, built the same way a model is trained — through deliberate exposure, repeated prediction attempts, and correction against real feedback.

Anchored in

Notion product lead Max Schoening's account of taste as a trainable prediction skill, supplied by the user from a source video transcript: "Taste actually means you're able to run a virtual machine in your head where, given an idea, you can predict for a certain in-group whether they're going to like it or not. You just have to do reps — it's almost like training a model." And on scope: "the extremes are — if you are the only person on the planet that thinks something is good, is it good? No. But maybe you also don't need to build a product for 8 billion people. You decide what your in-group is, and then how good do you get at emulating how they will react to it."

Method

1. Define the in-group narrowly, before anything else. Not "our customers" or "users" — a specific, bounded group (often 100-500 people in the source framing) whose reaction actually matters for this decision. A taste judgment made for "everyone" collapses into the lowest common denominator; a taste judgment made for a named, specific in-group can be sharp and confident. If the in-group can't be named concretely (by role, context, and what they already value), the prediction that follows won't be trustworthy — go back and narrow it first.
2. Build exposure hours deliberately, before you need them. Taste emulation depends on having internalized what "world-class" actually looks like for the relevant category — not generic good taste, but fluency in the specific tradition the in-group judges against (e.g. Japanese craftsmanship precision, Apple's unibody restraint, Bauhaus functional minimalism, glassmorphism's specific visual grammar). This is a standing practice, not a one-time prep step: the quality of every later prediction depends on how much deliberate, analytical (not passive) exposure has already accumulated. A side effect worth naming: this vocabulary is also what lets you brief an AI system precisely — "make it feel more Bauhaus" only works as an instruction if both you and the model have a shared, specific referent for it.
3. Run the mental simulation before asking anyone — AI or human. Before consulting a stakeholder, running a survey, or prompting an AI for feedback, close the loop yourself first: walk through the concept as a member of the defined in-group would experience it, and write down the predicted reaction (like/dislike, and specifically why) as an explicit, falsifiable claim. Skipping this step and going straight to external validation is the single biggest reason taste never actually develops as a skill — there's no prediction to be right or wrong about.
4. Validate against real signal and correct the internal model (the "backpropagation" loop). Compare the prediction from step 3 against actual reactions — real user feedback, a small test, a trusted in-group member's honest response. Where the prediction was wrong, don't just note the outcome; name specifically what about the internal model of the in-group was off (wrong assumption about what they value, wrong read on the specific detail that mattered). This correction step, repeated, is what turns a guess into a trained judgment — treat every miss as a labeled training example, not a one-off surprise.
5. State the confidence level and scope honestly in the output. A taste prediction is a considered judgment, not a fact — present it as "predicted in-group reaction: [x], confidence: [low/medium/high based on exposure depth and prior track record for this in-group]," and name explicitly which in-group it's scoped to. A taste call presented as universal truth, or made for an in-group the predictor doesn't actually have exposure hours in, should be flagged as low-confidence rather than stated with false authority.

What this skill does NOT do

• Doesn't replace real user research or testing where the decision's stakes justify it — this skill is for fast, early-stage judgment calls (should we even build this, which of two directions is worth prototyping), not a substitute for validating a launch-ready product.
• Doesn't work without genuine, deliberate exposure to the category — applying this heuristic to an unfamiliar domain the predictor hasn't actually studied produces a confident-sounding guess, not a trained prediction; say so explicitly rather than presenting low-exposure guesswork as taste.
• Doesn't determine who the in-group should be — that's a strategic positioning choice for the business, not something this skill resolves (see category-definition-and-modeling for that broader question).

Refinement notes

The exposure-hours and backpropagation-loop framing is a direct generalization of one practitioner's account, not a broader synthesized literature — if the owner develops their own track record and concrete in-group examples applying this heuristic, they belong here as validated worked examples rather than the current single-source grounding.

Continue from here

• Before positioning or building on a taste call: ../category-definition-and-modeling/SKILL.md
• Predicting reaction before a demo/prototype is built: ../../../prototyping-and-demonstration/skills/opportunity-visioning-with-pr-faq/SKILL.md
• A related, more structural read of an opportunity's attractiveness: ../../../opportunity-recognition/skills/opportunity-value-assessment/SKILL.md — that skill scores commercial viability; this skill predicts emotional/ aesthetic reaction, a different and complementary question.
• Once a concept has been through this heuristic, sharpening how it's explained to others: ../../../change-and-communication/skills/whiteboard-clarity-and-jargon-stripping/SKILL.md
• This pack's shared guardrails: ../../CLAUDE.md

References

• ../../CLAUDE.md — the pack's shared guardrails

Reminder: frontmatter has only name and description. Everything else goes into skills_index.json (run scripts/generate_index.py).