Value Realization

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.

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."