An empty dashboard can make a new project feel unfinished. Adding more features rarely answers the most urgent question: can one suitable person get a useful result? Start with a small promise and make that promise work from arrival to completion.
Choose one job your project can finish
For a fictional digital product, the job might be creating a simple weekly spending review. The first version could be a worksheet and a short explanation. It does not need accounts, social features and a sophisticated dashboard before someone can try it. It does need understandable instructions, working downloads and honest limits.
Write down who the project is for, what they must bring and what they should have when finished. Show an original example labeled as a demonstration. If a feature requires information the user has not supplied, explain that condition instead of displaying invented activity or fabricated success stories.
Make the first session usable
Test every step on a phone as well as a larger screen. Can someone find the starting point? Does the button work? Is the file accessible? Can the person recover from an incorrect entry? Give enough sample data to teach the workflow, clearly marked as sample data. Never mix fictitious purchases or members with real customer activity.
Manual help is acceptable during a small pilot if you disclose what is manual and protect participants' information. A concise email explanation may be more valuable than building a complex tutorial system too early. Set a realistic support boundary so a side project does not silently become an unlimited service.
Invite a few people with the actual problem
Seek willing participants in contexts where a relevant invitation is welcome. Explain that the product is early, describe the task and state any price or feedback arrangement. Let them decline. Avoid buying accounts, scraping contact lists or collecting followers who have no reason to use the work.
Watch for the first useful action rather than counting logins. For the worksheet, activation could mean completing a review and identifying one next step. Ask what was confusing and what they would otherwise have done. A friend's encouragement is welcome but should be recorded separately from an independent purchase.
Keep a small experiment ledger
| Record | Why it matters |
|---|---|
| Suitable people invited | Defines the context of the response |
| People who started | Tests the invitation and initial explanation |
| People who finished the useful task | Tests practical usability |
| Voluntary return or purchase | Provides a stronger, separate demand signal |
| Cash, hours and support | Shows the real cost of the test |
Suppose four people start and two finish. That is 50% completion among those four starters, with a very small sample. It is not proof that half the market wants the product. Write down the observed obstacles and test a focused improvement. If the task is naturally one-off, a lack of weekly use may be appropriate; judge return behavior against the actual job.
Decide whether to continue, change or stop
Set a time and cash limit before recruiting. Continue when people reach value and the next question is worth testing. Change the audience or promise when the problem fit is weak. Pause when the project exceeds your available resources or repeatedly fails to help. Use the first-experiment planner to turn the next uncertainty into one bounded test. Zero users is a starting condition, not a reason to manufacture evidence.
Sources and useful references
Keep learning
- What to do when your new community has no members
- Starting from scratch to one million: build a testable path
Your next move
Define the first useful result, invite a small suitable pilot group and record completion, feedback, hours and costs.