The purpose of a pilot is to generate information you do not have, in a context where acting on that information is still cheap. A soft launch is about risk management. A pilot is about learning. Those are different goals and they produce different designs.
Start with the questions. What do you not know about this program that would change how you run the full rollout? The pilot is designed to answer those questions. If you cannot name the questions before the pilot starts, you are not running a pilot. You are launching with a smaller audience.
The questions that matter most are usually about adoption and integration, not about the technology. Does the process work for the people it is supposed to serve? What does the support load look like? What breaks when this interacts with systems that were not in the design spec? Those are the things you find in a pilot and fix before they are multiplied across the full rollout.
Define the pilot success criteria before you start. Not success as in nothing went wrong, success as in you have answers to the questions you designed the pilot to answer. A pilot that surfaced three significant issues and produced clear fixes is a successful pilot. A pilot that produced no findings is either a sign of a clean program or a sign that you were not looking hard enough.
Time-box the pilot and resist the urge to extend it. Extension usually means the team found something uncomfortable and needs more time before committing to the finding. Name the finding and move on. The pilot is not supposed to be perfect. It is supposed to be informative.