A beta is an experiment, not a launch
The most common way to waste a beta is to treat it as a quiet launch: invite a crowd, collect signups, count the congratulatory messages. That produces applause, and applause is not evidence. A useful beta is an experiment with a question written down in advance. Something specific, like: can a new user reach the core action in under two minutes without help, or do people who manage rental properties actually want automated reminders. One beta, one question. If you cannot write the question, you are not ready to run the test.
Recruit for the problem, not the relationship
Five to fifteen people is enough for the qualitative answers a first beta exists to find, but only if they are the right people. The right person already has the problem your product solves and is already doing something clumsy about it - a spreadsheet, a workaround, a manual routine. Friends and family are the wrong sample: they will work harder than a stranger would, forgive bugs a stranger would abandon, and say kind things a stranger would not. Find your testers where the problem already lives: communities, forums, customer lists from a previous product, or direct outreach to people whose job description contains the pain.
Watch, do not demo
The instinct when someone tries your product is to help. Resist it. A demo proves the product works when you drive; a beta needs to show whether it works when the user drives. Sit with testers, in person or on a call, give them the goal and not the instructions, and stay quiet while they try. Where they pause, what they misread, which button they hunt for - that is the data. The tester who says "this is great" while failing to complete the core action has told you something far more useful than praise.
Ask about the past, not the future
When you do talk, avoid hypotheticals. "Would you use this?" invites a polite yes that costs nothing and means nothing. Ask about behavior that already happened: how did you handle this last week, what did it cost you, what did you try before. Questions about past behavior get facts; questions about future intentions get compliments. Rob Fitzpatrick's short book on customer conversations, The Mom Test, builds its whole method around this rule, and it is the single highest-return hour of reading before a first beta.
Close with a decision
A beta that ends in "people seemed to like it" has not ended. Write down what you saw, separate the three kinds of signal - people completing the core action, people asking when they can pay, people returning without being reminded - from the noise of compliments and feature requests. Then make the decision the beta was for: iterate on the biggest stumble, narrow the product to the one use case that worked, or stop. A beta that produces a clear stop has saved you a year. That is a successful experiment, whatever it does to your roadmap.