From my experience, I would not spend a single minute developing. Not even a little piece of code. At this stage, where the customer doesn't know what he wants, it's really important to do a good job of consulting. It's as important for them as it's for you.
Behind each project, there's a need (sometimes isn't obvious) related to the customer's business. So, in order to clarify the need, you first have to learn the business as much as possible. Then you will be able to lead the customer to a functional solution.
During the learning, be careful at the time of differentiating needs and whishes. What customer need might or might not to be the same than the customer wants?
While the analysis, if the customer doesn't take decisions, take them yourself. As consultant your job is to give advice and to lead the process.
As @Ewan pointed out, it's easier for the customers to make decisions if there's any choice to do. Offering several alternatives (exposing their pros/cons), makes easier the decision-making. Mocking up prototypes is a good way to give an overview of what you have in mind for them. Customer will have the first contact (and feelings) about how things are going to be.
Doing this exercise of "creativity" you will see quickly the lights and shadows of the project before they become a problem.
Try to get as many feedback as possible from the end user. So many times the person who we call "the customer", it isn't who is going to use the system. In such situation, you will get better feedback from the real end user. They will provide you with valuable tips about what they need. Identifying well who can provide the right answers to your questions will help you to meet customer's expectations.
Once you have collected a good set of requirements, put them into the prototype. Agile methodologies like SCRUM works fine at this stage. Doing sprints over the prototype.
Prototypes are going to be discarded/modified along the sprints. You can also "guide" the customer to the one that suits you best. ;-). Looking for a win-win deal.
I try to prevent Managers from starting the development before any well defined and measurable requirement has been signed off. Otherwise, starting with undefined requirements is fated to fail badly. A lot of money and time is going to be wasted (with no guarantee to recover it) because someone has decided to implement "the Chaos". The Chaos and the uncertainty where our so beloved and confused customer lives right now.
It's shocking to see companies whose employees do their job but they are not capable of explaining (reasonably) to you how.
It's shocking also to see how many Project Managers doesn't care about this problem, they just say "yes to all" or "let's start and we will see what happens".
Finally, @Ewan again pointed to the most important point.
Get the customer to sign off on the ones they want and implement.
Don't forget to define clearly, which requirements and conditions need to be met in order to say the project is done. The acceptance conditions
No need to say why.