Make the proposal tangible, then define when to stop

Start with the behavior you want to change

I used to fill requirements with features and launch dates. After several rounds of documents, I would discover that everyone had imagined a different screen. Now I first describe who should move from which behavior to which other behavior, and in what situation.

For an illustrative CSV tool, I would write: “After importing data, the user can identify items that need checking.” Naming the behavior tells me which steps to prototype before I add every chart or promise automatic corrections.

Build a clickable shell

I then ask AI for a clickable shell: fictional data, no real services, and visible success, error, and empty states. I ask for the screen structure before the core actions. At this stage I care about the flow; visual polish can follow.

In the meeting, I let the other person operate it and watch where they pause or expect something different. I record those disagreements and bring them back into the requirements. A shared screen gives us a reference for discussing what the words alone had left open.

Define the stop line before seeing results

A working prototype still leaves the investment question open. I fill three fields: intended behavior, primary evidence, and stop line. I choose one main signal and state the baseline, observation method, and period. If the baseline is missing, I collect it with a small test first.

For the CSV example, we might agree to revisit the problem if people still cannot identify items to check after two rounds, or avoid expansion if every item needs a personal explanation. These are example conditions. What matters to me is agreeing before results arrive, rather than inventing another reason to add a feature afterward.

Ask AI to challenge the proposal

Before an important proposal meeting, I run a separate challenge round. I give AI the decision, claim, evidence, and constraints, then ask it to separate claims, evidence, and assumptions and identify three weak links. Missing evidence stays marked as missing; I postpone rewriting the slides.

Next I ask questions from the decision maker, implementer, and affected person. I turn the result into evidence to gather, claims to narrow, and stop lines to set, then decide what to change myself. This helps me see what I cannot yet promise. I check AI’s counterexamples, too.

Keep a record of what was agreed

After alignment, I record the agreed flow, unresolved questions, next validation, and owner. Before development, I add data handling, permissions, exceptions, performance, and acceptance criteria. The prototype shows the direction; the document preserves its boundaries. I keep them linked.

When presenting, I explain which data is fictional and which parts remain unimplemented. For other people’s data or unpublished material, I confirm the permitted scope and prepare only the necessary de-identified summary. Then everyone knows what we have and what the next step still requires.

← Back to all notes