Value Realization is a prompt framework for testing whether a product idea holds up
Analyze whether end users will discover clear value in product ideas.
At a glance
- What is it?
- Value Realization is a version 2.0.0 analytical framework, distributed as a pair of Markdown skill files, that judges whether a product idea produces value by placing it in a concrete scenario and separating evidence from assumption across four independent dimensions. It is written for sustained conversation with people or AI models rather than as a one-shot scoring form.
- Who is it for?
- Adopt Value Realization if you are a founder or product lead who keeps getting polite agreement on an idea and needs a way to see which conclusions rest on evidence. Skip it if you need a quantitative scoring model or a comparison between options, since the framework produces a conversation rather than a number.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 83 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on October 20, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The problem the framework claims to solve
The README frames the target audience precisely: when judging whether something has value, the real difficulty is rarely did nothing. Most people took action. The problem lies in the weighting of that action, in that they did something but it went off-target or stayed shallow, and they did not know it. The framework names four common shapes of this. First, verified but the verification target was off. You start on a product, go talk to friends nearby, and friends are happy to cheer you on with positive feedback, so it sounds verified, but friends are not in the scenario you are anchoring to, so what you get back is a position-skewed signal, and the problem is not whether you talked but whether who you talked to matches the target. Second, a scenario was named but the scenario is too fuzzy, so you say for people who do marketing and the precision stops there, short of who, in what state, stuck on what problem. The README puts a ratio on that: scenario is 30 percent and features 70 percent, not zero scenario, just imbalanced.
The other two failure shapes: copied cases and hollow judgment
The third shape is copying a case but copying the surface and ignoring time. You see someone succeed and lift the actions without restoring the preconditions that made it hold, and the README singles out time as the more insidious part, because a product that worked two years ago looks like the same conditions today while competitors, platforms and user habits have shifted and copying it now might not work. The fourth shape is having a judgment but being unable to tell evidence from assumption. You say it looks like it holds, and drilling down, most of it hangs on assumption, which the README calls a pretty but empty judgment, and notes the person usually does not know it is empty. The framing point that follows is important for how the framework is meant to be used. None of these are black-and-white failures, they are all a matter of how much weight each carries, and the real world is almost all half-finished plus imbalanced weighting. So judging value cannot be a holds or does not hold binary verdict, it has to express degree and make visible where things are fuzzy and how fuzzy.
The premise: value as a relationship, not a property
One core judgment runs throughout the framework, and it is stated as a premise rather than a conclusion. Value is not a fixed thing the product owns unilaterally and waits to explain and hand to the user, but a relationship co-produced by both sides' states in a specific scenario. From that, the README argues the question does it have value is itself malformed. The right question is in which configuration, meaning who, what state and what conditions, does it produce a beneficial property. Find that configuration and you have found value; fail to, and everything you say is empty. Three further points follow. One person cannot compute complete value, because the other half is with real users. Value has degree, it is not a switch. And conditions carry time, drifting out of validity as the environment shifts. Together these decide what the skill looks like in practice, and they are why the framework's output is a set of judgements with degrees rather than a verdict.
The four dimensions and the two separate scales
Around the centre of gravity, in which scenario is value produced, the framework takes a vague is this good apart along four mutually independent dimensions. Value Scenario asks in which relationship configuration value is produced, and is the centre of gravity. Value Conditions asks on what basis it holds, and whether the conditions supporting it are still present. Value Timeline asks when it is produced, immediately or requiring accumulation. Value Delivery asks whether it can be perceived low-loss, or is buried in the backend where it cannot get out. Each dimension then gets two separate judgements. Direction is whether it holds, and solidity is how much rests on evidence. The README is explicit that the two are given separately, because a green light might be confirmed to hold or merely assumed to hold, which it calls a big difference and exactly the thing most worth watching. The reference files section names where those criteria live: SKILL.md holds the full methodology with three foundational definitions, four orthogonal dimensions, two meta-principles, the conversation plan, the analytical flow, common traps and core principles, while references/scoring-rubric.md holds the criteria for the four dimensions' direction and solidity.
A conversation format, not a scoring form
The README is direct that this is not an evaluation form you run through the four dimensions once and hand in as a report. It is a tool for sustained conversation, with people and with AI. Each round makes the target more precise and raises solidity from empty or thin to half or solid, closing in round by round on a value or business opportunity that genuinely stands up. The stated method of discovery is sharp falsification and probing, not agreement and paraphrase, and that sentence is the operational heart of the thing. A skill that rewards agreement will produce agreement. One that requires falsifying the hypothesis in a concrete scenario will at least tell you which part of your idea survives contact with a real user. The second structural commitment is that the skill set its own target using its own method. Not knowing which target you are firing at, and producing something fuzzy, is the disease it treats, so every analysis has to state clearly which target is being fired at, how far it has been probed, how much rests on evidence, and who to ask next. That is a self-imposed reporting requirement, and it is the mechanism that keeps the framework honest across rounds.
Where the framework says it does not apply
The README has a section on where it applies and where it does not, and the exclusions are the most useful part for judging fit. It applies to judging whether a value proposition genuinely holds, value assessment of a product, feature, copy or scenario, adoption and retention problems, positioning problems, and mapping features to concrete scenarios. It does not apply, with caution, to enterprise software where the decision-maker is not the end user, to monopoly products where the user has no choice, and to products whose value is inherently delayed and whose conditions are extremely stable. Each exclusion is a reason the central premise does not apply. If the person who decides is not the person who uses the product, then the relationship co-produced by both sides' states is not the relationship that determines value. If the user has no alternative, the scenario is not doing the work the framework assumes it does. And if value arrives after a long delay under stable conditions, there is no drift to detect and no accumulation worth timing, so the timeline dimension has little to say.
What it is as a piece of software, and where the limits are
It is worth being clear about the artefact, because the name suggests a codebase and the repository does not contain one. The top-level entries are LICENSE, README.md, README-zh.md, SKILL.md, SKILL-zh.md and a references directory. There is no source code, no build, no test suite, and no release history. What you install is a set of instructions, in English and in Chinese, that a model reads and follows, and the README calls the project type an analytical framework with the status ready, at version 2.0.0, and the licence is MIT. That has two consequences. The first is that adoption cost is near zero and so is the cost of changing your mind about it, since there is nothing to migrate. The second is that the output quality depends entirely on the discipline of whoever or whatever is running the conversation, and the framework's own commitment to self-target, stating which target is being fired at and how much rests on evidence, is a commitment that has to be enforced by the operator. The last push to the repository was on 2026-08-01, so the files are recent but the version numbering suggests an active rewrite rather than a long-settled method. If you want a quantitative score to put in a spreadsheet, this will not give you one. If you want to find out that your idea fails because you interviewed the wrong people, it is built to do exactly that.
Editorial conclusion
Adopt Value Realization if you are a founder or product lead who keeps getting polite agreement on an idea and needs a way to see which conclusions rest on evidence. Skip it if you need a quantitative scoring model or a comparison between options, since the framework produces a conversation rather than a number. Before you use it, read the two reference files named in the README, SKILL.md for the methodology and references/scoring-rubric.md for the direction and solidity criteria.
Frequently asked questions
What is the Value Realization framework?
It is a version 2.0.0 analytical framework distributed as Markdown skill files, SKILL.md and SKILL-zh.md with a references directory, that judges whether a product idea produces value by placing it in a concrete scenario and separating evidence from assumption. The README describes it as a tool for sustained conversation rather than a scoring form.
What are the four dimensions Value Realization uses?
Value Scenario, which asks in which relationship configuration value is produced and is the centre of gravity, Value Conditions, which asks on what basis it holds and whether those conditions still exist, Value Timeline, which asks when it is produced, and Value Delivery, which asks whether it can be perceived low-loss or is buried in the backend.
Where does Value Realization say it does not apply?
To enterprise software where the decision-maker is not the end user, to monopoly products where the user has no choice, and to products whose value is inherently delayed and whose conditions are extremely stable. It applies to value propositions, product, feature, copy and scenario assessment, adoption and retention problems, positioning problems and mapping features to concrete scenarios.
How is Value Realization distributed and licensed?
The repository contains only Markdown: LICENSE, README.md, README-zh.md, SKILL.md, SKILL-zh.md and a references directory containing scoring-rubric.md. There is no code, build or test suite. The licence is MIT, and the README records the version as 2.0.0 with the type as analytical framework and the status as ready.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/done-0-value-realization)Was this useful?