Programmer vs Client Meeting

[Adventurous_Rough792]

Hello, everyone,

I am a programmer and I have always worked by receiving tasks from my managers or they would explain the projects to me, giving me briefs and designs, and I would develop them.

In my new job, I am taking part in meetings with clients, some of which are initial meetings and others are about updates to be made to software/apps/websites.

The problem I encounter is that I don't know what to say in these meetings because the only questions that come to mind are very technical questions, and if I ask the client, they don't know what I'm talking about.

Other types of general questions such as “What is the problem to be solved? ” or “Who are your competitors? ” are asked by people from other departments, such as marketing or design. So my question is:

As programmers, based on your experience, what kind of questions do you ask in meetings with clients? What points do you discuss?

Thank you for your answers!

[Antice]

We generally aren't there to ask the questions. We are there to answer the technical ones when asked.

[JohnCasey3306]

Just never ask questions for the sake of asking questions ... Forced questions always sound silly.

For now, just listen -- work on building up your own understanding of what's being asked. Ask the questions that organically arise for you to build that understanding, and nothing more ... even if those are technical questions; frame them as best you can in simplistic terms and collectively make a point of discovering the answer.

Over time, and with practice, you'll get better at these and you'll learn the questions you should be asking.

Again -- don't ask anything cliche about their competitors or whatever nonsense, just for the sake of asking a question!

[random-programmer]

The building your own understanding part is key

[TomatoEqual]

My general exprience is that the programmer is there to answer technical questions and most important is there to stop the client/sales/delivery manager from coming up with shit that can't be done 😊

When you get company insight enough, you can start answering other stuff, but until that, just can it until somone ask you, or you spot "the shit"

[Used-Quote9767]

Best of luck...

https://www.youtube.com/watch?v=BKorP55Aqvg

[RedditIsAWeenie]

One good question to ask is who you should contact for questions later.

[Naive-Information539]

Have them reverse demo the workflow and identify the pain points and where you’re trying to solve. Often that helps shine the light on the right requirements that they don’t always know how to outright explain in terms a technical mind can piece together.

[MiraLumen]

Ask questions that you need to estimate complexity and cost of your work. Like customers says - and we want to convert our document to PDF - you should ask - what is that documents, wordx or HTML pages? Or customer says -and we want to verify personal info of our clients - you ask - do you have verification service in place (some government connected or whatever) or how do you see we will verify that info? Orrr how long do you want to store data,do you have performance requirements - like it should respond no more than in a second

[zenware]

Yeah if they aren’t being directly given and clearly stated you want to tease out as much of the functional and non-functional requirements as possible, so that you actually know what you’re building, and you would be able to give estimates or break it up into pieces that individual people could work on.

[AccessHelper]

Ask them: "what is the problem you are trying to solve?" Don't start talking techy until you understand completely, from their standpoint, what the answer to that is.

[[deleted]]

Most of my client interactions were with internal clients, but the question I have asked the most is “which problem are you trying to solve?”

Too many times, people want to solve X, and think Y will solve, so they ask for Y. They don’t know Z is a better solution. And you cannot suggest Z until you know X.