Working in a large organisation, it is often the case that the members of the development team are not able to get direct access to the client to gather requirements. Is it possible/advisable to give a list of questions to an account manager so that they can gather requirements on your behalf?

  • Possible: yes :-)

  • Advisable: only if there is really really no other way. This would easily result in very brittle, poorly understood requirements. And the problems may only appear at a later stage, during implementation or acceptance testing.

Requirements gathering ideally should be a series of detailed discussions between client and developer(s). Clients usually have very faint ideas of what they really want, thus implementing their first vague decription as is would almost inevitably lead to problems. So the developers should be able to tell the price of each idea/story/requirement, which helps clients prioritize their needs, and give technical feedback on what's possible and feasible. Also, they should understand the problem domain as deep as needed, in order to provide the best technical solution to the client's problem. And all along the way, they must ensure they understood the client properly, which means frequently asking back for clarifications and repeating what they understood with their own words during communication sessions (and frequently providing UI prototypes/mockups of client ideas). The best medium for this is oral communication - if it is not possible face to face, a video or phone conference is the next best option.

Having a nontechnical person as a communication channel between clients and developers severely limits the efficiency of communication. Even sending documents back and forth by e-mail would be better, where there is at least no intermediary, so there is one less possibility for misunderstanding.

  • I agree with you but why can't there be a proxy between the developer and business. I my experience in large companies projects touches multiple systems (with possibly different development teams in different locations), data warehousing and reporting, infrastructure and even changes to business process itself. You need someone to take care of all this. – softveda May 23 '11 at 9:21
  • 3
    @Pratik, it's called a business analyst (BA) in some shops. A BA is indeed useful in some cases (we also have one with our current project). However, a good BA is (IMHO) far from an account manager: she knows a lot about the problem domain, and (although not necessarily on the deep technical level) about the application as well. – Péter Török May 23 '11 at 10:16
  • A proxy between the developer and the business can work, but only if the proxy is trained and knowledgeable enough to know what to ask. Relying on someone who simply knows the customer's needs is a recipe for failure if they don't know how to translate those needs into technical specifications that reach the level of detail required for development. – Beofett May 23 '11 at 12:44
  • As a Business Analyst, I have to totally disagree with you that a nontechnical person acting as a communication channel severely limits efficiency. In my particular part of the IT industry (government contracting), I spent a huge amount of time trying to understand exactly how our customer works, how they want to be able to work, and what they consider important. Our software engineers do NOT have the time or inclination (nor, usually the social skills) necessary to unravel the byzantine aspects of our customer's business processes. I know a lot about the user, and a lot about the application – JBiggs Dec 16 '16 at 19:06

While I agree with Péter Török that a go-between may limit efficiency, having a non-developer talk to end-users may well increase the effectiveness of the communication.

I have found that developers and end-users often times may talk together but still mis-understand each other because they come from "different worlds." While speaking the same words they may understand them to mean completely different things... A go-between who understands both the end-user's and the developers mindset/language, can be worth their weight in gold improving mutual understanding of what is needed/what will be developed.

That being said, asking a manager, be it an account manager or any other type of manager, is not the way to go. Bridging the gap between developer and end-user worlds is a skill and not something you do "as an aside."

  • I fully agree that developers should understand the problem domain in order to provide real solutions, and extended my answer along this line while you were writing yours :-) – Péter Török May 23 '11 at 9:01
  • @Péter: yes, answering on StackOverflow is like people speaking simultaneously. You only hear what someone else has said after they said it and you have stopped speaking (answering) yourself (or load new answers). It would be nice to get an indication that somebody is typing, like you do in a chat session, but I guess that would be asking too much of the StackOverflow servers... :-) – Marjan Venema May 23 '11 at 9:29
  • I agree. As a business analyst, I have to serve as that bridge between software engineers who know very little about how the customer thinks and works and the customer, who knows very little about how software is developed. I have heard from both sides that people who do what I do are invaluable for communication. I can recall several times when I was able to represent the customer during a planning session that was running down a cool-technology-centric path by saying something along the lines of "that's great, but that isn't the way they want to use this. They need to be able to see the..." – JBiggs Dec 16 '16 at 19:10

In short, this way of working is fraught with danger and was one of the reasons that the Agile Manifesto was born.

{bad attempt at humour}Beg, borrow, fight, cheat, steal, charm, take to the pub, do what ever you can to actually get involved with the end user{/bad attempt at humour}

But seriously, if you can't get access then at least make sure there is a fast feedback cycle. So yes you can ask questions through the account manager (if you can access the client directly, even if remotely through email that is still better), but ask them every day and provide a prototype as often as possible for the client to try out.

Otherwise you have a massive risk of delivering something that the end client doesn't actually want.


I work in a medium-large size organisation and we have a business solutions team that have many business analysts. They do a important job as they understand the business process very well and translates what the business wants to what the developer understands. It works other way as well. If I detect some design and/or architectural issue or a propose a alternate way to solve the problem I talk with them and they in turn to business.

In a large business there many things to consider other than technical things when doing a requirement. Like the staff training issues, like not impacting a customer with a change, like a compensating process that exists to make your question a non-issue, or "John" is marketing uses this function and you cannot just change this etc.

To answer your question if you have a structure in place then use it. Give them the list of questions to follow up with the business account managers.


You're playing the requirements gathering version of the telephone game. At best, this will cause lots of communication inefficiency. At worst, it will cause incorrectly gathered requirements. The importance of this feedback loop and its efficiency is one of the primary reasons that the Customer Representative is one of the most valuable (and hardest to scale) roles in an Agile team.



Taking your question literally, the answer cannot be anything other than a resounding "NO! NO! A THOUSAND AND TWENTY-FOUR TIMES NO!" unless the "Account Manager" also happens to be a trained consultant, analyst, and developer

If there has to be an untrained middleman in the process, you are better off sending the users surveys via email and just CC'ing the account manager. He/She cannot possibly add value to the process, but can certainly garble the communications.

The proper role for the Account Manager in this process is to participate in the conversation as a stakeholder, not play middleware or amateur analyst.

  • +1, have to agree. It happens a lot, but I've never seen it work out. – msvb60 May 23 '11 at 20:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.