An MVP for an internal team needs a task it can complete. Reducing every feature equally can leave a small application that still cannot support a full piece of work.
Define the release around a task
Choose the participating role, starting input and required output. Select the records needed to test that path. Include one meaningful exception so the trial is not limited to perfect data.
For example, a request workflow needs a path for missing information as well as a path for a complete submission. It does not necessarily need every future reporting view.
Keep a deliberate exclusions list
Place requested features beside the task they support. If a feature serves another workflow, keep it outside this release unless it is a genuine dependency.
Record how the team will handle excluded work during the trial. That makes the temporary cost visible and prevents an omitted feature from being mistaken for a delivered capability.
Review scope against use
Test with the agreed dataset and participating role. Capture where the person cannot complete the task, where they need help and where the result requires correction.
Use those observations to choose the next change. A business-pain backlog keeps later requests connected to evidence instead of expanding the MVP by default.