Art of asking questions

As a new PM starting out in a new industry, how do you ask the most important questions when understanding requirements? I’ve gotten feedback from devs I have a lot of questions.

14 Likes

If you’re both new to PM and new to your industry, you’re much better served asking more, not fewer, questions.

You’ll just want to message that your job requires you to deeply understand your customers and the problem space.

Also, reflect on how you’re asking the questions (i.e., tactfully, and it can be better to block out question time with the team instead of sending them a constant flow all day, which could be disruptive for their workflow).

Lastly, accept some personalities may simply not be super receptive to questions.

13 Likes

@RohitKumar, You sir, have written the perfect reply!

12 Likes

Agree on all the points. Nicely done.

12 Likes

Some tips I’ve found useful:

  • State up front why you’re asking the question and the goal you’re shooting for with the answer (e.g., what will you do with the answer, if it isn’t just for knowledge seeking.) this provides context
  • If you’re asking on behalf of someone, say who that is and, if you can, why they are asking. This provides useful context.
  • Commit to documenting the answer, even if only for yourself, to avoid repeat questions as much as possible
  • Summarize any work you’ve done to find the answer yourself. This shows effort and initiative and that you’re making use of any resources (wiki, etc) available before asking someone, which indicates respect for the other person’s time
  • Ask how the devs would like to be asked questions. My tech lead provided feedback he wanted me to post questions in our team slack vs DM’img him, to give other devs the chance to answer and to absorb the knowledge themselves (and also, let’s be real, save him some effort, which is totally understandable)
  • Thank whoever answered the questions. If they go above and beyond in providing an answer, or they answer a lot of questions in a short time, or something for a critical project — acknowledge that extra layer.
11 Likes

@NathanEndicott, The first bullet was one of the most important things I learned as a new PM. Giving context as to why you’re asking as well as the goal is especially helpful to whom you’re asking because as a new PM, you may have not asked the question by itself in a way that would get what you need, especially from an engineer.

10 Likes

Another thing I would add is to show gratitude for the information you are getting. And to align with the first bullet point, let the stakeholder or dev you are asking a question know why you are asking it and what you will do with the information.

I also try to consistently provide a summary of the information I got and how it answered my question. If the information helped you clear a roadblock or make a solid decision, always call that out because it shows the other person that their information and time was valuable.

It’s all politics, but I always tell my team the PM job is 80% politics and 20% skill.

9 Likes

You’ll learn what questions to ask by failing to ask them once, and wishing you had.

8 Likes

If you’re getting feedback from devs that you’re asking a lot of questions, then it’s possible that you’re asking irrelevant questions to the current topic (that derails the original conversation) or you’re asking questions where you could have learned by doing homework on your own (e.g., you ask what does clicking on button A do when you could have tried out the product itself). Devs love PMs who are proactively learning about the product, tech stack, org chat, influencers etc.

I would split your questions into groups - execution, strategy, product knowledge. Execution level questions are fluid - each meeting might trigger new set of questions. Nothing much you could do other than just ask questions and/or find the right POCs.

For strategy and product knowledge, you can schedule time with the team to go through set of questions. That way, you don’t disturb them randomly or derail conversations etc.

In short, organize your questions and be proactive on learning.

7 Likes

Ask questions away but frame that you’re asking to understand and not to doubt.
Like:

“Apologies if this is a stupid question…”

“I’m sorry but I’m being a bit slow, could you help me understand this…”

“I’m sorry going over on this again but can I recap this to you to make sure I understood everything”

And so on…

6 Likes

Definitely frame it as trying to understand, and even better, be specific about what you’re trying to understand, and why.

But also, definitely don’t apologize for asking questions. It’s required of the job.

Instead of apologizing up front, thank the answerer for their help afterwards.

6 Likes

@AmyWalker, I guess I’m becoming too naive. In my view apologies disarms the answerer and preempts the feeling the conversation might create. I like the approach, but I understand it’s not everyone’s cup of tea or culture!

6 Likes

Haha yeah it could be cultural, or even down to personal preference. Pre apologizing annoys me, BUT it’s because I struggle with it myself and have tried to train myself to not do it. There are definitely times to apologize, but in my view just trying to do your job well isn’t one of them. Just my opinion.

5 Likes

Would agree better to apologize than not apologize even if other cultures find that strange. But also stating your purpose politely is the alternative as apologizing too much is also annoying.

4 Likes

I’ve found I need more teeth than being the apologist gets me. YMMV, but better to thank, be humble, always accept you opinion is largely rubbish and get data or sources to support you. Basically, try always be armed for the COO casually saying, ‘so why did you do that?’

3 Likes

This conversation reminded me of a good article about getting buy-in, particularly the section about Presence where apologizing or otherwise diminishing your ideas or questions reduces your ability to get buy-in on ideas: Getting buy-in - by Lenny Rachitsky - Lenny's Newsletter

2 Likes

I advise my team to not apologize or seem like they’re “bothering” someone because it is that person’s job to provide the information they have. If the team member made a mistake, wasn’t paying attention, or has to ask multiple follow ups to the same question 3-4 times that’s a different story, but immediately apologizing or making yourself seem like a burden immediately puts the power in the other person’s hands.

1 Like

Read The Mom Test by Rob Fitzpatrick, it will help you a lot.