---
name: value-realization
description: "Judge whether something actually produces value in a concrete scenario. Value is a beneficial relational property between subject and object, conditioned on the states of both sides, that only holds in a specific scenario. Typical uses: judging whether a value proposition holds, mapping a capability to a concrete use scenario, diagnosing why no one uses it or why they don't stick, clarifying how to position or state the value, assessing whether something is worth investing in, or judging whether you can borrow someone else's approach (e.g. \"is this idea sound?\", \"does anyone actually want this?\", \"why did we roll it out and no one uses it?\", \"why do people try it once and never come back?\", \"can we copy what someone else did?\"). When the thing being judged has a decision-maker (who pays / signs off) that is not the same as the actual end user (enterprise software, internal platforms, etc.), first state which side you're analyzing for and split the two value relationships to run separately."
allowed-tools: [Read, WebFetch, WebSearch, Grep, Glob]
---

# Value Realization

**Type**: Analytical framework

## Overview

This framework judges whether something — a product, feature, piece of copy, use scenario, or any value proposition — actually produces value in a concrete situation. It is not a checklist, nor an evaluation form you run once and hand in a report; it is a set of mutually independent analytical dimensions plus a method for sustained conversation, helping you turn a vague "is this good" judgment into "in which scenario, on what basis, when, and can it be perceptibly produced as value, and how much of these conclusions is reliable" — and then keep talking, round after round, until you've forced out a value or business opportunity that genuinely stands up.

It rests on one premise: value is not a fixed message waiting to be transmitted and explained, but a relationship co-produced by the states of both sides in a concrete scenario. So judging value is not about explaining it clearly, but about finding the specific scenario configuration that makes this beneficial relationship actually hold. Discovering value comes from sharp falsification and relentless probing, not from agreement and paraphrase — and this runs through the entire framework, whether you're talking to real users or in repeated conversation with an AI.

## Key terms

- **User**: the person using this skill (product creator, product manager, designer, founder, etc.).
- **End user**: the person who will use the product under discussion.
- **Experience**: a past event that, under specific conditions within a dynamically shifting historical period, solved a specific problem and yielded a method that correctly solves it (the method carries its own preconditions and usage). Experience depends on a specific scenario, triggers selectively, and before use you must judge whether conditions have changed.
- **Value**: a beneficial relational property between subject and object — a weighted, subjective property conditioned on the states of both sides. When both subject and object are people, it depends on the weighted balance of both sides' cognition.
- **Value scenario**: the concrete configuration that makes the beneficial relationship hold — who, in what state, in what situation and conditions, gets what result from using this thing.
- **Value-relationship configuration**: the specific combination of "subject — object — state — conditions" in the value scenario. Discovering value is, in essence, locking in this configuration.
- **Value-relationship position**: where in the relationship the value confirmation or result realization happens. At least three kinds: the end user confirms some external object, content, or feature is valuable to them; the end user achieves their own result through the product; the end user themselves, their behavior, or their output is confirmed valuable through feedback from others, a group, or a system. The three can coexist but cannot substitute for one another.
- **Second-layer condition**: a more abstract, cross-scenario-reusable constraint extracted from concrete experience, above the surface practice. When micro conditions keep shifting, you need to extract and record it.
- **Use scenario**: the concrete situation in which the product might be used.
- **Use case**: the specific task or flow an end user completes with the product in some situation.
- **Feature**: the product's technical capability.

A few distinctions you must keep straight:

- A feature is not value. A feature is what the product can do; value is what the end user gets as a result in a concrete scenario.
- A use scenario says where the product might be used, a use case says how a user uses it to complete a task, a value scenario says where the relationship is and on what basis it produces a beneficial property — being usable is not the same as producing value.
- Talking about value requires putting it in a concrete scenario. Value detached from scenario can't be judged true or false.
- Every conclusion has two independent axes: direction (does it hold) and solidity (how much rests on evidence). The two can't substitute for each other.

## Three foundational definitions

The whole framework rests on three definitions; return to them repeatedly while analyzing.

### Experience

Experience is an event that happened in the past, solved a specific problem under specific conditions, and yielded a method that correctly solves the problem (the method includes its own preconditions and usage). Three points: it happened in the past, and does not include predictions about the future; it is bound to specific conditions and a specific problem; it holds within a dynamically shifting historical period, not for all time.

Because micro conditions keep shifting within that historical period, you need to extract from concrete experience a more abstract, more change-resistant second-layer condition and record it. That is: experience depends on a specific scenario, triggers selectively under subjective judgment, and before use you must first judge whether conditions have changed.

### Value

Value is a beneficial relational property between subject and object — that is, a weighted, subjective property conditioned on the states of both sides. When both subject and object are people, it depends on the weighted balance of both sides' cognition.

Value is based on both sides' states and on a specific scenario, not a fixed property the product owns unilaterally and that holds detached from the user. Experience, too, only produces value in a specific scenario — when conditions change, experience can fail; reusing past experience in a real scenario usually requires re-analyzing the situation at the time and adjusting how the method is used.

Different end users in different scenarios may seek different types of value — identity and belonging, economic gain, status and recognition, capability improvement, time saved, problem solved, and so on. Such a list is only a prompt for exploration, not a template to apply.

### Information loss

Experience is born with an insider as its subject, and a person cannot be both insider and outsider at once, so experience is inherently limited and lossy.

- A written summary depends on the recorder's writing skill and incurs loss (and the event can't be reconstructed 100%); with exceptional expressive skill there can also be gain.
- Person-to-person communication depends heavily on both sides' cognition, expression, and perception: speaker1 wants to express 100 points and may only voice 80; in speaker2's cognition and perception it folds to 60, a loss of 40 in between (the reverse — gain — is also possible).

## Core insights

Value is a relationship co-produced by both sides' states in a specific scenario, not something the product owns unilaterally and waits to hand to the user. This yields several judgments that run through the whole text:

- **Discovering value is locking in the value-relationship configuration.** The question "does this thing have value" is itself malformed; the right question is "in which configuration — who, what state, what conditions — does it produce a beneficial property." Find that configuration and you've found value; fail to, and everything you say is empty.
- **One person can't compute complete value.** Value depends on the weighted balance of both sides' cognition; analyzing alone, you only grasp your own half. The other half — the end user's state, cognition, and the conditions of the scenario they're in — must be obtained from real, matching end users.
- **Value has degree; it's not a switch.** It's a weighted balance, inherently continuous, so a judgment can't be a binary hold/doesn't-hold verdict — it must also express how deep you've probed and how much rests on evidence.
- **Conditions carry time.** Both experience and value only hold under specific conditions, and conditions shift dynamically: a judgment that held two years ago may run on conditions that have changed today — looking the same, but actually different.

## Two meta-principles

Two disciplines take priority over the specific dimensions: each analysis first calibrates its stance with them, then enters the dimensions. They address two common analytical biases.

### One: start from the concrete, don't habitually see through to the "essence"

Once something has already manifested concretely and can be clearly perceived, the value or problem has already taken shape and landed — and you should directly use that concrete thing to build, rather than habitually abstracting it into an "essence."

The deeper you drill toward essence, the more you strip away the concrete conditions that make value hold — from the information-loss angle, abstraction is stripping conditions, which is loss, while the phenomenon is the state with the most complete conditions and the lowest loss. Seeing through and perceiving it but not acting yields a pretty judgment that can't land and can't be verified.

The only necessary abstraction is extracting the cross-scenario-reusable second-layer condition. So abstract only up to the second layer and stop; don't drill all the way to essence and lose the concrete, usable thing already in your hand.

When analyzing: when the user can already point at a concrete phenomenon — a real piece of feedback, a real usage action, a real dataset — and speak, start from that concrete thing, rather than first abstracting it into a grand truth and discussing that.

### Two: set the target before firing the arrow

Value is only produced in a specific scenario, so no target means no scenario, which means value has nowhere to happen.

Investing continuously without a clear expectation — continuing if there's an effect, stopping if there isn't — is like firing arrows endlessly with no target; once conditions change, what looked useful before fails instantly. Usually you should set the target first — lock in the concrete scenario configuration where value happens — then fire. There's also the exploratory case of finding the target: in a dynamically shifting environment, the target itself must be discovered. The framework holds both modes, but you must explicitly distinguish which one you're in, rather than pretending you have a target.

When analyzing: at the open, confirm whether there's a target (whether the value scenario is clear). If not, first work with the user to set the target, or explicitly declare that you're now in exploratory target-finding mode — don't pretend to make a value judgment with no target.

## Analytical framework: four orthogonal dimensions

Around the current value scenario, evaluate from four mutually independent dimensions. Orthogonal means: each dimension answers a question that doesn't presuppose the others' answers, and one dimension's conclusion can't substitute for or derive another's.

| Dimension | Question it alone answers | Independent axis |
|------|---------------|--------|
| Value Scenario | In which relationship configuration is value produced? Who, in what state, in what situation, does this relationship produce a beneficial property? | Location (is it there) |
| Value Conditions | On what basis does this value hold? Are the preconditions supporting it still present, and will they fail over time? | Foundation (is it stable) |
| Value Timeline | When is value produced? Immediate, delayed, or requiring sustained accumulation? Do both sides know it's coming? | Time (when) |
| Value Delivery | Can value be perceived, understood, and verified low-loss by the target side from the producing side? Or is it buried in the backend, unable to get out? | Delivery (can it arrive) |

These four dimensions correspond to four decoupled links in value's path from production to arrival at the user: where it's produced, on what basis it holds, when it's produced, how it arrives. Changing any one link doesn't presuppose the state of the others, so they are mutually independent.

The four are not equal in weight; Value Scenario is the center of gravity. Discovering real value is, in essence, locking in the scenario configuration that makes the beneficial relationship hold; the latter three dimensions verify whether that scenario is real, stable, when it pays off, and whether it can arrive.

Each dimension follows the same flow:

1. **Why this dimension is critical**: explain why this dimension is critical for the current object, giving reasoning rather than boilerplate.
2. **State assessment**: systematically apply this dimension's method to the current product, feature, copy, or scenario, stating clearly the preconditions the judgment depends on and its boundaries of applicability — don't skip the analysis and jump straight to questions. Where the analysis should call out a contradiction, call it out directly — use one line, "the tension here is…," to put on the table where the current conception is fighting itself, rather than burying it in euphemistic narration.
3. **Named real-product comparison** (mandatory on every dimension, not optional): take one or a few **real, named** products as a mirror to hold up to the current object. Don't say "some tools" in the vague; name names — is it Grammarly or Google Analytics, Duolingo or Mixpanel — restore the preconditions under which it holds on this dimension, then compare against the current object. A real product's value proposition is the sharpest reference: Grammarly sells "it fixes them" (result) not "it shows me errors" (data); Duolingo users commit to language fluency, with XP only an optional touchpoint. Use this concrete comparison to force out whether the current object stands up on this dimension. If a dimension genuinely has no comparable named product, say so — "this dimension has no directly comparable product" — rather than fudging it with a vague "similar tools."
4. **Symbols in the heading, reasoning in the body**: this dimension's direction light (🔴🟡🟢 round lights) and solidity (🟩🟨🟧🟥 squares) follow the dimension heading directly, e.g. `### 3. Value Timeline 🟡 🟧` — the symbols speak for themselves, scannable at a glance. Direction uses round lights, solidity uses squares; different shapes, so they won't get confused. As for "why this grade," don't put it on a standalone label line — work it into this dimension's reasoning body, with phrases like "the current state is…" "the tension here is…" that state the judgment fully. Before judging these two grades, read `references/scoring-rubric.md`.
5. **Sharp questions** (list one group at the end of each dimension, numbered 1./2./3.): don't dilute sharp questions by working them into paragraphs — take this dimension's 2–3 most cutting questions and **pull them out, numbered, as a group**, fired in rapid succession. Each must strike a soft spot in the current judgment and force the other side to answer head-on, not something they can wave off vaguely. For the intended force: "Is your XP system helping users become better marketers, or is it engagement theater?" "If users already have Google Analytics, why would they need another analytics tool?" Discovering value comes from falsification and hard probing, not from agreement — this group of sharp questions is exactly the handle that lobs the ball back to the other side and lets the conversation move to the next round.

Within each dimension, keep the blocks short, direct, and unsparing — like a diagnosis, not a report. Reasoning first, then comparison, then the symbols into the heading, then a group of sharp questions last; the order is fixed. Complete all four dimensions before summarizing, avoid logical leaps, and show the full chain of reasoning.

### 1. Value Scenario (center of gravity)

First ask which relationship configuration value is produced in: can you state clearly who, in what state, in what situation and conditions, gets what result from using this thing. Here you must distinguish value scenario from use scenario — being usable is not the same as producing value. Also look at the configuration's precision: circling only a broad segment merely grazes the scenario; pinning down the segment, their state, and exactly what problem they're stuck on is a precise-enough configuration.

Also state the value-relationship position clearly: is this value the user confirming some external object is useful to them, the user achieving their own result through the product, or the user themselves or their output being confirmed valuable by others and systems. The three are often muddled together, but they support entirely different product claims.

Value only holds in a specific configuration; with the configuration unlocked, the latter three dimensions have nothing to attach to — you don't know who you're giving it to, or under what conditions you're verifying what. This is the target that meta-principle two speaks of.

Method: force the abstract value down to a concrete configuration — who, what state, what situation, what conditions, what result. If you can't force it out, there's no target yet, and that itself is an important conclusion (direction 🔴 or solidity "empty"); the next step is to set a target or go talk, not to keep analyzing downward.

### 2. Value Conditions

First ask on what basis this value holds, what preconditions support it, whether they're still present, and whether they'll fail as time and the market, technology, and user habits shift; if you've borrowed someone's experience or case, whether you've extracted the transferable second-layer condition or just copied the surface practice. Both experience and value only hold under specific conditions, and conditions shift dynamically; this dimension exists specifically to guard against "conditions changed, but the judgment stayed the same."

The key on this dimension is that conditions carry time. A product judgment that held two years ago and one that "looks like the same conditions" today often actually run on different conditions: competitor density, platform maturity, user habits, tech availability, traffic cost are all moving — the earlier one succeeded, this one might not. Before citing any past experience, case, or your own past success, ask first: are the conditions it depended on to hold still present? This is exactly what "a dynamically shifting historical period" in the definition of experience means.

Method: list the key preconditions the value's holding depends on, judge each one as present, changed, or unknown, and flag especially the time-bound ones. If borrowing a case, first restore the conditions under which it held, extract the second-layer condition, then check whether they're currently met. When a key condition has changed or is unknown, downgrade the related judgment to a to-be-verified hypothesis and lower solidity accordingly.

### 3. Value Timeline

First ask whether value is immediate or delayed; if delayed, whether both sides — especially the end user — know it's coming, and what sustains investment during the wait; and whether this timeline matches the product's nature, the scenario, and user expectations. Short-term value and long-term value are both valid, with no inherent superiority; the choice depends on the product's nature, the scenario, and the user's situation. The real problem is mismatch — an immediate-value product forcing in a long-term mechanism, or a long-term-value product giving no perceptible progress during the wait.

There are three timelines: pure short-term, where the immediate value is the complete product; pure long-term, where the user commits to a journey and the result needs long accumulation; hybrid, where a long-term goal is paired with optional short-term touchpoints, and here the short-term touchpoints must serve the long-term goal rather than replace it.

Method: identify the primary value timeline, assess whether it matches the product's nature, the current scenario, and user expectations; if delayed, check whether the end user knows value is coming and whether there's perceptible progress during the wait.

### 4. Value Delivery

First ask whether the value already produced can be perceived, understood, and verified low-loss by the target side; or whether value is buried in backend logic where the user can't perceive it at all; whether value has a concrete image or concrete-scenario carrier that presses information loss to a minimum. This is a direct application of information-loss theory: however strong the backend logic, that's only 100 points on the producing side — without a low-loss form of expression, the target side may only receive 20 points in their own cognition. Invisible value feels like no value.

Perceptibility takes different forms across products — sometimes immediate feedback in the interface, sometimes a report, dashboard, or metric, sometimes runtime output or data — but the key is the same: the end user can point at something concrete and say "I got this." Giving value a carrier of a concrete image plus a concrete scenario is the most effective way to press down loss — giving a class of people a concrete persona, giving a backend judgment a visible state, is doing value delivery. This framework's own direction and solidity are a self-demonstration of this principle.

Method: identify what the end user can point at and say "I got this"; if value is invisible, explore making it tangible, perceptible, and showable through the interface, notifications, progress indicators, result comparison, concrete personas, etc.; and check which link on the path from producing side to target side loses the most.

## Direction and solidity

Value itself is a weighted balance based on both sides' cognition — a continuous degree, not a three-notch switch. So every dimension must give both direction and solidity; missing one leads you to read it wrong. Before giving these two judgments, you must read `references/scoring-rubric.md`.

**Direction** is the indicator-light axis, answering "does value hold on this dimension": 🟢 holds, 🟡 partially holds, 🔴 doesn't hold or lacks a key condition.

**Solidity** answers "how much of this judgment rests on evidence versus still hanging on assumption." The denominator is the set of premises this dimension depends on; solidity is roughly the share of those already backed by evidence:

- Solid: the judgment is basically evidence-backed — on-target user interviews, behavioral data, real cases — and the boundaries are drawn.
- Half: evidence and assumption in equal measure, the most common state in real projects.
- Thin: the direction is there, but most of it still hangs on assumption, to be verified.
- Empty: not yet explored, a blind spot.

Don't report fake precision like "63%." The real world is a weighted balance, and the balance is itself an estimate; a grade plus one line of "why this grade" is enough. The grade's job is to make where and how much is fuzzy visible, not to look precise.

Direction and solidity are orthogonal and combine freely, which is what fits reality: 🟢 but "thin" looks fine but mostly rests on assumption — the most dangerous "pretty fog"; 🔴 but "solid" is confirmation it doesn't hold here, which is actually a valuable conclusion — time to switch targets; 🟡 "half" is the most common state in real projects. Looking only at the indicator light would show "confirmed to hold" and "assumed to hold" as the same green light, missing exactly what most warrants caution; solidity adds that layer. The "thin" and "empty" grades of solidity are directly the checklist of what to go talk about and verify next.

Direction and solidity are both aids to judgment, not replacements for the chain of reasoning; when they conflict with the detailed analysis, the full analysis wins.

## Discovering real value: go talk

Value is a relational property of both sides' states; analyzing alone, you can only compute your own half. The other half — the end user's state, cognition, and the conditions of the scenario they're in — can only be obtained by talking to them. Not talking means having only half the state, and the value relationship can't be judged.

But the real problem is often not that you didn't talk, but that you talked — to the wrong person, without the right method — and the signal you got back is still fuzzy. The most common version is talking only to friends nearby: they're happy to cheer you on but aren't in the scenario you're anchoring to, so what you get back is a position-skewed, already-lossy signal. Information-loss theory explains why: guessing alone at what users want, you are the already-lossy speaker2; talking to the wrong person, asking the wrong way, is just another way of collecting post-loss guesses.

So produce a conversation plan for the dimensions with insufficient solidity (thin or empty), and design "who" and "how to ask" themselves using the definitions of value, information loss, and experience:

- **Who to talk to**: value is a relational property, so pick people whose state, cognition, and scenario match the target. Match runs low to high: friends, general users, early real users; the lower the match, the larger the skew in the signal you get back — don't take friends' positive feedback as verification. Also weigh the other side's expressive ability: information loss depends on both ends of the communication, so however well the scenario matches, someone who can't articulate their own experience still gives you a lossy signal; the less clearly they can speak, the more you must fill in from the concrete through your questioning, rather than having them summarize for you.
- **What to talk about**: take the other half you can't compute — their real scenario, their conditions, the value in their cognition.
- **How to ask**: don't ask about features ("would you use X" is making the user do the already-lossy abstraction for you); ask about concrete events that already happened — "last time you hit this problem, what was the situation, what did you do" — inferring value and conditions back from the concrete, at the lowest loss; digging down into conditions from there is doing condition archaeology and extracting the second-layer condition.
- **How to verify**: put what you got back into the four dimensions, update direction and solidity, and raise "thin"/"empty" to "half"/"solid."

## Sustained conversation loop

This framework is not an evaluation form you run through the four dimensions once and finish with a report — it's a tool for sustained conversation, with real people and also with AI (including the one you're talking to). The goal is not to give a conclusion as fast as possible, but to **round by round talk the target more precise and raise solidity from empty/thin to half/solid, until you've talked out a value or business opportunity that genuinely stands up**.

Each round of conversation is not an endpoint but the start of the next. A round should close by delivering three things, not a pretty summary:

- **Current four-dimension state**: the latest direction and solidity for each dimension, clearly pointing out which dimension is the decisive foundation, which is "pretty fog" (🟢 yet thin), and which is still a blind spot (empty).
- **The one question to attack first**: not a list of every to-be-verified item, but the single veto-power one for this round — verify it first, and only then does the rest matter. Make it a concrete, executable, falsifiable action, not a vague "needs verification."
- **The entry to the next round**: following that question, throw out a sharp counter-question or a scheme to compare, lobbing the ball back to the other side so the conversation can keep going. Better to force out an uncomfortable but critical question than to hand over a comfortable but useless affirmation.

Keep sharp through every round: actively do value exploration and discovery, call out muddled value-relationship positions, question green lights hanging on assumption, restore the preconditions of borrowed cases. Agreement and paraphrase don't raise solidity; only falsification and hard probing do. When the other side (person or AI) gives new information, put it back into the four dimensions, update the symbols, and throw out the next question — keep this loop going until some value configuration genuinely stands up on evidence, or you clearly judge this path a dead end and time to switch targets.

## Common traps

1. **Talking about value detached from scenario.** Saying "boosts efficiency, cuts cost, improves experience" without saying in which scenario, for whom, under what conditions it holds — the end user can't judge whether these values have anything to do with them. Map abstract value to a concrete configuration: who, in what situation, completes what task, gets what result.
2. **Focusing on features rather than value.** Listing "we have features X, Y, Z," but the end user only cares what result they'll get. Always translate features into value — feature X lets a certain kind of user achieve Y in a certain scenario.
3. **Mechanically copying the surface practice.** Seeing someone succeed with a mechanism and copying it wholesale, without understanding under what conditions and by what mechanism it produced value for that batch of users. First restore the preconditions under which the case held, extract the transferable second-layer condition, then judge whether it applies now.
4. **Ignoring the time drift of conditions.** "It worked two years ago, the conditions look the same now, so it'll work" — competitors, platforms, user habits, tech availability, traffic cost are all changing, looking the same but actually different. Before citing any past experience, restore the conditions under which it held and check one by one whether they're still present.
5. **Invisible value.** Claiming "stronger, faster, better," but an improvement the end user can't see or feel is equivalent to nonexistent. Give value a low-loss, perceptible, showable form.
6. **Treating direction as solidity.** "This dimension is green, so it's fine" — green might be confirmed to hold or assumed to hold, and the two are worlds apart. Mark both direction and solidity on every dimension; 🟢 plus "thin" is the pretty fog that most warrants caution.
7. **Taking the wrong person as verification.** "I asked my friends, they all said it's great" — friends are happy to cheer you on but aren't in the target scenario, so the feedback is skewed and post-loss. Find people who match the target, and discount the solidity of friends' feedback by match.
8. **Habitual abstraction, ignoring the concrete you have.** You already have a concrete phenomenon and real feedback, but first abstract it into a grand truth and discuss that. Abstraction strips conditions and adds loss, while the concrete is the state with the most complete conditions; start from the concrete, already-perceptible thing, and abstract only up to the reusable second-layer condition.
9. **Firing the arrow with no target.** Investing continuously without a clear expectation, continuing if there's an effect and stopping if there isn't. No value scenario means value has nowhere to happen; once conditions change, what looked useful before fails instantly. First confirm whether there's a target; if not, set one first, or explicitly acknowledge you're in exploratory target-finding.
10. **Confusing the value-relationship position.** The user finds the content fun and the interface easy to use, and you conclude the product already supports the result it claims. But fun and easy might only mean some external object was confirmed valuable, or a one-time short-term result was delivered — not that heavier results like capability improvement, identity, or being needed by others have already happened. State clearly where in the relationship the value lands, and don't extrapolate evidence from one position into a result at another.

## Methodology

### Distinguishing hypothesis from evidence

A value scenario can be proposed as an analytical hypothesis, but can't be taken directly as fact. A hypothesis is a possible configuration, conditions, and result inferred from the product, users, and features; verified means a configuration, conditions, and result supported by on-target user interviews, behavioral data, real cases, market data, or usage evidence. When unverified, state clearly that it's a hypothesis (reflected in solidity), and point out what evidence is needed to verify it.

### Condition archaeology

Before citing any theory, pattern, or case conclusion, first restore the necessary preconditions the original conclusion depended on, test whether those conditions hold in the current situation, then judge the conclusion's scope and boundaries of applicability. Key points: conditions change over time, and a judgment that held at one stage may lose validity after conditions change; don't aim to exhaust all conditions, but identify the decisive condition, the main failure conditions, and mismatch risks; distinguish cross-situation misuse (transferring a conclusion from one set of preconditions to a situation with different preconditions) from cross-level misuse (treating a local, tactical, short-term judgment as a whole, strategic, long-term one).

### Extracting the second-layer condition

When micro conditions keep shifting, what's reusable is not the surface practice but the more abstract second-layer condition. When borrowing experience, abstract up to the second layer and stop: abstracting further loses all the concrete conditions that make value hold (meta-principle one), while stopping at the surface practice leads to mechanical copying (trap 3).

### Assessing case applicability

A reference case shows a pattern, not a universal rule. Before citing, first restore the preconditions under which it held, then assess the match on several fronts: product type (B2C consumer app, B2B developer tool, enterprise software), market environment (competitive, niche, monopoly), user behavior (daily use, occasional use, one-off transaction), value delivery (immediate utility, long-term transformation, hybrid), and time conditions — the difference between the historical period in which the case held and now. When a case differs significantly from the current object, search for comparable products in the same domain to analyze, rather than forcing a consumer-app pattern onto a different context.

When comparing, always use **named real products**, never vague phrasing like "some tools" or "similar products" (this is a hard requirement of step 3 in the four-dimension flow). A real product's value proposition is the sharpest reference — it makes distinctions like "result vs data" and "immediate utility vs long journey" concrete for you: Grammarly sells "it fixes them" not "it shows me errors," Mixpanel needs no gamification because its utility is immediate, Duolingo's XP is only an optional touchpoint rather than the core value. Naming names, restoring the conditions under which it held, then comparing against the current object forces out a truer judgment than abstract discussion.

### Balancing exploration and evidence

Exploratory thinking suits identifying possible value configurations, brainstorming ways to make value visible, and exploring positioning directions. Evidence-based analysis is required for: claiming a specific adoption pattern or metric, comparing against real products, and stating what works in practice. The flow is to explore possibilities first, verify through research when a concrete claim or comparison appears, analyze based on verified patterns, and acknowledge where evidence is limited or context differs.

### Research sources

Prefer primary sources: official sites and docs, company announcements, published metrics and growth data, academic or industry reports. Use secondary sources with caution: tech news, user reviews, third-party estimates. Avoid making claims from memory alone, assuming a domain's pattern applies universally, making claims without sources, or treating a reference case as a prescriptive template. WebFetch and WebSearch can be used to verify information; when research fails, analyze based on the framework and clearly state which information still needs verification.

## Analytical flow

1. Calibrate stance: first run the two meta-principles — are you starting from the concrete, is there a target.
2. Lock in the value scenario: who, what state, what situation, what conditions, does this relationship produce a beneficial property. This is the center of gravity.
3. Go through the four orthogonal dimensions one by one: scenario, conditions, timeline, delivery, showing reasoning on each, no skipping.
4. Give direction and solidity: at the end of each dimension's reasoning, give them in one line with a line of why this grade, against `references/scoring-rubric.md`.
5. Produce a conversation plan for dimensions with insufficient solidity: who to talk to, what to talk about, how to ask, how to verify.
6. Summarize: summarize after all four dimensions, pointing out the decisive question and the next step.
7. Continue the conversation: the summary is not the endpoint. Throw out the sharp counter-question that most needs verifying first and is most likely to overturn the current judgment, lob the ball back to the other side (person or AI), enter the sustained conversation loop, and round by round raise solidity, until you've talked out real value or clearly judged it time to switch targets.

**Adjust output to the request**: the core doesn't change, but the presentation varies by request. To evaluate an idea, run the full four dimensions and give a judgment; to write copy or use scenarios, run the value scenario and four dimensions through in your head first, then output the content itself rather than laying out the analysis process; to diagnose existing copy or a value proposition, use the four dimensions to find which one it fails on; to propose improvement directions, first state the current object's problems on the four dimensions and the value scenario, then give adjustments derived from the analysis, distinguishing what has evidence from what's a to-be-verified hypothesis.

This is not a checklist, it's a way of thinking. Every product, market, and end user is different. The goal is to judge clearly: in which scenario, on what basis, when, and whether value can be perceptibly produced, and how much of these conclusions is reliable.

## Core principles

1. Discovering value is locking in the value-relationship configuration — don't ask "does it have value," ask "in which configuration does it produce value."
2. Value is a relationship of both sides' states — one person can't compute complete value; the other half comes from matching users.
3. Value has degree — use the two judgments of direction and solidity, no binary verdicts.
4. Conditions carry time — before citing any past experience, check whether the conditions under which it held are still present.
5. Start from the concrete — prefer the already-concrete, already-perceptible thing; don't habitually see through to essence.
6. Set the target before firing the arrow — no scenario means no position for value to happen.
7. Perception is value — invisible value feels like no value.
8. Short-term and long-term are both valid — no inherent superiority; choose by the product's nature and scenario.
9. Falsify sharply, don't agree — value discovery comes from overturning assumptions, not from nodding. Every dimension must call out the hidden confusion, throw out the most cutting counter-question, and give a judgment-bearing suggestion, until the "pretty fog" is forced into its true shape. Tepid paraphrase is this framework's failure state.
10. Use named real products as a mirror — every dimension holds a named real product (Grammarly, Duolingo, Mixpanel, not "similar tools") against the current object, using the preconditions under which it held to force out whether the current object stands up. A real product's value proposition is the sharpest reference.
11. A diagnosis, not a report — keep each dimension's blocks short, direct, and unsparing, ending with a numbered group of sharp questions fired in rapid succession. Neat structure blunts the edge; better to crudely strike the vital point than to neatly go around it.

## Reference files

- `references/scoring-rubric.md`: the criteria for the four dimensions' direction (🔴🟡🟢) and solidity (🟩🟨🟧🟥); required reading before giving these two judgments.
- `references/worked-example.md`: a full worked run of the four dimensions on one real object, showing how the symbols land in headings, how the named-product comparison is done, and how each dimension closes with sharp questions.

## Boundaries of applicability

Two real situations change the shape of the analysis, and you have to name them rather than run the four dimensions as if they don't exist.

**Decision-maker ≠ user — split into two value relationships.** In enterprise software and internal company tools, whoever pays or signs off (procurement, a manager) is often not whoever uses it daily (a frontline employee), and the two value relationships differ: the decision-maker's is cost, control, visible results; the user's is smoothness, time saved, less friction. State which side you're analyzing, and run the dimensions separately for each — the frontline loving it doesn't mean the decision-maker buys, and sign-off doesn't mean the frontline adopts. This is the "value-relationship position" concept applied to a structural split the four dimensions otherwise treat as one relationship.

**When adoption isn't driven by "beneficial," the framework misfires.** A monopoly product, or an internal tool the company mandates — the user has no choice, so adoption says nothing about whether the beneficial relationship holds. The framework measures that relationship, so on this object it reads a false signal. Say so, and shift the real question to the cost and friction of the mandate rather than pretending usage is evidence of value.

## Remember

This framework helps you think about value, not prescribe a solution. Every product is unique, every market is different, and conditions shift dynamically. The goal is always to find the scenario configuration that makes the beneficial relationship genuinely hold — because value is only produced there.