How to nail down requirement when the customer is not sure what s/he wants?


Customer comes with a rough software idea and is willing to pay. However, he does not have a detailed requirement. Please kindly advice what to do with this situation (or links to resources). Would it be a bad move to propose requirement (with limitations) first?
Thanks in advance.


asked Feb 29 '12 at 14:05
Dr. Xray
113 points
  • Should this be in http://pm.stackexchange.comJonny Boats 12 years ago
  • If I am the PM, I will definitely go push for the requirement. Now, it is a hard decision... – Dr. Xray 12 years ago
  • Thanks everyone for your advice, very helpful. Sorry that I can only pick one right answer. I think I am in a position not being able to charge for the spec hours (if I do, he is likely to work away due to the culture, and I do want to establish a good relationship with this client, and on the other hand, I need to protect myself, well, it is another question). Thanks again! – Dr. Xray 12 years ago

6 Answers


"Customer comes with a rough software idea" is probably telling you what they think they want and not what they need.

If you want to establish an ongoing relationship with them, you'll want to do some discovery (as Marcus says) to understand the problem. Once you understand the problem better than the client, you are in a position to make a proposal for a solution.

This position is powerful. The client has already invested in you (even if only their time), has built some rapport with you and should be happy that you're listening to them. It also means that you get to understand how much pain the problem causes, convert that to money, and figure out how much you can charge for the product.

Should you get paid for this discovery? That's up to you. For a big client, that we want, we tend to offer to put in fifty percent of the hours as our risk. For example, if the discovery takes 40 hours, we'll bill 20 and eat 20. This shows the client that you're looking to the future, not just to the end of the month.

answered Feb 29 '12 at 20:13
Nick Stevens
4,436 points
  • Thanks Nick. Yup, Knowledge Is Power, never go wrong with that. – Dr. Xray 12 years ago


It's your job to guide your customer through the process of building this software. From your perspective, you should want to be paid for the entire process.

To build this software you need a specification that your customer agrees to and that you can use to build the actual product. If your customer doesn't even have a start on this specification, you need to develop it for him.

Propose that you will develop the specification, charging him at your current hourly rate. Give him a firm estimate for what this part of the project will cost. Make sure to include client meeting time, your own time, and review time for this specification.

answered Feb 29 '12 at 15:54
Gary E
12,510 points


You have to determine what needs to be done before you build it, right? You have a few choices:

  1. Spend your own time defining the requirements so that you can give a proposal.
  2. Tell the client to "trust you", and start billing him hourly.
  3. Not define the requirements upfront, give him a bid and pray you covered your cost.
  4. Tell the client you require a "Discovery" phase, in which you will gather requirements, document then, do any necessary wire framing and technical discovery work, and present him with a written proposal and bid for the work.

I do #4 with each project. I feel it's the most honest & ethical, and also gives them an asset they can use even if they do NOT accept my proposal.

answered Feb 29 '12 at 15:54
Marcus Blankenship
376 points
  • Thanks Marcus. Always good to hear from experienced person. Yeah, option 4 looks good to my situation. – Dr. Xray 12 years ago
  • Yeah, it can be difficult to explain to clients, but we've found that it's the only sane way to do business. Sometimes you have to walk away from clients if they don't understand the value of the Discovery process. It's up to you to sell the long-term value of Discovery. – Marcus Blankenship 12 years ago


Start with some paper sketches. This may prompt some more ideas by getting them to think more specifically about how the app would be designed and functions. Since they are really vague, you may want to start with a prototype a little earlier in the process than normal.

Another approach could be to look at a similar application that is in another field. Or a more generic application that has a specific feature. If they want a discussion board component, you could go over the stack overflow site and look at some of the features.

Try to keep an open mind about radically changing requirements. Seems like you've approached the cost issue. You don't want them to be reluctant to change their mind, but they still need to pay for it.

answered Mar 1 '12 at 00:10
Jeff O
6,169 points


The best way is using prototypes, the main idea is that you can show to your customer screens that will server as bridge to get all the requirements, and he will know how the software will reacts to their needs.

If you get to a point where he understands how the software is going to work, then you nail it.

The creation of these prototypes will not require too much effort, if you're using some tools you can create some forms very easy.

here's the definition of Software prototyping: is very easy, just screens without code, just the transitions between them.

answered Mar 1 '12 at 00:45
141 points


I don't think you will get detailed requirements from the client. I see two options:

  1. Use a price model that let you discover over time - together with the client - what they want and need. Here's a link with some good examples of price models: 10 agile contracts
  2. Charge for a pre-study to get the requirements in place.

In any case, make sure you have change management and risk analysis in place. Avoid a fixed price contract!

answered Feb 29 '12 at 21:04
111 points

Your Answer

  • Bold
  • Italic
  • • Bullets
  • 1. Numbers
  • Quote
Not the answer you're looking for? Ask your own question or browse other questions in these topics: