What are they “really” asking?

My previous manager taught me an important principle for navigating the work place: whenever somebody asks a question, think about what they are really asking. This came to mind because I recently moved to a new team full-time at work and one of the ceremonies that they have is a weekly status/progress/management type of meeting where I get asked this question:

“What is the feeling from QA?” [this from product manager regarding the project that we are working on]

I normally create a quality report that tells the story of the product state, but in these meetings nobody cared about any of that. I was asked for a some form of statement. My first reaction to these types of ambiguous questions is to feel the heat of being put on the spot and quickly attempt to synthesize the vast testing space into a judgment in seconds. This valiant effort is quickly followed by confusion as my mind races to evaluate the thousands of ways that I can tackle the answer.

My natural solution at this stage is to simplify the terms of the problem by asking clarification of what the person means. Is there something specific that they want me to focus on? Naming examples of what I can elaborate on helps. However, what I discovered is that most product managers are as confused as I am and don’t really know what they are after with these questions!

This triggers my third response: suspicion. Are they just asking for the sake of asking? Are they really going to do anything with this information? This bias comes from years of cases where no matter what is the assessment of QA, the plan remains unchanged, leaving the suspicion that the decision has already been made and voicing my opinion is just a formality.

On good days, serenity brings me to my final reaction: humbleness. Product managers have a very difficult job, they never have complete information and have to balance many things to make a responsible call. Most of the times all they have to go with is their emotional reaction to something I say. That’s a tough position.

What I do now is make sure that I can always summarize my test report into these 3 parts: a) top two important issues that are active, b) top test activity that we have not done yet, and c) top test activity that we have had to cut. Don’t fret too much, in my experience, product managers have a difficult time reacting to these (unless the risks are emotionally charged). Instead, the most important part is that I follow these statements by asking the product manager if there is anything else he/she wants to know. I think that this helps form clarity of what is important in the eyes of the manager. Remember that they are the ones that are going to make the ship/no-ship decision at the end and the more I can help this person be aware and articulate what information he/she feels is important the better. Make sure to address these in the written test report that you send later (where it can be read in calmness).

Lastly, I never do the job for them. I do not answer questions related to ship-readiness, if we’ll be able to ship on time or if we should block the release. This is the product manager’s job (or if not them, someone higher up). If he/she wants my opinion I’ll be happy to give it over a cup of coffee. I like lattes.

- Federico