Framework: How I ask questions.

I know you must be thinking, this is ridiculous. Who writes something on ‘how to ask questions’ but bear with me here as you might find something of value, and if nothing else you can tell me I am wrong ;)

From early on, we are taught to always question things we don’t understand. This has slowly transitioned to getting your answer from Google, books, experts or anyone in the relevant field. The value of the answer took precedence over the question (and rightly so), but this has now transitioned to how quickly we have answers ready in anticipation to the questions that never come. This happens frequently while building products & businesses - why reinvent the wheel by asking questions that have answers already?

In my experience, solutions are often given before the problem has been spelt out. Hence, I try to focus on problem discovery separately through the requirement gathering process. You may not be able to solve the issue immediately, but you’re building provisions along the way.

When building products & services with different teams, I’ve noticed that the initial interaction sets the structure for the rest of the engagement (most of which are long term relationships). While it is in my best interest to get the solution as soon as possible, the steps taken to reach that output need to be thought through as it has direct influence on how the solution is formulated.

When I started learning about the requirement gathering process, I found that a lot of my questions were being trivialised or didn’t result in a response that was satisfactory. In time, I learnt that it is a continuous process and the more I spent understanding, the less I spent asking “trivial” questions. I’d ask questions that helped build rapport where even questions lacking depth were  relevant.

The process of gathering requirements can be bifurcated into many slices. I don’t claim to showcase the best way but “a way” I have used to reach that sweet spot of knowing just enough to build a product successfully. There is a great deal of research published around asking the right questions or how to ask questions, which made me think that there is more than one way to cook an egg.

In this setting, asking the right questions displays strong business acumen and every step after this has a foundation built on direction rather than simple “problem and solution” tactics.

So here is a basic framework that might help you elicit the answers you are actually looking for:

: When you put a question across can you identify where on this radar the question scores highest and lowest? If you can, then you have a better chance of getting the answers you are looking for.

Measurability

Refers to how likely the answer provides quantifiable details, considering the accuracy as well. There is a higher probability that questions with a quantifiable or numeric component require accuracy. While it may look like you’re getting 2 for the price of 1, you may want to check the authenticity of this data for safe measure.

e.g: How have you managed to keep user retention steady?

e.g: Why is price tier X the most affordable for SMEs?

Complexity

Refers to the difficulty of answering this question given the circumstances. This can be due to a lack of information or bias. The reason why I’d focus on asking a question that scores high on the complexity metric is to highlight different factors or properties that have not been considered. This is most common with products & services operating in or around finance or when looking at the macro operations of a product/service.

e.g: Have there been any steps taken to ensure the Product X is functioning legally? - Ultimately, understand and address what the dependencies and legal complications, if any, are.

e.g: Is there a plan in place for optimising content consumption on the platform specific for mobile users?

Focus

Refers to how relevant the question is. I know it sounds obvious to keep questions relevant but it is often missed; in some cases the question may not even be valid. Consider the stage the product is at when putting questions across. In the event I am scoping the future of the product, I tend to ask questions that look at a 3 year horizon and I clarify the intent so the validity of the question is preserved.

e.g: Why have you decided to pivot towards these features?

e.g: Are you planning on increasing the usage & access rights for users?

Emotion

Refers to how well a question appeals to the person’s sentiment towards a product. There will be questions that score on the emotion metric across the requirement gathering process but you’ll find it to be more prevalent during design discussions.

e.g: What indicators drove you to take the business decision?

e.g: Why did you feel it is necessary to bring a different appeal to the website?

Assumption

Refers to how the questions anticipate an output but do not have clarity on the exact details. Assumption based questions are usually helpful when you want to share an idea or an approach that might help the business/product.

e.g: How frequently are you updating the recommendation engine? - The assumption here is that the recommendation engine is being updated but needs clarity on the frequency.

e.g: Have you considered storing data locally for improved usage?

Finally, avoid information overload: Don’t ask more than you need to do, less is more. Gathering information incrementally will improve the overall efficacy in the initial stages. While asking all the questions at the beginning is also an approach, a more tactful method is where you ask only what you need and consider the rest to be kept in a black box, which you’ll discover.

This framework has been tweaked over time ,and if you do feel something is missing, drop me a line and I’d be happy to improve this further.