The Three Questions That Stop Bad Salesforce Project Management Before They Start

I watched a client spend six months building a custom service console. Beautiful interface. Smart automation. Integrated with everything.

Three months after launch, adoption sat at 11%. This is something I wanted to share as to why adoption is necessary.

In a dimly lit, modern office, an individual is focused on multiple digital screens displaying data analytics and futuristic graphs, immersed in a high-tech analysis environment.

The team had validated the market need. They'd confirmed technical feasibility. What they'd missed was the third piece: whether their service reps would actually change how they worked to use the new system.

This intrigued me while I was reading about Jeanette Mellinger, who led UX research at Uber during their "Uber Everything" experiments, and who saw this pattern repeat across dozens of ventures. The ones that succeeded had validated three things that the failures hadn't. Not just customer needs. Not just technical delivery. But the behaviour change piece that keeps getting ignored in Salesforce Project Management.

"When we experimented with new businesses that didn't work, I see now they failed because they'd only gotten two of those three things," Mellinger says. Most teams focus on the business case and technical feasibility. The human behaviour part gets hand-waved.

And it kills otherwise solid projects.

After two decades of coaching executives and early-stage teams, Mellinger mapped what separates successful implementations from expensive shelfware: systematically discovering and validating team-problem-solution alignment before building anything.

The problem is worse now. You can spin up a Flow or an Experience Cloud site in an afternoon. Speed feels productive. But here's the thing: it's easier than ever to build a Salesforce solution nobody wants and a process nobody will follow.

Most Salesforce teams miss three validation steps:

• First, we skip asking if they're actually suited to maintain what they're building. You can be great at requirements gathering but terrible at ongoing admin work. That mismatch matters.

• Second, we often confuse "users said they want this" with an actual understanding of workflow context. Five focused on field interviews beat 50 scattered Zoom calls.

• Third, we design features without intending to change behaviour. New tools must be dramatically better than existing workarounds to overcome inertia. Most teams don't even document the current workaround.

The reality: successful Salesforce work requires the intersection of three validations. Who you are as a team. A fundamental problem you're suited to solve. This is a solution that tackles the problem while overcoming behaviour change barriers.

Most teams check one or two boxes. The teams that ship things people use validate all three before building.

Why teams skip the validation that matters most in Salesforce Project Management

Your users have existing habits. They've built workarounds. They know how to get their work done, even if it's messy.

Introducing a new process means asking them to abandon something that works (kind of) for something unknown. That's a higher bar than most project plans acknowledge.

"You can build something desirable but not really needed," Mellinger explains. "Or if people can't figure out how to use it, or the inertia of behaviour change is too strong, then the product won't go anywhere."

The gap isn't user validation. Most teams do discovery calls. The gap is systematic discovery across three dimensions that most teams never consider together:

Team validation: Do you have the specific capabilities and energy to maintain this for years? Are you building in your zone of strength or competence?

Problem validation: Beyond stated pain points, what are users' actual workflows? What behaviour patterns must you understand? What integration points matter most?

Solution validation: Is your solution genuinely 9X better than the current workaround? Have you designed explicit adoption mechanisms, not just features?

"Problem, solution and fit are all different steps, but you can't think about them in isolation from one another," says Mellinger. "And the silent first step is the team. Before thinking about the problem, you've got to start with who's solving it."

Most teams skip this entirely. They race to validate user needs without validating whether they're actually suited to deliver and maintain the solution.

Three validation systems that prevent shelfware

Framework 1: The Team-Problem Fit Audit

Before validating user needs, check whether your team is actually suited to work on this problem with the Four Zones. Not passion. Capability and energy alignment.

One admin worked through this exercise before committing to a complex integration project. One question stopped her: "Would you be willing to maintain this integration for more than three years?"

She thought about it. "Absolutely not. I don't want to debug API calls long-term."

That alone saved months of work building something she'd eventually abandon.

Implementation: Track 2-4 weeks of daily work, noting what energises versus drains you. Create a zones map. Cross-reference with problems you're considering. If solving the problem requires spending most of your time in competence or incompetence zones, reconsider.

Framework 2: The Three-Phase Discovery System

Top teams alternate between three research modes:

Phase 1: Incubation (1 day to 1 month). Don't rush to build. Spend time where your users work. Shadow them. Join their Slack channels. Attend their team meetings. Don't pitch, observe.

For a sales process redesign, this meant sitting in on pipeline reviews for a month. Patterns emerged: reps spent 15 minutes per deal updating fields they considered pointless. That observation changed the entire approach.

Phase 2: Immersion (1 focused week). Go where your users are. Conduct interviews in context, not conference rooms. Five in-context conversations beat 50 Zoom calls.

One consultant building a service console interviewed agents during live shifts, not in offices. She discovered the real problem wasn't the case view layout. It was that agents couldn't access knowledge articles while on calls. That single observation changed the architecture from desktop to split-screen mobile.

"A focused week with your users can get you there faster than months of scattered conversations," Mellinger says.

Phase 3: Integration (1 day to 1 week). Design for the behaviour change your solution requires. Map the complete user journey. At each critical moment, check: Do they want to use this? Is it easy? Do they have a prompt to start?

New solutions must be 9X better than existing workarounds to overcome inertia. If you're not clearly 9X better, redesign or reconsider.

Framework 3: Behaviour-Centric Solution Design

Building something users want is necessary but insufficient. Build something they'll actually change their habits to use.

BJ Fogg's behaviour model: B=MAP. Behaviour happens when Motivation, Ability and Prompt collide simultaneously.

Your solution might be desirable (motivation exists), but if it's not easy (low ability) or users lack a trigger to start (no prompt), adoption fails.

One team built a beautiful opportunity tracking dashboard. High motivation (sales leaders wanted visibility). But it required reps to log activities in real-time. That extra step killed adoption because reps had no prompt to remember, and existing tools (notes, email) were easier to use.

They redesigned around automatic activity capture from email and calendar. Adoption jumped to 73%.

Design behaviour change explicitly: What triggers prompts first use? What makes the first action easier than the current workaround? What immediate value demonstrates this is worth the effort?

Why this works when speed fails

Thoughtful discovery doesn't slow you down. It prevents building in the wrong direction, which is infinitely slower.

"Thoughtful upfront research helps train your intuition so you can move faster and with more intention as you scale," says Mellinger. "It's even easier to speed in the wrong direction really fast now. I want to help people build velocity, which is speed in the right direction."

The teams that ship things people use aren't necessarily the ones who configure fastest. They're the ones who validate team-problem-solution fit before building.

This isn't about taking six months. You can do:

• 2-4 weeks for team-problem fit audit

• 1-2 months for three-phase discovery

• 1-2 weeks for behaviour design

Total: 2-4 months of research before building. Compare that to 12 months building something nobody uses, then starting over.

The choice isn't speed versus thoroughness. It's 2-4 months validating direction versus a year building shelfware.