Choose the assumption before the feature list

Ask what you need to learn: whether people complete the workflow, return to it or pay for the result. Identify the customer and setting for the test. A prototype may answer a usability question without supporting live operations. Match the test format to the decision you need to make.

Design a complete narrow workflow

Map the customer’s task from start to finish. Build the steps needed for a useful outcome, and defer unrelated features. Include error handling and support paths. A small product can still need access controls, reliable data handling and backups when used with real customer information.

Use manual work transparently

A founder can manually review requests or prepare outputs while testing demand. Account for that effort when evaluating delivery economics. Explain material human involvement where customers could otherwise misunderstand the service. Avoid accepting a pilot volume you cannot support safely.

Review evidence before expanding

Choose a review date and assess completed tasks, customer feedback, repeat usage and delivery effort. Low usage may reflect onboarding, timing or the wrong problem. Investigate before adding features. Decide whether to improve the workflow, test a different offer or stop.

Your next steps

  • Name the assumption being tested.
  • Define one end-to-end customer workflow.
  • Set minimum data and reliability requirements.
  • Track manual work and exceptions.
  • Choose a review date and decision criteria.