Start with one person doing one job
Describe who the first version serves, the situation they are in and what they need to finish. “A platform for all college events” is too broad to guide a first build. “A club organiser collects registrations for one workshop” gives you a workflow to examine.
Write the beginning and end of that workflow. What information arrives? What result leaves? What happens if something goes wrong? Talk to people who currently do this job before deciding which parts need software.
Choose a complete, narrow slice
List the steps a user must take to reach the outcome. Mark each as essential for this test, possible to handle manually with permission, or safe to postpone. An attractive screen without a complete path may teach you less than a plain but usable service.
Example: an event pilot may need an event description, a registration form, a confirmation and a way to correct an entry. A recommendation feed, badges and elaborate dashboards can wait unless they are central to the assumption being tested.
Manual delivery is not an excuse to conceal what is happening. Tell participants what the service does, handle their information responsibly and avoid promising an automated capability you do not have.
Define what “done” means before adding polish
- The intended user can complete the core task.
- They can understand what happens next.
- Likely mistakes have an understandable recovery path.
- Someone owns support during the test.
- The team knows what evidence it will review.
These checks are a starting point for a small pilot, not a universal production-readiness standard. A product handling payments, health information or other sensitive activities needs additional domain-specific work.
Keep a parking list with a reason to revisit
For each postponed idea, write the evidence that would justify building it. “Add team accounts if pilot organisers repeatedly need a second person to manage registrations” is more actionable than “team accounts later.”
After the test, compare observed difficulties with your parking list. Do not treat every feature request as a commitment. Use the experiment planner to decide which uncertainty deserves the next slice.