Start with the question, not the feature list
An MVP should help you learn whether a specific audience will use a product to solve a specific problem. Write that question in plain language before discussing screens or technology. For example: can a training coordinator schedule a course and manage enrolment without a separate spreadsheet?
Choose one primary user and one complete journey. A small product still needs a usable beginning, middle and end: access, the core task, confirmation and a way to recover when something goes wrong.
Separate the essential from the uncertain
Sort proposed features into three groups: required to complete the journey, required to operate it responsibly, and useful later. Permissions, basic error handling and data protection can belong in the first release even when they are not visible in a sales demo.
For each uncertain feature, ask whether a prototype, interview or manual process could answer the question before you commit to building it. Record deferred ideas with the assumption they depend on.
Define what learning looks like
Agree a few observations that will influence your next decision. These could include whether people finish the core task, where they ask for help and whether they return when the need arises. Avoid collecting metrics simply because a dashboard can show them.
Before development, document the scope, acceptance criteria, integrations, owners and dependencies. Keep some capacity for feedback. A focused release gives you a better starting point for iteration, but the evidence still needs to be interpreted in the context of your users.