Method / 01Ask the harder question.
Start by defining the problem, the people affected and what evidence would change the team’s mind. A compelling answer to the wrong question is still the wrong work.
A useful question is specific enough to investigate but open enough to learn from. It names the situation without deciding the solution in advance. It also makes assumptions visible: who experiences the problem, what existing work already addresses it and why a new intervention might be necessary.
Before building, write down what would make the team revise, narrow or abandon the original idea. That is not weakness. It is a sign that the project can learn.
Evidence / 02Evidence before performance.
A clear demonstration can communicate an idea; it cannot replace testing. Separate what the work shows from what the team hopes it will eventually prove.
Evidence should be proportionate to the claim. A conversation can reveal a perspective. A small test can reveal how one component behaves. A prototype can reveal interactions or technical constraints. None of those automatically establishes broad effectiveness.
A strong presentation makes that boundary visible. It tells the audience what was observed, under which conditions, what remains uncertain and what test should come next.
Prototype / 03Build to learn, not to impress.
A prototype is a question made tangible. Its purpose is to expose assumptions, invite useful criticism and guide the next test.
The right prototype is not always the most complete one. It is the smallest appropriate form that allows the team to study a meaningful uncertainty—technical feasibility, user understanding, safety, access or the logic of the proposed system.
Document what the prototype was designed to teach. Then record what actually happened, including the parts that did not support the original direction.
