So they want to run lean by getting early feedback, but they don’t want that feedback in the form of bug reports. I find that very confusing.
I’m entirely in agreement with you. Without any process or structure it’s a waste of time and energy. If they want feedback at all then the minimum that’s needed is some way to record the problems that are found. If they want feedback on all of the functionality then some way to ensure users have explored all of the areas is also needed. If they want directed feedback about a particular area or quality criterion then direction of the users on the sandbox is also needed. You could sprinkle in screen recording, note taking, exploratory charters, product area checklists, risk-based testing… It’s really a case of purpose. Someone needs to shout “why?” at someone else and then hopefully the fog will clear.
Consider what’s best for you, your end users of the software, and whoever signs your paycheck. That’s a useful starting point. If it would serve you better to give fuller feedback than a checklist of tasks (scenarios the users will have to perform on this new functionality) might be helpful. If it would serve you better to give more accurate feedback then a charter or questionnaire based on quality critera might help (“How easy was it to X? Did it install okay? Was it fast enough for you?”). And so on. The HTSM is a really useful guide for this sort of outside-in risk analysis (http://www.satisfice.com/tools/htsm.pdf).