How to get domain experts to answer questions correctly, completely & concisely

Question

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?

Or:

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."

Answer 1

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.

Answer 2

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?".

Ask:

"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."

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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, it takes seven clicks to get to the screen I use the most, and then I need to enter the same information again, and then wait for it to load, all 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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

Short answer: If you can figure out how to do this, please let us all know, because software developers have been struggling with this since the earliest days of the profession.

But that said, some helpful hints that I may be able to pass on:

Most subject matter experts that I've worked with LOVE the opportunity to explain their jobs. You run into a few who take the attitude, "Everybody should know this. If you don't know it, you must be some kind of drooling idiot." But most like to think of themselves as geniuses for having mastered this difficult field that no one else understands, and they are happy to explain all the wisdom that they have gained through years of experience to anyone who will listen.

And when you're just getting into a new domain, this can be great for you. You can find people who will explain all about the domain at length.

But -- and here's the huge "but" -- they probably don't know anything about software development. They don't know the first thing about how computers actually work. And so trying to translate their knowledge into software requirements is a difficult process.

One example I've seen time and again: I'll say to the SME, "Okay, you've explained what to do in cases X and Y. What should the computer do in case Z."

And he'll say, "Oh, don't worry about that, that almost never happens."

And I say, "If it ALMOST never happens, then does that mean that it does happen sometimes?"

And he says, "Oh, sure, occasionally. But if it happens, just do something reasonable."

Those sort of instructions work fine when you're dealing with human beings. Like sure, you could tell a reasonably intelligent person, "If the part comes out of the machine cut incorrectly, put it in the reject bin. It it comes out with scorch marks, clean them off using this chemical. Any other problems, do what you can to fix them." And that would be fine for a human. But as I'm sure you know if you're a software developer, you can't just tell a computer "do something reasonable" or "do what you can to fix it". You have to give specific instructions.

I've had many conversations where the SME got clearly annoyed with me because I kept pressing them for detailed instructions on what the computer should do in odd cases, when they had ALREADY TOLD ME that these situations rarely happen and the computer should just do what it can to handle it correctly.

Similarly, ask any auto mechanic how he goes about diagnosing a problem with a car. Very few will say that they perform test 1 and then depending on the results of that they either perform test 2 or test 3, etc. Instead, they'll say something like, "I open the hood and look for something that isn't right." And yeah, for a human being, if you open the hood of the car and see steam pouring out of leaking hose, you don't say, "Okay, test #1, check if we're getting a spark to cylinder 1." You go right to the obvious problem. But of course a computer doesn't work that way.

So my point is, the job of the developer is often to take the vague, "use your intelligence" statements of the SMEs and turn them into concrete steps. To some extent I try to explain this to the SMEs, and sometimes they get it and sometimes they don't. But usually I spend most of my time trying to nail down their fuzzy concepts. Like, "You say, 'see what's wrong'. Okay. Can you tell me what might be wrong? Give me some examples. How do you know that it's A and not B?" Etc.

Once you start nailing them down, you often find gaps. Like I remember once going through requirements and finding they had said what to do for local, express shipments; for long distance, standard (non-express) shipments; and for long distances, express shipments. But they had never said what to do for local, standard shipments -- which I would guess would probably be the biggest group. Apparently the SMEs just skipped over the common case and went right to the special cases. It's your job as the developer to figure out where the holes are and ask questions to fill them in.

As someone else mentioned, it's usually more productive to put together a proposed solution and ask the SMEs to identify the flaws then to just ask open ended questions about "how do I solve this?" Because if they knew how to implement it on the computer, they wouldn't need you. If you give them something concrete, they can say, "Oh, wait, this won't work right when the fwacbar isn't engaging" or whatever. If you just ask an open-ended question, they are likely to wander all over the place.

Answer 12

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)

Answer 13

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.

Answer 14

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.

Answer 15

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.

Answer 16

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.

Answer 17

Don’t think about “shareholders” and “subject matter experts”, think about talking to people who are doing a job, and you intend to change the way they are working. People often don’t like that, because people don’t like change.

So be prepared to run into people who don’t want you to succeed. If at all possible, try to get everyone on your side. If not, you need to find out who isn’t on your side.