How Many People Should Be in Salesforce Project Meetings?

The Situation

You’ve signed up to work with someone to implement Salesforce.

It’s a big deal.

So naturally, you start thinking about Salesforce project meeting attendees and who should be involved.

Your instinct?

“Let’s invite everyone even remotely connected so we don’t miss anything.”

147% of the time it does not work.

The Short Answer

Your Salesforce project meeting attendees need to check a few boxes:

1. Knowledgeable of the real processes

2. Influential enough to drive usage after go-live

3. Able to actually test the system

4. Able to support the build (data, answers, decisions, tradeoffs)

Ideally, this is one person per functional area.

That’s it.

Forbes suggest that the ideal size is 7.

Bringing 15 people into a meeting is a near-guarantee that:

• Decisions stall

• Edge cases dominate the conversation

• Nobody owns anything

• The implementation takes a nose dive.

Salesforce Project Meeting Attendees: What Actually Goes Wrong

I’ve seen this play out more times than I can count.

The intention is always good:

• “We want everyone heard”

• “We don’t want to miss anything”

• “We want buy-in”

But that’s not how systems get built.

A healthy CRM does not capture every edge case, does not reflect every personal preference, and it does not solve every historical frustration.

A healthy CRM moves the business forward.

Your meeting structure needs to reflect that.

The Root Causes

1. FOMO (Fear of Missing Out)

You’re afraid something important won’t get said.

So instead of selecting the right people you invite all the people.

What happens instead?

You don’t miss anything.

You just never decide anything.

2. Lack of Clarity on Who Actually Matters

A massive group means no one truly owns processes, outcomes, and day-to-day execution.

This is safe.

It’s also slow and unproductive.

3. Mistaking Participation for Adoption

This one gets people all the time.

You think that people in the meetings are more likely to adopt the system.

Here is a dose of reality.

• 3–4 people talk

• 10–12 people sit on mute browsing YouTube

• nobody is active learnin mode

Meetings ≠ training

Meetings ≠ adoption

Meetings are meetings

What This Looks Like in Real Life

It follows the same pattern almost every time:

1. 12–15 people are invited

2. Everyone has slightly different needs

3. Edge cases dominate the conversation

4. Decisions stall because no one can align

5. Action items don’t have real owners

6. Frustration builds quietly

Eventually progress slows, people disengage, and the system becomes a compromise that nobody wants to engage with.

This is a recipe for a broken Salesforce environment.

What More People Actually Means

More people doesn’t mean better input.

I love you all but more people amounts to more politics, opinions, personal preferences, and distortion.

Leaders on the org chart are often not the best people to design the system.

Not because they’re wrong.

Because they’re removed from the constraints.

They don’t click through every field, deal with friction daily, or have a tangible feel for the inefficiencies.

So what gets built?

A system that sounds right, but doesn’t actually work.

Why It Keeps Happening

Salesforce projects are high stakes.

You’re paying:

• $10K–$50K+ per year in licenses

• $20K–$100K+ for implementation

So your instinct is to cover all your bases.

But covering all your bases creates a different problem:

Too many motivations in the room.

• Jim wants flexibility

• Sarah wants attribution

• Paul wants visibility

• Johan wants structure

Instead of alignment you get gridlock.

The Cost of Ignoring This

Time

• Meetings become a waste of time.

• Decisions stall

• Projects take 2–3x longer

Money

• You burn consulting hours with no progress

• You pay for licenses you’re not fully using

• Rework becomes inevitable

Stress

• People disengage

• Frustration builds quietly

• Confidence in the system drops

And the worst part?

You end up needing to read something like why most companies should fix Salesforce instead of starting over.

What Good Looks Like Instead

Your Salesforce project meeting attendees should be small and intentional.

The Right Makeup

Per functional area:

• 1 person who actually does the work

• 1 person who understands outcomes

That’s it.

The Traits That Matter

• Knows real workflows (not theoretical ones)

• Will use the system after go-live

• Can test without hand-holding

• Can make decisions or escalate quickly

What This Creates

• Faster decisions

• Clear ownership

• Practical system design

• Higher adoption

If You’re Already Mid-Project

If you’ve already got 12–15 people in meetings…

You don’t need to blow it up.

Just do this:

• Reduce the core group immediately

• Keep others as “on-call” input

• Move from group design → targeted feedback

It will feel uncomfortable.

It will also save your project.

Closing Thought

This is one of those situations where doing the “safe” thing creates the worst outcome.

More people feels responsible.

In reality, it’s what quietly derails Salesforce projects.

If you want this to work keep the group small, keep it grounded, and build for reality, not consensus.

If you’re in the middle of this or dealing with the aftermath, let’s talk.

We’ll help you simplify it and get things moving again.