Choose a task, not a feature list

Start with a person in a real situation: a client requesting a service, a coordinator assigning a job, or a customer choosing a booking. Write down what triggers the task and what a successful finish looks like.

For a client portal, the question might be: can a customer understand the proposal, approve it and find the next step without asking the team? That is narrow enough to demonstrate and specific enough to observe.

Make the decisions visible

Use realistic fictional examples. Empty dashboards and placeholder text hide the difficult decisions. A proposal needs a scope to read; an approval needs a consequence; a project status needs to say what happens next.

Include one meaningful exception. For example, what happens when the proposal needs a change? A prototype does not need every edge case, but it should expose the assumptions behind the main journey.

Ask people to do something

Give a potential user a task rather than a tour. Ask them to find the proposal, explain what they are approving and show where they would check progress. Avoid telling them which button to press.

Record where they hesitate, what they misunderstand and what they expect to happen. Separate observations from suggestions: ‘could not find the delivery date’ is evidence; ‘add another dashboard’ is one possible response.

Know what a demo cannot prove

A smooth demo does not establish demand, willingness to pay, security, integration reliability or production performance. Those need different evidence: conversations with buyers, real-world trials, technical investigation and engineering checks.

Our free demo uses fictional data for one agreed workflow. It is a way to review direction with you. It does not include recruiting research participants or claiming that a market has been validated.

Turn the review into a next decision

Finish with three lists: what was understood, what needs changing and what remains untested. Use them to revise the first-version scope. If the key assumption is still uncertain, resolve that before expanding the feature list.

  • Write the main question before the demo starts.
  • Observe the complete journey, not only the attractive screens.
  • Keep untested assumptions visible in the architecture plan.
  • Agree a paid build only when its scope and acceptance criteria are clear.