I had a list of questions I expected in the demo and knew I wouldn’t be able to answer; questions about configuration of this and that, system architecture, product road-map, etc.
I shared the list during the dry run, asking who would take ownership for each in the meeting proper. This vetting of the list helped make sure we had the right people in the meeting, and that answering the questions was quick, helpful, and professional.
Someone asked where the questions came from. “I made them up.” Hilarity ensued. “Seriously. I think these are the questions they’ll have.”
We’re so programmed to solve problems, to score well on the test, that these were presumed a list of requirements- yet another homework assignment- from the customer. And by answering formal questions with the best answers, we’ll be picked.
No.
This list of questions was ours. It was necessary. It was the result of thinking about the customer’s situation and what they’ll want to know, how they’ll perceive the solutions, how they’ll attempt to grasp our something different from what they have today.
The questions aren’t requirements. The questions are the poking and prodding the customer will do to understand our message.