Want better answers? Ask better questions!

Here is a simple question, right? Short and to the point!

So, what’s wrong with it?

Some immediate questions that pop into my head are

• What are you after?
• What is userlist.com?
• What is the problem?
• Why should I care?
• All of which could be answered in advance with a little care.

Bad questions only give you more questions.

So how could you ask this question in a good way?

Here is another example.

You can see that this is a much better question. This is what you would want people to ask you questions!

But how do you get from the first version to this one?

Let’s break down what was better with this way of asking questions

I provided some context

Here I explain the history of how we came to the place we are at.

If someone started just two months ago, they would not have this context, since they were not there when it happened.

Since every decision is taken under unique constraints that existed at that specific time, providing this up front is crucial to understanding your question.

Explaining why you should care

This is me “asking for your attention” in a way that explains why you should actually drop what you are focusing on and start focusing on what I want.

Or if you see that it does not affect you, simply ignore the message!

I clearly state what the problem is that I am trying to solve for; onboarding emails. Which means it is not “email deliverability” or “designing better emails”.

Providing some facts

In order to not demand that the person on the other side dives into code in order to get the full context and risk being distracted or derailed by poorly written code that definitely can be improved (you can always do that, right) she gets the relevant facts in the context I am trying to communicate.

It’s only relevant to the “Onboarding flow”, not the password reset emails that we also send out.

Summarise communication that happened somewhere else

Conversations can spark in a lot of different places. On a phone call, in another chat room, over email or when reviewing code. And that is great.

But it is a conversation that didn’t happen for anyone else!

So if you came up with something during that conversation, you need to summarise it for the people who weren’t there.

• What did you talk about?
• What was your conclusion?
• How did you come to those conclusions?

Be clear of what you expect from people reading your question

Showing that we actually did (a little) research communicates what we expect of the person reading it.

The word “Quickly” communicates that we didn’t spend that much time. So neither should you!

It also communicates where you are in your thought process. Are we almost ready to start building the feature or did we just start thinking about it?

Being explicit about what you want answers to and telling people how they can contribute is very important. You may think you have nothing to contribute to this topic, but you might have a friend you could ask?

If you want better answers, start asking better questions.