I met a friend last night out at a restaurant he'd never been to. To tell him where to go, I said, "from your office, walk down Boylston until you hit Dartmouth, and make a right. Then walk down Dartmouth and it'll be on your right." This was a mistake. You see, my friend wasn't coming from his office; he ran an errand on the way and all of a sudden my directions weren't very helpful. What I should have said was, "it's at the corner of Dartmouth and Clarendon." That way, no matter where he was, he could figure out the best way to get there. I told him what to do, not what my goal was.
This applies to testing, too. When the product manager asks me, "can you please run a performance test in configuration foo?", that's telling me what to do. It might be right, or I might get some element of it wrong and basically waste the test (and who has time to waste!). If instead, the product manager wants to "run a performance test to update this analyst with the amazing benefits of our new feature foo", that's telling me what you're trying to accomplish. With that I now know to run the exact same test as I did the last time we published results for that analyst - same data sets, same hardware, same system configuration - with the exception that I'll make sure feature foo is enabled. Because I understand what the product manager was seeking to accomplish, I'm much more likely to provide useful test results.
Don't tell me what you want to do. Tell me what you're trying to accomplish.
I'm much more likely to do the right thing, if I understand the end goal. So if I hear something that sounds like a task to me - that sounds like telling me what to do - I'll probably respond with something like, "Just so I make sure I get the information you want, can you tell me about what we're going to do with the results?" You save yourself a lot of time and test repetition that way.