Stop wasting time!
The main point I want to make is that the more people you have in a meeting, the more time you are wasting. Whenever you are discussing something not directly relating to employee X, you are wasting employee X's time.
Why is this a bad thing? Obviously there is a direct cost (assuming you are paying employee X for his/her time!) but there's also an indirect one - you are demoralising employee X. Every time he/she is up against a tight deadline, or having to work overtime, they are going to think about the wasted time they spent in that meeting when they could have been achieving something.
So, keep your meetings as small as possible. You do this by organising people into teams. Think of a team as the set of people who need to be involved in order to implement a task. This might be specific people, or it might be "two developers and one UX designer". One person can be in more than one team, and you may well need to create different teams for each feature.
If 2 teams need to work together - e.g. team A can't start their feature until team B finishes theirs. In this case try to get one or two representatives from each team involved instead of bringing the whole team in.
Ultimately the product is being developed for a customer (or customers), and it's the customer who decides which features are most important. Your marketers are the ones dealing with the customers, so it's their job to find out what features the customers need/want next and assign priorities to those features.
To decide how to prioritise features, your marketers need to define the requirements, which they can then use to get an idea of how much development/design time is going to be required for each of them. This is one of those meetings where you get representatives from each team together.
Your devs/designers might need to have a discussion with their respective teams to come up with a decent estimate, so allow space in your scheduling for that. I'd suggest making these meetings fairly frequent - either as and when new features are thought up, or on a weekly/bi-weekly basis.
The other important thing to consider is that some features depend on other features. If feature A is a prerequisite for feature B, then feature A has to come before feature B in the priority list.
Another point here is that bug fixes should be treated as features here. It's up to the customer to decide if they thing new feature A is more important than fixing that niggly bug with existing feature B! This should also simplify your scheduling.
Planning for the next milestone
With your prioritised list of features (with time estimates) this part should be pretty straightforward. Basically, just take the next achievable feature* off the top of the list until you've filled up people's time!
If you find that you can't do the top item on the list because it a required person/team already has a full schedule, leave it for the next milestone and find the next achievable feature.
Get everyone to give you copies of their schedules and you should have all the information you need in order to do the milestone planning on your own. Just remember to leave some time for dealing with the unexpected!
Further reading/where to go from here
I've barely skimmed the surface here. I strongly recommend you spend some time reading up on different development methodologies and working out what would suit your team's situation best. Agile development is the "in thing" (there are various types - e.g. Scrum and Kanban are popular) but it might not be the best fit for your team.
The final point I'd like to make is not to change things too quickly!