Make no mistake: you must always speak with your users. As much as I'd like to celebrate my awesome software once we ship, the users get the final say in just how awesome it is, and users don't like software that doesn't fix their problems.* The only way you fix problems is by understanding them, so yeah, talk to your users.
The problem, though, is that users aren't engineers. The same attention to detail they exhibit with their daily tasks is the same attention to detail that derails most demos and leads to four hour excursions into "well can that be a radio button instead of a picklist because it's only ever a select one and never a select many or select all." Your users don't know how easy or hard it is to change things, and they should never (never!) be forced to sit through a technical discussion with an architect to learn the finer points of configuration versus code.**
Worse yet, these discussions typically result in a very slick, very expensive system that effectively reproduces the Excel spreadsheet you're trying to replace. Yes, absolutely let your users help define their own future workflow. Understand, though, that they will always be predisposed to doing things the way they've always done them, and that usually means something like "copy this data to this spreadsheet, move that cell there, and then run the macro."
What can you do about this?
First, pick a use case. At the start of your meeting, mention that you are going to do a quick walkthrough of the new process before you get into details. Execute the steps in your wireframe/comps/demo as if you were the end-user of the system. Gloss over details like button placement and instead show the benefits of your new process: reduced time, reduced complexity, reduced duplication, and increased automation. If you do a good job, they'll stop trying to replicate Excel and start identifying MVP requirements and changes to your process.
Next, have your user walk through the same steps but ask for feedback along the way. If they start talking about trivialities, direct them back towards what;s important. YOU know what's easy to change and thus undeserving of your user's time. THEY have the business context. Trade valuable information, not errata.
Make sure to ask the right questions. You're iterating, so you need to know whether something is truly part of your MVP requirements or not. Don't ask whether they need something, ask whether it's something they do 100 times a day or once. Ask them if it's truly painful or just an annoyance. Figure out what they're willing to trade for this feature that covers an edge case; I personally love the "buy a feature" exercise*** because it highlights priority to users.
Regardless of the quantity and quality of user feedback, business analysis still needs to be done by business analysts. Use your technical knowledge to apply the business context to your solution and everyone drinks champagne on launch day. Otherwise, invest in scotch.
* This isn't always true. iTunes is a classic example of bad software with adoring users.
** When should they be subjected to this? You have two choices:
1. Never
2. The day before they complain to their manager about how annoying/confusing/rude the PM from Tech was.
*** Give your users a list of features and $100. Tell them they can spend the $100 on whichever features they like, but they only have $100. If you want to make it really interesting, you can price the features (where $100 represents the total development capacity of the team) to give a sense of scale. Maybe the big feature isn't as important as fifteen little ones. With a representative sample, you'll have an indisputable prioritized list of features to hand to your product manager. Out of the mouths of babes...
