I'm a software developer working for a consultancy that undertakes a variety of projects in a variety of domains. Projects typically have a relatively short turnaround (e.g. a few months).

I find that domain expert customers have a habit of not quite answering my questions correctly, completely, or concisely, both via email and over the phone/in person. This frustrates me because I usually don't have very long to do the work, and I feel like I have to keep chasing the customers as they only partially answer my questions, and often introduce new confusion for me.

The questions I typically ask are fairly open-ended, e.g.

I don't understand requirement X, could you please explain what -whatever- means?


I've encountered -some issue-, here are some proposed ways of solving it, what do you think?

These are usually broad or non-obvious questions that require a bit of thought to answer.

One common problem I experience is that domain experts tend to assume that I know what they're talking about when they use specialist terms or discuss specific things within their domain. They also might start talking about something else entirely e.g. another requirement. Sometimes I get back a verbose reply that may only answer part of the question and requires substantial parsing to get the info I need, or a rant about something tangentially related.

I've found that when I interrupt and ask for clarification, the results really depend on the person; sometimes things might get cleared up, but other times they'll basically repeat back what they already said, and some of them can get impatient and condescending. Even if they do explain what some terms mean, I'm still not a domain expert, so I still only have a shallow understanding of what they're talking about, and it's hard to know what bits are relevant or not.

Here's a contrived, falsified example:

Question: You mentioned you wanted the PGA receptors to be displayed in a list - each PGA contains a lot of data, so here's how I'm thinking of displaying it. Does that look ok to you?

Answer: We want a way of showing the PGA receptors coming in in real-time. We currently don't know where they come from so it'd be nice if we could have a list showing each of their numbers and info. Then the QXT2 comes in and crunches those numbers - can we have a screen for this? Right now it takes a long time to input all the P values for the data, but I'm not sure what the best way of doing this is. The current system was made a long time ago and we've added many different types of LFG since then, each with their own bongo system, which has to be input in a separate spreadsheet and loaded prior to the app running. I think the list of PGAs should go on the main screen and have as many items as were loaded in from file. This may not be the best way of doing it but it will work for now. Just be aware that the bongo system for the PGAs has to be in .xml format, so I don't know how much info you'll want to display for each one. We need each one to calculate the T values over time.

My thoughts upon seeing something like this are that it's kind of answered the question, but it's also opened up a lot of other questions and is full of ambiguity, which may or may not be relevant. I may have a shallow understanding of what e.g. "PGA" is, but nothing else, so I don't know if it's worth asking and chewing up more time.

Am I being unclear in my questions, or should I phrase them differently to elicit better responses, e.g. are they too open-ended? I typically try to avoid constraining the possible responses because I want the clients to think about the problem and/or solution, not just "pick A or B."


15 Answers 15


You don't ask open ended questions. You ask concise, directed questions for specific relevant information pertaining to a task or project they care about or have some stake in.

People are not there to teach you.

  • 2
    Comments are not for extended discussion; this conversation has been moved to chat. – DarkCygnus Sep 17 '20 at 3:22
  • 1
    Folks, really... this conversation has been moved to chat. You can carry the discussion there. Further comments here will be deleted without notice. – DarkCygnus Sep 17 '20 at 19:29

Help them (by answering the question) to help you.

Do not, I repeat, do not expect people to be happy (or waiting) to help you (even if they say so). Everyone has their own responsibilities to be taken care of and helping you may not be on their priority list (most of the cases).

If you ask questions which should be answered by a tutorial / googling or needs a brainstorming session, it's very likely that your question will get ignored / unanswered. Ask objective-based, direct and relevant questions and add all relevant info in the question itself. Also, while communicating in writing, do not send one email to multiple recipient, keep it very targeted - one or two at most. If you have a problem that needs to be responded to by multiple people, break them down into individual questions and direct each one to the respective person.

Some quick tips to ask a better question and increase the change of getting an answer:

  • Don't ask

"How do I do this"?

Show your efforts till time. Say:

"I tried doing X, so evaluated P and Q, and here's the list of pros and cons. In my opinion/ analysis, P will help us in a better way, do you see the same? Any better alternate which I've missed?"

  • Don't ask

"This not working, how to make it work?".


"Tried making it work by configuring P, setting up Q and passing through R, but in the end it showed an error saying "hubaa dubba do!". Quick googling shows that I need to import G and H to have this resolved, tried but the message changed to "Ho Ho Ho!". Attached are sample configs which I used and the environment details for operation. Any quick thoughts are appreciated, and if you feel a debugging session would be needed, let me know, I'll set up one"

Bottom line: The more you make it easy for them to answer, the more likely you'll get an answer. Save the open ended questions for a training / learning session.

Last but not the least, here's a nice reference on how to ask good questions. I quote the author

"For the sake of convenience – and as Stack Overflow is so popular – I will assume the question is going to be asked on Stack Overflow or a similar Stack Exchange site. Most of the post doesn’t actually depend on that, but if you’re asking elsewhere you may need to tweak the advice a little."

  • 1
    Also, it is often better to call instead of writing emails. Schedule a call, ask questions directly, write down answers. – Sulthan Sep 16 '20 at 15:16
  • 3
    @Sulthan Possible, but not very suitable for technical discussion, IMHO. But good to get the attention and a quick decision thing (yes/no). – Sourav Ghosh Sep 16 '20 at 15:35
  • For technical discussion, I have found a web call (ideally recorded) with screen sharing and/or text chat as needed (like 'here's the link to the documentation for the think I'm trying to do that's not working') is extremely superior to either a phone call or text communication. – Meg Sep 18 '20 at 15:17

This is I think going to be unpopular....

For software at my work we hire FIRST for subject matter expertise, it is easier to teach C and Assembly (Yes, and the rudiments of small core embedded dev) than it is to teach live TV workflow and the gnarly problems that ops people have to deal with sometimes.

An OK programmer who understands how the domain operates is in our experience FAR more useful than a brilliant programmer who can only follow a spec and does not know which bits are likely to be torn up (And who does not recognise stupid in the spec, there is generally some).

Much the same thing goes for developing business process and dealing with things like CRM systems. Know the business first, if you have to raid stack overflow for how to code it, that is less of a problem than not understanding on a fairly deep level what the thing has to actually achieve.

Our product manager is a subject matter expert, but you know what? So are some of our development team (And the subject is NOT software development).

This has a rather neat advantage, the experts talk the same language and while they might disagree, that fight usually gets a solution that is BETTER than what either one came up with originally.

The expert on the dev team is disseminating knowledge to the rest of the team and short stopping a lot of silly questions, so the external guy is only being asked about the stuff that does not have a clear answer, and is being asked in his language. The guy on the dev team is also heavily involved in architecture because an SME will usually have at least an idea about where a given product might go.

Even for a 'code monkey', contextual understanding is far more important than technical skill, otherwise I will pick a higher level language and let the compiler monkey my code for me (Cheaper, less bugs and no pension to pay)!

If your only SME is way up the company you got a problem because her time is being wasted, the SME annoyed, and people are working to specs that they do NOT understand the reasoning behind, this does not beget good or even very useful results.

Hire someone onto the dev team who talks the language of whatever the domain is, and knows a bit of software dev, it is well worth it.

  • 3
    That may be true for your work, I'll take your word for it. In my previous job, anyone who was a subject matter expert in the problem domain (finance) would be working in that field earning £250K/year, not as a software developer earning £50K/year. We still wrote great software for them. – BittermanAndy Sep 16 '20 at 15:29
  • 1
    This might work for some programming aspects, but you're likely to get really nasty code. It might work (emphasis on "might"), but it'll likely not be efficient, lacking security, readable by anyone other than the author, and such a rats nest of spaghetti code that it's a nightmare to maintain. You might want to think about a compromise and have at least some experienced programmers on staff to clean up the mess left by the novices. This would allow you to cross train between your SMEs and your programmers. The difference between a good programmer and a bad one is often the mentor. – computercarguy Sep 16 '20 at 19:40
  • 1
    @BittermanAndy There is a difference between understanding the jargon and processes in finance and having the skills and inclination to actually use them. You don't need to be an accountant to write finance software, but you should know what's the difference between a debtor and a creditor. – Philipp Sep 17 '20 at 8:54
  • 1
    "[someone described as] a brilliant programmer who can only follow a spec and does not know which bits are likely to be torn up (And who does not recognise stupid in the spec, there is generally some)." I don't know by what metric someone who meets this description can be called a brilliant programmer. I could see someone like this getting good marks on CS homework, and/or gaining experience and possibly going on to be a brilliant programmer, but they aren't there yet. – Ryan1729 Sep 17 '20 at 10:22
  • 2
    Oh we have hired folks who really wanted to be contributing to the C++ standard, turned out to be FAR less useful then someone customer focused who could bash out ideas in code that we could then clean up. Yea, it is NOT brilliant code, and generally wants a rewrite, but code gets rewritten (usually multiple times), so starting with an example that does what is wanted but is O2^n or leaks memory or whatever is no big thing and is almost always better then an ambiguous spec. I don't say hire senior tax accountant, I do say hire someone knowing general accounting principles. – Dan Mills Sep 17 '20 at 15:26

When I work with domain experts in my current software engineering job, I tend to prepare yes/no questions I intend to ask by giving context of why I am asking myself a question e.g. link on related issue / ticket / task, what I inferred from it, asking if my understanding is correct or which of my two scenario is the correct one.

Similarly if I need clarifications for a requirement I'd likely prefer a conversation in chat, phone or in-person so I can make feedback about whether the clarification hits the point or not, and if not, clarify myself what I was asking or ask further questions.

If you need training to understand domain experts, that's a whole other problem. Knowledge should flow in your company so that you understand what your field of work is, and that is mostly the responsibility of your management that you have up-to-date knowledge of abbreviations, acronyms etc. and I'd even say ideally even absorb some of the domain knowledge so you'd directly understand when you are presented a specification.

It's tempting to believe that a more open ended question would give the domain experts more room to go straight to their requirement, but usually this only results in them wasting time explaining what you already know, rephrasing without clarifying, or even missing the point completely.

I'd anyway avoid open-ended wordings about "thought" or "inputs" on a vague subject as they will be unsatisfying since you do require specific information to write a piece of working code.


Open questions are great for interviews. They're not the right tool for gathering requirements.

When you ask, "what are your thoughts on X?", best case scenario is that the expert thinks "oh, wow, I've been doing X for 20 years and this person is asking about my thoughts? Where do I begin?". Worst case scenario, they either assume you know nearly as much as they do, or assume you can't possibly learn enough to do what's needed.

Instead, ask for confirmation. "I think X works like Y, is that correct?". Or, "show me how you do Z". This will inevitably leave gaps as there will be things you don't know you need to ask about. That's why you need to get the first iteration of the software into their hands as soon as possible (even in prototype form), and rapidly work towards the next iteration that responds to the feedback from the first. Prime your experts to expect this.

  • 13
    Requirements aren't like fruits that you pluck, complete and ready to process. They're like nuggets of gold that you pan for. Open-ended questions are very much part of of the requirements process. They just belong at the requirements-elicitation end, not the requirements-definition end. – fectin Sep 15 '20 at 23:36

A good starting point is to understand that your "experts" are primarily selected for their competence in operating their own jobs, not in explaining or communicating the content of those jobs explicitly to others.

People (who might be called "students", and that's how I'm going to characterise your role here) who don't broadly share the education, training, or tacit experience which the experts have, will of course tend to value explicit communication from the experts about what their job involves in all respects. But possessing such explicit understanding and communication skills as an expert, with a view to reproducing that expertise, is the domain of the professional educator.

These "experts" of yours are not educators by trade, and usually will not be academics or intellectuals by nature, so they should not be treated a priori as people who can just be asked questions and from whom a good coherent answer can be expected.

The standard way in which business experts are reproduced from non-experts is firstly by making the non-experts into students of professional educators (i.e. placing them on a course of formal study), secondly by placing the non-experts alongside experienced experts where the information is slowly transferred by osmosis (usually over years), and thirdly by simply allowing non-experts to perform an expert job until they figure it out for themselves (potentially allowing mistakes to be made along the way, again usually over years).

What you're doing is that you're expecting your business experts to adopt the role of professional educator to match the role you have adopted as a student.

But you are implicitly putting the business experts into that third mode of learning, where they must learn (now as non-experts themselves) how to be professional educators by muddling through it for themselves as best they can. Typically this is without releasing them from their day jobs.

If you're finding this approach is hurting, then you know the doctor will say "don't do it then". Your other alternatives to gaining the knowledge of these roles could include a course of formal study with a real educator, or it could involve your employer sitting you down to do this job for a while to gain experience with it (which may at least give you a shared vocabulary and shared common sense with the experts whose brains you are trying to pick).

If you continue with your existing method of simply asking questions from a distance, you simply have to accept that it is often going to be somewhat haphazard and frustrating by nature, because of the mismatch between the role you are casting the expert in - the role of educator - and their actual business role, which is usually nothing of the sort.


I have found that the easiest way to elicit useful information from domain experts is actually to make the software that does what you think is right and then see what they reckon to it. To take your examples:

Instead of saying this:

You mentioned you wanted the PGA receptors to be displayed in a list - each PGA contains a lot of data, so here's how I'm thinking of displaying it. Does that look ok to you?

do this:

Since you said last week that you wanted the PGA receptors to be shown in a list, here's a mockup of what I'm working on. [include screenshot] The idea is it shows you the PGA's mondo bongo in the list but you can click the little icon to open up more detail. This is going to be ready from next week when Steve uploads the figures from the scooby doo.

That means that if there's anything actually problematic, they'll have something concrete to build from: "Oh hey that's fine but can you make sure that the PGA is highlighted somehow if the smoke factor is greater than 74%? Also we should see the R value in the list as well and we need to be able to filter where R < 4 or R > 4."

I have given software over and said that it's a trial, an experimental thing, so don't trust its output. And then the users have been invited to try it. When they do, their experienced eye can often see where anything looks a bit off, and be able to diagnose the problem. And say: it is not doing the right thing in the case where X holds because then this happens and we need to account for the blegbod.

So don't use emails and conversations to communicate about software requirements. Use the software to do that. Use things like demonstrations, UAT scripts, mockups etc. It's much easier this way for you to say "Is this what you mean?". It's also much easier this way for SMEs to say "that's right" or "no that's wrong because X".

End users can share with you useful information beyond "right and wrong". They might not be able to see the problems they have and say, "look, I need to click here and there, and then enter the same information again, and then wait for it to load, all while the while the customer is on the phone getting impatient". But if you have the opportunity to sit with them and shadow them, this kind of thing will be obvious to you. If you can't, then think about using something like user stories and process maps.

  • If you had a user story, it could have said something like "As a PGA plumber, I need to list the receptors separately for low and high R values, so that I can see at a glance where the smoke factor exceeds the legal threshold". Then you would have known beforehand what to implement because you'd know why you were doing it.

  • If you had a process map, it would be clear what the PGA plumber is trying to accomplish, and how to enable him.

  • 1
    While this doesn't cover all cases (rushing off to code before gathering the basic requirements would lead to wasted time/effort/money), it's fantastic advice for the common case of a design question popping up during development. (i.e. "For edge case Y, should we sort the list by froom or blarq?") – Llewellyn Sep 15 '20 at 18:31
  • 2
    @Llewellyn It depends on how simple it is to code up, and how easy the program is to modify. It also depends on how well we even know what the requirements are before starting to implement. I guess it's for OP to weigh up. – OmarL Sep 15 '20 at 18:43
  • 2
    Along this track is to repeat what the customer answers with your own version of what you think they said. "I want this icon moved over here." "Oh, you want the icon next to this one and vertically centered?" This allows you the ability to zero in on what you've misunderstood or they misspoke. This works during development, too, by using the software as your visual, like you said. – computercarguy Sep 16 '20 at 19:49
  • Iterating on the software in small pieces and showing the customer and getting fast feedback. I think this is what Agile was/is trying to encourage. To what extent it has succeeded in that aim, is a different story. – Ryan1729 Sep 17 '20 at 10:29

I've found that when I interrupt and ask for clarification

Avoid interrupting. It's usually rude & they're only talking "too much" because you asked the wrong question. Ask better questions.

You should never ask the SME open ended questions unless you are socializing. Usually there are different levels of expert on the topic, ranging from people in your own department to people in other departments/external companies, going upwards to the top level expert you're dealing with. Avoid asking lots of questions of the top level expert. Get as many questions answered by the lower level people first before taking the ones nobody else can answer to the top level person. Don't take anybody's time for granted either. Sometimes they are so busy that they can only meet with you once every couple of weeks. Never assume that you'll have the freedom to take another hour of their time. But they're going to be more receptive the more respectful you are of their time when you do deal with them.

  • Or at least commit to asking an open-ended question, e.g. because you believe you need an actual thorough overview of their field to do your own work. – fectin Sep 15 '20 at 23:39
  • 3
    "Avoid interrupting. It's usually rude" - not really. If there's uncertainty from both sides, the asker who doesn't fully comprehend the problem domain and the expert who doesn't know the asker's experience, asking "what about fooing the bar", and the expert starting on a five minute tangent on what foos actually do, and the asker knows that already, they can save both time and frustration by saying "yes, I know the foo stuff, but not in relation to bar". This is contrived, of course, but "interrupting" can quickly establish a base for what the discussion really is about. – CodeCaster Sep 16 '20 at 7:49
  • 1
    @CodeCaster Could go either way depending on the situation I'd think. I've been in meetings with CEOs and 8+ other people where I'm the one person there who's going to implement something. The CEO decides to ramble/educate for an hour and those other people are learning things they need in 99% of his talk while I get 2 sentences. Better be good at taking notes. – HenryM Sep 16 '20 at 15:46

Remember: they are domain experts, and you(!) are an expert on the software that you are designing or building. (Which might be designed to serve users within that domain of expertise [that you don't also have].)

Furthermore – "the entire reason of this, of course equally shared by both parties," is very-specifically purposeful. Your mutual(!) goal is to achieve "the timely creation of an excellent piece of software." However, only you (say ...) are the "domain expert" on the specific task of software-creation.

"And so, here both of you are."

Frame most questions as specifically as you can in terms of what your software needs to do and/or to provide. Perhaps prepare some use-case scenarios ("user stories," as they're often called these days) for comment and contribution.

  • 4
    Expecting the SMEs/users to talk in the language of software development will not result in excellent software. It will result in really bad software and also an awful process where you implement exactly what they said and then have to go back and completely redo it because it turns out that what they thought they wanted wasn't what they actually needed. – user3067860 Sep 16 '20 at 17:27

I really like the example you provided, and I think it does kind "answer" the question. It is not what you were expecting, but they don't know the "correctly and concisely answer" themselves. I might have done on occasion something similar to your experts.

You mentioned you wanted the PGA receptors to be displayed in a list - each PGA contains a lot of data, so here's how I'm thinking of displaying it. Does that look ok to you?

You are asking about an interface control. This may look like a simple, delimited question. In fact, if they have a clear design in their mind on how the software should work, it may be so. However...

We want a way of showing the PGA receptors coming in in real-time.

They don't need "a list". Their actual requisite is to, somehow, show the PGA receptors in real-time.

We currently don't know where they come from so it'd be nice if we could have a list showing each of their numbers and info.

Albeit a list of sorts is probably warranted.

Then the QXT2 comes in and crunches those numbers

Here, they are mentioning their flow

can we have a screen for this?

which adds another requisite. It is important to take into account that there should be a secondary screen from that list, though.

Right now it takes a long time to input all the P values for the data, but I'm not sure what the best way of doing this is.

The current system was made a long time ago and we've added many different types of LFG since then, each with their own bongo system, which has to be input in a separate spreadsheet, and loaded prior to the app running.

Historical data.

I think the list of PGAs should go on the main screen and have as many items as were loaded in from file.

Some idea which may be wise or not.

This may not be the best way of doing it but it will work for now. Just be aware that the bongo system for the PGAs has to be in .xml format, so I don't know how much info you'll want to display for each one.

Some helpful advice mixed in.

We need each one to calculate the T values over time.

Plus an explanation of the data you will need to process from the bongos

In fact, I think you explained it quite well:

it's kind of answered the question, but it's also opened up a lot of other questions, which may or may not be relevant

You have a problem of design. If this was a waterfall development. A design would be drafted early on, then set in stone. "There is a screen 2.6.4 with a listview here full of PGAs, and three buttons."

I think you are working from a set of incomplete requirements. I'm not sure what is your exact role in this project, who would be responsible for gathering all the requisites and formalizing them. If it's someone else, you might have to pass that to them, so they figure out (with the help of your team?) what needs to be done.

The expert answer does open a number of questions (unless these were already known). Before a line of code is typed, there should be a design. This may use a pretty graphical design program, pencil and paper or even be fully in your head, but there is a need to understand what is needed and (roughly) how to do that. It is possible that among all those words some things sort out themselves, other may require help from the development team, or from the experts. I would probably meet with the domain expert to review this screen and how to design it. It's not uncommon either that from the input received there the development team produces a proposal, which then goes back...

In short, on this fake example you were centering on some very specific part, while there are many important pieces around it poorly defined, that need focusing first.

(note how, finally, you should be able to reply such email explaining how the PGA, bongos and LFG fit on that screen)


I've been on both sides of this particular situation, and here are a few things that I've learned.

My basic rule of thumb is that specific questions get specific answers, and open, general questions get open, general answers. The problem with open-ended questions is that it's not obvious when you've actually answered the entire question. There's always more that you could say about the subject, but at some point you feel like it's enough and you stop writing. This isn't really an issue in a face-to-face conversation because you can ask follow-up questions to explore further. Asynchronous communication like email makes this significantly more difficult. If you need to ask broad, open-ended questions, it's better to do it in person or on the phone. Rambling replies are usually a sign that the question was not very specific to begin with. The Stack Exchange network is actually a decent example for this. Think about the sort of specific, focused questions that attract quality answers quickly vs. the kind of questions that get closed as "Too Broad" or "Unsure what you're asking".

Jargon, industry-specific abbreviations, and internal codenames are always a problem. Your SME almost exclusively works with a set of people that have a common foundation of knowledge that you don't have. Your SME may also be completely unaware that these terms and concepts are unfamiliar to you, or that a term might mean something completely different in other contexts. I usually follow up with a message along the lines of "I'm a bit new to your team/company/industry and am not familiar with some of these terms. Can you define what the term 'BFG' means in this context?" This is a specific question that should be answerable in a short sentence or two. It also makes the reader aware that you may not understand all of their jargon, and that they should be a bit more careful with future messages.

Also, remember that this entire process is symmetrical. Both of you are SMEs with extensive knowledge of your own subject of interest and only a passing familiarity with the other side's subject. When you ask questions about implementation details (like your "here are some ways I've thought about solving it" example), the other person will likely find your question as confusing and hard to understand as you find their answer to be. People that aren't programmers tend to respond best when you ask your question in terms of a sketch or a GUI mockup (as in "which of these two interfaces looks easier to use"). If you start talking about things too far below the GUI layers, non-programmers tend to either not understand you completely or not care. If some aspect of your internals really does need SME input to function properly, try to word the question in a way that either minimizes or eliminates anything software-related. Don't try to make them "think about the problem and/or solution"; they already did that once, and their solution was to hire you. They want to outsource as much of the thinking as possible.


Lots of great answers here, so I'll make this brief to add something not covered yet. It's a strategy I generally use as a last resort when other methods fail.

Prepare something that you know is wrong. Preferably wrong in an obvious manner specific to what you want to ask about. Then have that reviewed. More than likely you'll get some specific criticism back that will help you.

Again, try other methods first. But I've found that some experts and cranky lead types respond to this approach in a much more helpful way than any other, and it can be an inroad to a more constructive relationship. Yeah, you might have to deal with feeling like you're coming across as an idiot for a little while, but pretty soon you'll have their knowledge and they'll retire or otherwise move on and then you'll know for yourself what it's like to field these types of questions.


The overarching problem here is that you are being asked to be a business analyst.

The distinction between a developer and an analyst exists for a reason. Interrogating SME's and turning their answers into intelligible and complete requirements is a business analysis task, not a software development task. They aren't the same skill set and don't use the same methods.

If the client is paying the developer hourly rate for you to chase down answers that should have been documented by a (less expensive) business analyst before you even started billing time to the project, the client is being ill-served and the project is being poorly managed on your team's end.

If there is no business analyst role built into the project - perhaps because it is nominally a scrum project and you're supposed to be working it out as you go along - then you should be working closely enough with the SME's that these awkward, intermittent and ambiguous email exchanges aren't a problem; you should be in constant contact with them and should have plenty of opportunities to incrementally get clarification.

  • 2
    "that should have been documented by a (less expensive) business analyst" - proficient analysts are rarely cheaper than coders. – Steve Sep 16 '20 at 21:32

Formulate a list of written, short-and-to-the-point questions

I deal with requirements from individuals who generally aren't even domain experts, and often it's a case of the customer doesn't know what they want. Even with experts, there can be misunderstanding and confusion, so questions should be concise, and kept as narrow as possible.

For example:

I've seen X does A, but the requirements say X needs to do B. Do you prefer if it does A or B?

I've noticed C appears to be glitching out, I can fix it with U or J. My preference is U, but I'm wondering what you might think.

If you get back an answer of 'I don't know' or any expression of confusion, you can take it to mean they don't know. You can try to find someone else, or, use your best judgement, keeping notes on why you chose that course of action.

Experts have great difficulty translating their knowledge into a computerised software format, so it's often not possible for them to answer any software related questions directly, unless you boil it down.

Close-ended questions often translate better to the binary choice selection computers make. Open-ended are more useful to get an overview.

If they still don't understand, you might have to

Use analogies

So, in dealing with people who aren't tech savvy, I often try to simplify the query to an analogy.

I've spotted a case scenario where person H doesn't get registered onto the system due to software glitch XYZ

What's glitch XYZ?

Well, lets say person H enters the system, and just as they hit submit the power instantly fails; is person H still registered, or have all their details been lost?

Even if they misunderstand the analogy you can just adapt it:

Well power failures are rare.

Power failure here could mean many things, like someone pulls out the cable, wind knocks the cable down, fire starts up. Is patient H still registered or do we need a system to handle that?

Instead of saying 'the form might lose data due to a software glitch' which is incomprehensible to non-tech savvy minds, I've transformed it into a real world example of how the data could be physically lost in a similar manner, which usually prompts a close enough comment or suggestion that can be adapted to software.

Your questions and methodologies should adapt to the particular individual. Throwing open-ended questions will leave those unsure even more unsure, and so they often fall back to stuff they've already told you.

So to avoid any uncertainty, give them the smallest amount of information necessary to work with.


It sounds like your consulting company is missing at least one layer of communication.

Do you have a team/project lead or project manager? This is how the flow is supposed to work:

  1. Client creates requirements for the whole project at a large scale and scope.
  2. Client communicated project requirements to project manager/leader, who is usually but not always the team lead of the development team.
  3. Project manager builds a dev spec based on those requirements and works with the team scrum master (if you're using Agile; they don't always have to work with anyone else to do this but it's usually good to get a developer's perspective) to break the dev spec into tickets which are complete, valid, deliverable pieces of work on their own.
  4. Each ticket is completed by a developer. The developer does not need to be concerned with issues outside of their ticket's domain (and concerns outside of the ticket's specific domain but which require consideration when completing the ticket should be present in the ticket).

Now, given you have this workflow, the person who is the expert on the project is not the client; it is the project manager. The project manager should have an idea of what the end product should look like, and also what each intermediate part of the project should look like as it gets delivered to the customer, because they were the ones who orchestrated breaking down the project into small, deliverable tickets. Therefore they should have the best picture; you should ask them whatever the question is. Then, if they don't know, they will go to the client and ask for clarification; it's expected that the client-side SME will be able to knowledge-transfer whatever secondary considerations, such as those you've described, to the project manager much easier than they could do so to a developer such as yourself.

  • 1
    What happened to the Agile Manifesto here? – user3067860 Sep 18 '20 at 18:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .