Salesforce Discovery Phase: 4 Steps to Avoid Watermelon Projects [Guide]
Salesforce discovery phase failures cause most project disasters. A 4-step framework from a CTA with experience across NEOM, Carlsberg, and enterprise programs.
A watermelon project delivers features but no business value—green status reports hiding red reality. Discovery phase failures are the root cause of most these disasters. This framework prevents them: challenge requirements, map processes, find owners, define exclusions.
The watermelon project problem
Green on the outside, red on the inside.
Features are “delivered.” Milestones are “met.” Status reports show green across the board. But twelve months later, you’ve spent the full budget and the business is asking why nothing has improved. Adoption is near zero. The system solves no one’s actual problem.
This is the watermelon project. And it almost always starts with a weak discovery.
Why discovery gets treated as a formality
I’ve seen this pattern repeat across my years at Publicis Sapient, IBM, and multiple enterprise implementations as a Salesforce Certified Technical Architect (CTA). The discovery phase gets compressed, rushed, or staffed with the wrong people. There are reasons for this, and none of them are good.
Vendors want to start implementation. Once code is being written, the project hits a point of no return. Contracts are signed, teams are staffed, momentum is building. Stopping to question fundamentals becomes politically difficult. Discovery that runs too long looks like indecision. So it gets shortened to fit the sales cycle.
Both parties under-engage. The client assumes the vendor knows their business. The vendor assumes the client knows what they want. Neither invests the time to bridge that gap. Workshops become box-checking exercises. Stakeholders send delegates instead of decision-makers. Questions go unanswered because the right people aren’t in the room.
The wrong team leads discovery. Not every consultant can run effective discovery. It takes someone who can challenge assumptions, call out political dynamics, and push back on unrealistic scope. When discovery is led by people without these skills, foundational problems get baked into the roadmap.
“Wow factor” beats foundation. The features that get attention during discovery are the ones that demo well. Complex integrations, data migration, security architecture? These don’t generate excitement in a steering committee. So they get deprioritized. The flashy features make it onto the roadmap. The foundational work that makes them possible gets underestimated or ignored.
The result? A roadmap built on assumptions no one validated. A timeline based on scope no one fully understood. A project that looks healthy until it isn’t.
4 steps to get discovery right
These aren’t theoretical best practices. They’re the things I’ve seen separate projects that deliver value from projects that become expensive lessons.
1. Challenge the “why” behind every “what”
The business asks for a new component, a custom object, a workflow automation. Don’t just document it. Push back.
Ask these questions:
- Why do you need this? What specific process outcome does it drive?
- What happens if we don’t build it?
- How do you handle this today, and what’s actually broken?
- Who will use this, and have you talked to them?
This is how you avoid building expensive features nobody uses. Every requirement should trace back to a business outcome. If someone can’t articulate the outcome, the requirement isn’t ready.
I’ve watched entire workstreams get eliminated during discovery simply because someone finally asked “why?” The answer was often “we’ve always done it that way” or “someone requested it years ago.” Neither is a reason to build functionality.
| Requirement | Ask “Why?” | Business Outcome | Decision |
|---|---|---|---|
| Custom approval workflow | ”Finance needs visibility into large deals” | Reduce deal review time by 50% | ✅ Build |
| Custom object for tracking | ”Someone requested it years ago” | No measurable outcome identified | ❌ Don’t build |
| Integration with legacy ERP | ”Operations can’t function without inventory data” | Enable real-time order fulfillment | ✅ Build |
| Dashboard with 50 reports | ”Nice to have for leadership” | No decision tied to specific reports | ⚠️ Reduce scope to 5 critical reports |
2. Map the process, not the features
Map the entire business process from end to end. Use whatever works for your team: a physical whiteboard in a face-to-face workshop (still the best option when possible), Miro, Mural, or LucidChart for distributed teams. The tool matters less than getting the right people in the room. What you’re mapping isn’t the system features you want to build, but the actual business process with all its handoffs, exceptions, and edge cases.
If you can’t draw the flow of data and decisions across the organization, you have no business automating it. You’ll end up digitizing confusion.
The process map reveals where data originates, where handoffs break down, and which steps are actually necessary versus legacy artifacts nobody questioned.
This map becomes your source of truth. Stakeholders disagree? Point to the map. Scope creep? Test it against the map. Implementation stuck? The map shows where your assumptions were wrong.
Most projects skip this step or do it superficially. They map the happy path from the demo and assume everything else will work itself out. It won’t.
3. Find the real owner
Every process needs a single, empowered owner. Not a committee. Not a working group. One person who can make decisions and be accountable for outcomes.
If the business can’t provide this person, your discovery will fail. You’ll spend months building by committee, navigating politics, and compromising on everything. The end product will satisfy no one because it was designed to offend no one.
You’ll know you don’t have a real owner when decisions require multiple sign-offs with no clear hierarchy, when different stakeholders give contradictory requirements, and when “we’ll figure that out later” becomes a common response. Requirements that change based on who’s in the room are a dead giveaway.
A real owner makes scope decisions without escalating everything, resolves conflicts between groups, and stays engaged throughout discovery—not just kickoff.
When you have the right owner, discovery moves faster and produces clearer outcomes. When you don’t, you’re building a system for a process that doesn’t have organizational commitment.
4. Define clear exclusions
Discovery isn’t only about what you will do. It’s about defining what is out of scope.
This is the ruthless separation of true must-haves from nice-to-haves. And here’s the uncomfortable truth: most “must-haves” aren’t. They’re preferences dressed up as requirements because someone with enough authority wanted them.
Real must-haves are things the process cannot function without, regulatory requirements, or features users will reject the system over. Everything else is negotiable. And it should be negotiated during discovery, not during implementation when changes are expensive.
Here’s the thing stakeholders often miss: clear exclusions protect their priorities. When everything is “must-have,” nothing gets the focus it deserves. By explicitly removing distractions from scope, you ensure the team concentrates on what actually drives business outcomes. The exclusion list isn’t about saying “no” to stakeholders. It’s about protecting their ability to succeed with what matters most.
| In Scope (Phase 1) | Explicitly Out of Scope |
|---|---|
| Core opportunity management workflow | Custom forecasting dashboards |
| Integration with ERP for order data | Real-time inventory sync (Phase 2) |
| Standard approval process for quotes | Complex multi-currency pricing rules |
| Basic reporting on pipeline metrics | AI-driven lead scoring |
| User training for sales team | Admin training for custom development |
Document exclusions formally. Get sign-off. Refer back to them throughout the project. When stakeholders ask “can we also add…?” you have something concrete to point to. The clearer your boundaries, the more likely you are to deliver what’s inside them.
What Happens When Discovery Phase Succeeds
You get a roadmap that isn’t a fantasy. It’s a practical, executable plan based on validated requirements and realistic constraints.
Every feature is tied to a business outcome. Stakeholders understand what they’re getting and what they’re not. The team knows what success looks like. The budget reflects actual scope, not wishful thinking.
When discovery is done right, implementation becomes execution rather than exploration. You’ve already explored. You’ve already made the hard decisions. Now you’re just building what you decided to build.
That’s the difference between a project that delivers value and one that just delivers features.
What Happens When Discovery Phase Fails
You build exactly what was “required,” but it solves no one’s actual problem. The requirements were documented, but they were never validated. The scope was agreed, but it was based on assumptions that turned out to be wrong.
Twelve months later, you’ve delivered a system. The features work. The test cases pass. But adoption is minimal. Business outcomes haven’t changed. The executive sponsor is asking difficult questions, and the only honest answer is: we built the wrong thing.
From my experience in consultancies, this happens more often than anyone wants to admit. Projects “succeed” in the narrow sense of delivering what was specified. They fail in the meaningful sense of delivering value. The discovery phase is usually where the failure started. It just took months of implementation to become visible.
The worst part? Everyone saw it coming. The warning signs were there in discovery. The questions that weren’t answered. The stakeholders who weren’t engaged. The scope that kept shifting. The timeline that felt optimistic from day one.
But once implementation starts, the incentives shift. Stopping is harder than continuing. Raising concerns feels like negativity. So the project continues, accumulating problems that become too big to fix.
A roadmap is not a contract
One clarification: a well-built roadmap isn’t set in stone. Reality changes. Business priorities shift. New information emerges during implementation. The goal isn’t to create a plan you follow blindly for twelve months.
The goal is to make informed decisions from the start, so when adjustments are needed, you’re adapting from a position of understanding rather than scrambling to catch up. Methodologies like SAFe build this in explicitly: regular inspect-and-adapt cycles, PI planning that acknowledges uncertainty, and structured ways to incorporate new learning without derailing the entire program.
A good discovery gives you a baseline. It’s the difference between “we planned for X but now need Y, here’s how we adjust” versus “we never really understood what we were building, and now everything is changing.”
Key takeaway
A roadmap’s accuracy is a reflection of the quality of its discovery.
Discovery isn’t a formality you rush through to get to the “real work.” It is the real work. It’s where you ensure you don’t waste months building the wrong thing.
The four steps aren’t complicated. Challenge requirements. Map processes. Find owners. Define exclusions. But they require time, the right people, and genuine engagement from both vendor and client.
Skip this, and you’re gambling that your assumptions are correct. Sometimes you’ll get lucky. More often, you’ll end up with a watermelon project: green on the outside, red on the inside, and everyone wondering what went wrong.
Related
This post is part of a series on enterprise Salesforce implementation strategy:
- Before you buy: 5 Questions That Expose OOTB Feature Gaps Before You Buy helps you evaluate whether “out-of-the-box” will actually work for your requirements.
- Before you go live: Salesforce Data Migration Strategy: 4 Steps That Prevent Day-1 Disasters covers how to approach data migration as a strategic business transition.
Original post
This article expands on a LinkedIn post from my feed: