/value-realization

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 conditi