3.1.2 - Ask for Signals, Not Opinions, From the People You Trust

Choose the decision signal: point to the behavior or result you need to see and explain what decision it will change.

Decision signal

Are you seeing real signals or just opinions?

The call

Ask for behaviour, not applause. Otherwise feedback confirms what you already believe while real friction stays hidden.

Sharpen the decision signal with AI

This is a Launch idea, so there are two AI moves: first Sharpen the decision signal 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 and Make the output trustworthy.

New here? Let your AI do this with you. Paste your problem into 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.

Or copy this prompt into AI chat, replace the bracketed lines with your real decision signal and keep the instruction exactly as visible here. It helps you put your launch/decision-signal.md together by refining your three lines until two people would make the same product decision from them.

You are checking whether this decision signal is clear enough before you move forward.

Constraint:
The decision signal must be specific enough that two people would interpret the same evidence from it.

Example of the standard:
Vague: "We want feedback on whether people like the search results."
Sharp: "We want to see whether a content creator acts on a context-shaped search result in the same session, because that behaviour will tell us whether the context layer is adding real value or just adding steps."
The sharp version is specific enough that two people would interpret the same evidence. The vague one is not.

Working draft:
Signal to watch: [what behavior or result you need to see]
Behavior behind it: [what action creates that signal]
Decision it changes: [what decision it will change]

Task:
Decide whether this decision signal is specific enough that two people would interpret the same evidence. 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?
- Does it meet this bar: You can point to the behavior or result you need to see and explain what decision it will change

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.

There are six ways to work with AI across a build. This idea's AI moves are noted above. See Working with AI for all six and where each fits.

The same idea on a recipe card

At dinner, everyone says "lovely, thank you" to be polite, whether they mean it or not. What actually tells you is the empty serving dish and the guest quietly going back for a second helping. One is good manners, the other is real evidence.

Asking for signals not opinions is watching the second helpings instead of fishing for compliments. Name the behaviour you can actually see, what it would tell you and the decision it would change. "Do you like it?" invites politeness, but an empty dish cannot lie.

The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See the recipe card.

What it really means

A decision signal is not just more feedback. It is an observable behaviour or result that can change the next product decision. Until you can name one observable signal, one behaviour behind it and one decision it will change, the conversation will drift into opinion. AI can help summarise reactions, but it cannot turn vague feedback into evidence on its own.

Make the decision signal concrete

Compare the broad version with a version you can actually test.

Too vague: We want feedback on whether people like the search results.
Concrete enough to test: We want to see whether a content creator acts on a context-shaped search result in the same session, because that behaviour will tell us whether the context layer is adding real value or just adding steps.

The second version lets two people interpret the same evidence from it.

Opinions are cheap and mostly noise, people are kind. A decision signal is a behaviour you can count, like someone coming back unprompted, so you ask for signals not opinions and let what they do outweigh what they say.

Check the decision signal

Pass: You can point to the behaviour or result you need to see and explain what decision it will change.
Fail: If you are still asking for thoughts, opinions or reactions in general, the signal is not defined well enough yet.

Do not move into feedback collection or iteration work 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/decision-signal.md written and sharpened: the decision signal 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 decision-signal.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/shape-build-launch/launch/decision-signal.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 for why this matters across a whole build.

Risk and mitigation

Risk: Treating confident opinions as evidence, which can push launch decisions in the wrong direction while real user issues stay hidden.
Mitigation: Agree on one behaviour signal per decision and only change direction when that signal crosses the threshold you set in advance.

Key takeaway

Do not move forward until you can point to the behaviour or result you need to see and explain what decision it will change.

How to document your decision signal

Write your decision signal 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.

# Decision signal

## Answer
Signal to watch: [what behavior or result you need to see]
Behavior behind it: [what action creates that signal]
Decision it changes: [what decision it will change]

## 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
Signal to watch: The empty serving dish
Behavior behind it: A guest quietly going back for a second helping
Decision it changes: Whether this dish stays on the menu

## Evidence
The dishes that sold out quietly are the ones I kept, and the ones I only heard nice words about often did not last.

## Decision
Optimising for what people do, not what they say. Saying no to letting polite comments decide the menu.

## Risk
An empty dish could just mean it was first out or there was little else. Watch it across more than one meal.

## AI instruction
Judge this dish by the signal of an empty serving dish and guests quietly going back for more, not by their opinions. Let that decide whether it stays on the menu.

What now?

Apply it. Guide me turns what you are building into a prompt that walks you through this idea.

Get all 27. The guide is a free coffee-length read with the whole method. Join free and it is yours to download.

Get a hand. Work with me and we will work out together what is worth doing. The first conversation is free.