There's a few things going wrong here that might be the cause of your problem. They're common problems, simple miscommunication between you and your audience.
First of all, be conscious of what you're doing when presenting. You and your presentation are often the first real interaction between your product and your customers. Assume these people want to use your product and want to use it in the most convenient way possible. To that end, they'll be asking you questions with a specific kind of answer in mind.
Also be aware of the fact that these people are not just there to waste time. These are your customers, not people with an hour to kill. If someone asks a question, that means there's a piece of information missing that's important to them. Sure, your definition of important and theirs might differ (see every version of "Can we change this colour") but they care.
Questions and Answers
And that brings us to the second point: People are terrible at asking questions. Usually, when someone asks you a question, they're only asking half of the question, the rest being implied by the context, what they have in mind as an answer and a whole load of other implicit things. Often, much of the implicit question is lost if there's a knowledge gap between the person asking the question and the speaker. When someone asks you about having to enter their data first, they're not asking you: "Do we have to enter our data into your application". They know this and you know this. What they might really be asking is: "How much time does it take to enter our data?" or "Can we import our existing data?" or "How much data-entry overhead should we be taking into account?" or "In what ways can we enter our data?" and a dozen more questions that aren't obvious to you.
Which brings us to our third point: People are terrible at answering questions. Often when you answer a question, you don't quite answer the question but you answer the question that you think is being asked. Take the question above: "Do we have to enter our data into the system". You can answer this question a dozen different ways but if none of them answer the question that was being asked, all you've done is wasted time.
So, solutions. First of all, be aware of your presentation's content. It can be helpful to either have a test audience, preferably someone with little to no knowledge of the subject. If that's not available, either a recording or just reading it over a few days after preparing it can help.
This way you can get a better idea of exactly what is being presented. Your mind often fills in blanks based on your knowledge and it's important to know if there are any major ones in the system. This is the same reason you (should) do usability testing. If you've worked on something for weeks/months/years, you know how it works and why. Someone without that knowledge might not see it and ask questions that seem obvious.
Also be aware of how different your priorities may be. You as a software engineer are going to care about different things than someone working in a lab or their IT director or their marketing guy or whoever. But since they're the customer, what they care about is important because you want to make that sale.
And perhaps more importantly, their questions can point to features that you've missed. That guy asking about changing the text colour from green to blue might sound like he just likes to pick nits, but there's likely a good reason for it. (Maybe two of his co-workers have some form of colour-blindness)
For the other two points, practice asking questions back. Sure, it's annoying if someone answers a question with a question but it's worse if someone doesn't answer a question you asked but instead talks about something unrelated. Try to give a brief answer to the question while at the same time angling for clarification.
Also important here, since it sounds like you're pitching your product to people, is appearing interested in their concerns. Active listening is important here. Try to use their questions, or part of their questions in your answer but use your own words. That lets them know you are hearing their questions but rephrasing it might make them realise they weren't very clear in what they were asking.
Q: "Do we have to enter our data into your application?"
A: "Entering the data into our database works via a simple interface, almost like an excel spreadsheet. We can pre-populate some of the database for you, but to really get the most out of it, you'll have to use accurate data for your environment"
Q: "Like an excel spreadsheet? Can we import our existing spreadsheet?" (There's the real question)
Long answer short: treat these observation with the seriousness they deserve because often the posed question isn't the real question but the real observation is important to you and them.