Why To Absolutely, Positively, Never Let the Conversation Get Away From You

Here’s the scenario: You walk in starry eyed. A fresh start. A new challenge. An opportunity to learn and share knowledge. The introductions fly past and, if you’re lucky, you remember the name of the meeting’s facilitator. Kerryn. Or was it Karin? Ready – set – go! The conversation kicks off. Most of the stakeholders around the room already know each other. More importantly, they know the business.

No question, no gain

From the onset it’s evident that the project is about replacing the CDS with the QLT. Before long a seemingly uninterested attendee enters the room. It’s Gary from RGM. You remember that RGM is the department that is strongly opposing the project. It’s ok though, because if the system can adapt to the existing LGM and then bypass whatever it is that’s stopping it in GDR, the benefits will greatly outweigh the resistance put up by RGM. Obviously it’s all down to the timing though, because project Wolf is underway and creates a major dependency for this project. The session draws to a close. You look around the room and the stakeholders seem satisfied. It looks like they got exactly what they wanted from the session.

You look down at your notepad and there are a bunch of acronyms, question marks and additional names that were picked up in conversation. Right, it’s up to you. Go forth and do the analysis and deliver something awesome by Friday. Thanks.

This is unfortunately, a position that many analysts find themselves in too often. I know this, because I have had this conversation many times before.

Question all, assume nothing

Let’s replay this scenario. The conversation kicks off and acronym one rears its ugly head. You interrupt the conversation and sheepishly question: “CDS?”  You receive the anticipated ‘idiot’ glare from across the room, followed by: “Yes, Customer Data System. You know, where we keep the customer data stuff…” That’ll teach you to ask stupid questions.

After the fall, you get up, brush yourself off, and brave the next question. “What type of customer data?” “Well, it stores names, addresses, telephone numbers…” There’s a brief hesitation – “And relationship information” shouts a voice from across the room. “Does it?” questions the original attacker. “Of course it does; that’s where we get all the information we provide Marketing.”

Hmm… the attacker needed help this time round. Perhaps they don’t know everything. “What type of relationship information?” you ask. The original attacker cautiously answers, “We store information related to the type of products customers are interested in, so that Marketing can target them specifically.” You quickly fire in the next question, “Is that information collated into specific groups, or is it a free text field?”  There’s a moment of silence. You look around the room in anticipation for an answer. Nothing.

Questions can be more powerful than statements

The question is parked and the conversation swiftly picks up again. Acronym number two comes up and you ascertain that QLT stands for ‘Quick Leasing Tool’. It’s the name of the project after all. The meeting room door opens and a seemingly uninterested attendee sneaks in. There’s a pause and the facilitator points out that this is Gary from RGM. Notice how easily the next acronym snuck in there? You guessed the second one and it’s time to confirm this one. “RGM… Marketing? “Yes, Retail Group Marketing” Gary confirms.

Excellent, we’re making progress. You remember that he’s from the department that is strongly opposing the project. “Can Gary answer the question we parked earlier?” you ask. Gary wraps his mind around the question and immediately expresses his frustration. “It’s a free text field. It’s amazing how many ways there are of writing the same thing!” “How do you target specific customer groups from this information?” you ask. Gary shows more frustration as he passionately explains how a single employee spends their time sifting through the information to identify potential target groups. This is why the communications to customers are always late.

“Why don’t we collate this information into specific groups asks the facilitator?”  Excellent, they’ve asked the question that you couldn’t, because you don’t want to make promises on functionality this early on. Gary explains that this wasn’t thought about when the system was originally designed in 1992. “You mean we can change the way this is captured in the future?” he asks. Gary’s interest in the project has suddenly increased – and so has your value add. “Yes” answers the facilitator. “It’s why we’re implementing this project, to improve the quality of data we get from the system.” Have we just changed Gary’s position from ‘strongly opposed’ to ‘mild interest’?

Stupid questions are only as stupid as the assumptions that support them

So what does this story demonstrate? Part of an analyst’s job is to bring previous project experience and innovative thinking to the table. By asking the ‘stupid’ questions, they break down assumptions and demonstrate to stakeholders why obvious questions aren’t as instinctive as they seem at face value. Stupid questions are only as stupid as the assumptions that support them.

As an analyst you need to challenge what you hear. You need to seek clarity when you’re unsure and most importantly – never assume. Never ever assume. You’d be surprised how often I have asked a question, only to hear someone say, “Thank goodness someone else doesn’t know,” or “I was about to ask the same thing.”  If you don’t know something, it’s quite likely that someone else around the table doesn’t either. And if you are the only one that’s learning from the question, then at the very least you’ll be able to follow the rest of the conversation.

Never be afraid to question, never be afraid to challenge assumptions and never be afraid to analyse. Ultimately, the analyst needs to understand – that’s why they’re there. The only stupid question left to ask is… Why aren’t you doing this already?

Learn More About Asking Stupid Questions

Here are a few articles from our archives about this topic!

The Only Stupid Question Is the One You Don’t Ask

Why Terminology is Important

How I Take Meeting Notes and Facilitate the Discussion Without Driving Myself Crazy

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.


  1. Nik Gebhard says

    Thanks for all the comments; I’m really glad you liked the article.

    @Doug, I often find myself in a very similar scenario. I ask the question and then – for a very brief moment – second guess myself. In most instances, as soon as I’ve received the response, I’m pleased I asked the question after all.

    @Steve, Your cardinal rule really resonates with me. I always find it best to find the fine line between demonstrating ‘naivety’ and showing stakeholders that I’m there to learn and understand their business. Hopefully this prompts them to give me the answers that I require.

    @Michelle, I think I know the exact moment that you’re talking about when “the business realises that they have questions too”. I’ve increasingly become conscious of that moment when stakeholders gain a renewed interest in a project and start asking the questions that they should be asking.

    @Ron, Thank you for your comment. I believe that this is very important training. Without that imperative clarity that you talk about, there will always be assumptions. Perhaps the naive questions become naïve assumptions, the stupid questions become stupid assumptions, etc.?

    Best Regards

  2. Great article Nik.

    I have trained thousands and thousands of people over the years and mentioned asking questions; naïve questions, stupid questions, tough questions. Only then will the project scope become clear, roles clearly identified, risksk identified and managed etc etc. We need to train people in this skill……this article confirms my belief. Good artilce Nik

  3. You are right Michelle. The problem is that the business assumes we know all about the technology because most of the business analysts report to IT, and the developers and other technologists assume we know all about the business, because that’s our first name. We are many times considered to be a subject matter expert by both sides even though we go out looking for the SME to get the information. And, indeed, if we do our job right we probably will know more about how a business process operates from start to finish than anyone working in the process. However, we have to start with the “stupid questions”. It’s an unfair conundrum, but that is one of the prices of being in the center of the organization.

  4. Michelle Swoboda says

    It occurs to be that I continually tell the business that “there are not stupid questions” – why does that not apply to us too? We have a learning curve and we need to use it. I would rather ask the question than be caught out later with missing or faulty requirements. 🙂

  5. Duane Banks says

    I’ve come to the conclusion that the role of the BA requires more humility than that of perhaps any other role in the corporate world.

  6. Duane Banks says

    This is an area of improvement for me. Though I will ask “stupid” questions, it sometimes pains me to do it:).

  7. Disha Trivedi says

    Excellent, Excellent, Excellent article. My initial reaction was, “Gosh, I had wanted to write about this”, but I doubt I could have said it so well. So thank you for getting the point across, and doing so with great creativity 🙂 and I am glad there is someone else (and from the comments, I can see many more), who recognize the importance of asking the questions.

  8. Michelle Swoboda says

    Nik, impressive article and I really enjoyed it.
    We have all been there – why are we worried about asking the stupid questions? We travel so much further when we do. I could actually see myself in that room with you and your team. I love it when the business realizes that they have questions too.
    The question I have to remember and learn to ask is ‘why?’

  9. Rather than “stupid” perhaps we should call it “listening naively”. We admit our lack of knowledge or at least do not expose our knowledge to the people providing the information. There is a cardinal rule: If they think you already know the answer they won’t give it to you.
    In the movie Philadelphia, Denzel Washington played a lawyer who had a very complicated health insurance case to litigate. In depositions and in the courtroom questioning witnesses he constantly used the phrase “tell it to me like I’m six years old”. He knew and fully understood the answers, but he wanted to make sure everyone else, especially the jury understood.
    Same approach applies to business analysts. We need to leave our egos at home. We are not really being paid for our knowledge, but for our ability to acquire and analyze information to produce solutions.
    Asking for someone to clarify or elaborate on a topic we know might result in information that we didn’t know. Assuming we already know it, we don’t ask the question, or listen carefully, or ask the follow up question, and the new information is lost.
    Good post Nik.

  10. Michael Hendon says

    Nik –

    This article inspired me to read your others. This is the first business analysis related article that has ever had me in hysterics. I particularly enjoy the way you make this skill sound ‘nonchalant’. If every analyst approached a project with an open mind and asked the ‘stupid questions’ – as you put it – I reckon their productivity and delivery quality would increase substantially.

    You’re right to claim that this is an ‘obvious’ skill to have, however, how many analysts actually step forward and admit that they don’t know something? I run a business unit for a bank in the UK and, if the BAs that we brought in would admit that they don’t fully understand our business, we would be in a much better place with project deliveries. I’m going to be distributing this article to the BAs within our bank.

    Thanks again for a refreshing view.


  11. Doug Goldberg says

    Ha! Well said Nik!

    I absolutely hate and love this phase of the projects I’ve been on and similarly refer to it as my “case of the stupids”. What a temptation it is to crawl under the conference room tale and hide from my own ignorance, but what a reward when fighting that urge to ask the unaskable questions.

    Not only does an analyst’s effort to query the audience reap more knowledge, but it also shows the stakeholders that the analyst is interested in the right answers and is not willing to accept ambiguity or ignorance.

    Nice post!

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)


Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.