> ## Content Index > Fetch the complete content index at: https://vibe2value.com/llms.txt > Use this file to discover other available public pages before exploring further. # 3.2.3 - Iteration Should Increase Value, Not Just Add Surface Area - URL: https://vibe2value.com/iteration-should-increase-value/ - Published: 2026-01-08T23:59:02.000Z - Updated: 2026-09-07T08:58:59.000Z - Description: Check the iteration value test: say what changed, what user outcome it is meant to improve and what signal will show that it did. - Author: vibe2value - Tags: launch, assist, iteration, focus, avoiding overbuild, shape+build+launch+run+close ## Iteration value test Is iteration increasing user value before launch with AI-assisted coding? ## The call Check whether each iteration increased value. Otherwise you ship changes that feel productive while the user outcome stays flat. ## Sharpen the iteration value test with AI This is a Launch idea, so there are two AI moves: first **Sharpen** the iteration value test using the prompt below, then **Build it with AI**, building carefully to carry the decision into the live system. This idea also calls for **Run it for real**. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real iteration value test and keep the instruction exactly as visible here. It helps you put your launch/iteration-value-test.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this iteration value test is clear enough before you move forward. Constraint: The iteration value test must be specific enough that two people would judge the same release as worthwhile from it. Example of the standard: Vague: "We shipped an update and it feels better." Sharp: "This release quotes your own words back, so you recognise the thought before deciding. The test is whether suggestions get acted on rather than skimmed." The sharp version is specific enough that two people would judge the same release as worthwhile. The vague one is not. Working draft: Release change: [what changed in this iteration] User outcome to improve: [what user outcome it should improve] Proof signal: [what signal will show that it helped] Task: Decide whether this iteration value test is specific enough that two people would judge the same release as worthwhile. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. Check: - Would two people interpret this the same way? - Does it stay concrete enough to guide the next step? - Can you state what changed, what user outcome it is meant to improve and what signal will show that it did? Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Iterating on a live thing without piling on surface area is a running-it-for-real discipline. That is [Ways to run it for real](https://vibe2value.com/ways-to-run-it-for-real/), one of the [six ways to work with AI](https://vibe2value.com/working-with-ai/). ## The same idea on a recipe card Every change to a dish should make it taste better, not just add another ingredient to the list. Throwing in a sixth herb because it is in the cupboard makes the recipe longer and not nicer. A good cook keeps only the change that actually improved the bite and quietly drops the rest. Your iteration value test is that taste-it-again check. Name what you changed, what it was meant to improve and the sign it actually did. Keep the change only if the dish got better, the way a cook adds a herb to improve the flavour and not just to lengthen the recipe. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means An iteration value test is not a diff. It is the check that says whether the change made the user outcome better, worse or unchanged. Until you can name what changed, what it was meant to improve and what signal shows it worked, iterations stay unmeasured. AI can help generate options, but it cannot judge whether the output improved. ## Make the iteration value test concrete Compare the broad version with a version you can actually test. - **Too vague:**��We shipped an update and it feels better. - **Concrete enough to test:** This release quotes your own words back, so you recognise the thought before deciding. The test is whether suggestions get acted on rather than skimmed. The second version lets two people make the same decision from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). v1v2v3value risingbusy but flatchanges, no added value Iteration is only progress if value goes up. The test for each round is whether it added something a user would actually feel; if the version changed but the value did not rise, that was motion, not iteration. ## Check the iteration value test - **Pass:** You can say what changed, what user outcome it is meant to improve and what signal will show that it did. - **Fail:** If the iteration still sounds like we made improvements, the value test is not clear enough yet. Do not ship the next iteration until this passes. ## What you'll walk away with This post is about the framing decision: the words that pin down what this idea actually means for your build, before any code. You'll come out with your own `knowledge-base/launch/iteration-value-test.md` written and sharpened: the iteration value test pinned down as a decision, three worked examples to map against your own surface and an AI prompt that pressure-tests it until two people would make the same call. ## Write it down Your `iteration-value-test.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/launch/iteration-value-test.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Shipping iterations that feel productive but do not increase user value, which accumulates complexity without benefit. - **Mitigation:** Define one value signal per iteration and roll back changes that do not move it. ## Key takeaway Do not move forward until you can say what changed, what user outcome it is meant to improve and what signal will show that it did. ## How to document your iteration value test Write your iteration value test up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Iteration value test ## Answer Release change: [what changed in this iteration] User outcome to improve: [what user outcome it should improve] Proof signal: [what signal will show that it helped] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer Release change: Adding a sixth herb from the cupboard User outcome to improve: The taste of the dish Proof signal: A taste test says the bite is actually better, not just longer ## Evidence A past improvement added ingredients without a taste test and the dish got busier, not better. ## Decision Optimising for changes that improve the taste. Saying no to adding things just to have added something. ## Risk The sixth herb might muddy the dish rather than lift it. Taste against the previous version before keeping it. ## AI instruction Judge the sixth herb by whether a taste test says the dish is actually better, not just more complex. Keep the change only if it improves the taste. ```