You must leverage your framework more effectively. This includes pulling your stakeholders into Backlog Refinement and explaining the iterative/incremental nature of the project's delivery framework.
You also need to increase the level of collaboration with the CEO. Being dismissive or using emotion-laden statements like "he moans all the time" are 100% counter-productive, and usually a sign of ineffective communication on both sides.
NB: While you didn't tag the question with agile or scrum, your mention of "backlog grooming" indicates it's some sort of Scrum-like framework. My answer will therefore be tailored for that.
Stakeholders Required for Refinement
I am responsible for grooming the product backlog and on a weekly basis plan the team's work for the week. As part of the process, I have to show my plan for the week every Monday morning to my CEO.
Ouch. No! If you're following Scrum, then the Product Owner should be leading the refinement ceremony, and inviting the rest of the team to participate. If you're doing Backlog Refinement all by yourself, you're Doing Scrum Wrong.™ More importantly, the input to the Product Backlog and the Backlog Refinement ceremony needs to flow from the stakeholders and through the Product Owner.
In your specific case, the CEO is a key stakeholder, but he's not actively participating in defining stories or refining your Product Backlog. This is a problem, because he's waiting until Monday (which is presumably Sprint Planning or your equivalent) to weigh in, rather than getting out in front of things in Backlog Refinement.
You should insist that he take part in refinement. Call it a "pre-planning" meeting if he's not an agilist, or invest the time to explain the differing purposes of the formal ceremonies of your framework.
Explain Iterative Development
[T]he normal protocol is for the CEO to review the first draft of the design work. Since this is DESIGN, it is very difficult to get it perfect the first time due to subjectivity of what a good design is, which is why he is involved in the process. I showed him the design, my designer did 5 versions, and he just kept complaining over minor things.
First of all, "the normal protocol" seems like a project smell. The client should generally be the one reviewing design decisions, because the CEO is not the one ultimately consuming the delivered product. It's likely that the CEO doesn't trust you or the team, and that's something that needs to be addressed. Furthermore, you need to find out why the CEO doesn't want the client reviewing the design. His answer may be useful in deciding how to proceed.
Secondly, regardless of who is reviewing the design, the team and the CEO are not collaborating constructively. That needs to change.
In an iterative delivery model like Scrum, work is done in increments. Whether the increment of work is a design or a slice of functionality is irrelevant. In either case, the team should do the work and then the stakeholders (in this case, the CEO) review it and suggest changes or improvements.
The CEO is free to make an infinite number of changes. It's his company. Your job isn't to stop him from making changes. Instead, your job is to:
- Make the cost of changes visible to the organization.
- Ensure that changes are introduced at framework inflection points like the Sprint Review or Sprint Planning rather than in the middle
of an iteration.
- Ensure that everyone (including the CEO) agrees to respect the framework ceremonies, or is willing to accept the costs of
introducing change outside the normal cadence.
So, how do you make these things happen? Collaboration and education! Here are some key techniques.
- Have a conversation with the CEO about how incremental, iterative, and emergent development work together or separately, and how these techniques differ from traditional up-front planning systems.
- Disintermediate yourself, and have the CEO collaborate with the designers on design.
- Educate the CEO on framework ceremonies. Ensure he's introducing work during Backlog Refinement or Sprint Planning, and reviewing the increment during Sprint Review.
- Introduce Acceptance Test Driven Design/Development to encourage a more collaborative approach to product specification.
- Leverage testable specifications to objectively drive the designers' work, rather than trying to guess what is wanted.
- Ensure that the team plans the work, rather than trying to digest the requirements and plan the work on the team's behalf.
- Encourage the CEO to attend the Sprint Planning meetings so that he can see firsthand how his requirements enable or impede the team, and so he can be on hand to answer questions about the work planned for the iteration.
If the CEO is not on board with your current process, then you and he either need to agree on a new process that you can both live with, or you need to resign yourself to the status quo. You can't make anyone do anything, and if you can't collaborate then you can't succeed.