It can depend on context, but generally I find that small sample size testing like that is most useful while the development is in early to mid stages. So the most valuable feedback tends to be that which will validate or invalidate assumptions about which tasks are most important to do sooner rather than later. On all but the smallest projects, there will always be many things to do as well as uncertainty about what should be done first, where the most ideal trade-offs lie, etc. The larger the gulf in domain expertise between developers and users, the more assumption validation and learning there needs to be. More metric-oriented reporting tends to be less critical at this stage where the product is churning rapidly, and is not terribly reliable for small sample sizes anyway.
I would try to specifically highlight things that answer the question: "What part of the product needs the most immediate attention to unlock value for the customer and/or reveal how best to expend dev resources for the next work cycle."
Be aware that that this can sometimes run into political issues, particularly when testers are expected to just report findings and others are left to make strategic determinations about resource allocation. But at the end of the day that is where the essential value of early cycle rapid testing lies. It can be beneficial (and humbling!) to have us developers ourselves silently observe these small early test sessions periodically, and not just rely on reports of test observed by others.
Typically, at the end I also like to ask what the participant felt were the "highs" and "lows" of their experience. Their answers will sometimes not match what I would have assumed based on my observations of their session, but those cases almost always provide key insights into the how a user's perspective, expectations, and mental model differs from those actively involved with the project development.
