In Salesforce Projects, “Everything Is a Priority” Isn’t a Strategy
At the beginning of a Salesforce project, everything tends to feel precious. Every feature has an advocate. Every automated email is essential. Every report is urgently needed and every formula field to output summary details on a Contact record is somehow a blocker.
If you’ve spent time around software teams, you may have encountered a prioritization scale that looks something like this:
Low
Medium
High
Drop everything and tell your loved ones you’ll see them next week
The labels are funny because they expose a familiar problem: when ordinary priorities aren’t producing the desired response, we invent a more urgent priority.
But adding another level above “high” doesn’t help a team decide what matters. Honest prioritization does.
Start With the Constraint That Can Move
Every project operates within a constraint model that project managers call the iron triangle:
Time: what is the actual deadline?
Cost: how much labor investment can be made?
Complexity/Scope: how “perfect” must processes be before the team can go live with the solution?
As in geometry, if two of the sides of the triangle are fixed length, you lose the ability to adjust the third. In many projects, timeline and budget are fixed, meaning that scope has to adjust. This isn’t pessimism, it’s mathematics.
Salesforce projects make this especially important because features are not equal in complexity. A field that appears simple may affect automation, permissions, reports, integrations, and historical data. A request that sounds large may be straightforward when it uses the platform’s standard capabilities.
Counting features, therefore, tells us very little. We need to understand the effort, risk, dependencies, and value behind each one.
Without those distinctions, a project plan quietly assumes that every request can be completed within the original constraints. The team discovers otherwise only after time and budget have already been spent.
Prioritization Should Begin with the Mission
The most useful prioritization question isn’t, “Which feature does each stakeholder want most?”
It’s, “What outcome is this project supposed to produce?”
A strong mission statement or project charter gives the team a stable point of reference. When a new request appears, we can evaluate it against the project’s purpose:
Does this directly support the desired outcome?
Who benefits, and how significant is that benefit?
Is it necessary for launch, or could it come later?
Does it reduce risk or unblock other work?
Are there work-arounds which achieve necessary outcomes, even if they are less desirable?
What higher-priority work would we delay by doing this now?
That last question is critical. Adding scope is never free. Even when a request sounds small, it consumes attention, testing, decision-making, documentation, and deployment capacity. Prioritization means acknowledging that trade-off openly.
“Not Now” Is Different From “Not Valuable”
This is often the hardest part of the conversation. Stakeholders usually advocate for features because they see genuine value in them. The finance team needs accurate, quickly generated reports. Fundraisers and Programs teams want high-context engagement data with low barriers to access. Leadership wants summary-level visibility into all key performance indicators at all times.
Those needs can all be legitimate without all being equally urgent.
Imagine a nonprofit implementing Salesforce to improve fundraising operations. The first release might need to deliver reliable donor records, gift processing, acknowledgments, and essential reporting. A sophisticated set of email journeys could also create value, but does the organization need every automation before staff can begin using the system? Probably not.
Launching the core fundraising process first allows the organization to start realizing value, gather feedback from real users, and make better decisions about later automation. Delaying those email journeys isn’t abandoning them. It’s sequencing the work strategically.
That is the difference between prioritizing for time-to-value and waiting for perfection.
Honest Prioritization Protects the Highest-Value Work
A project can have a prioritized backlog and still behave as if everything is equally important. This happens when lower-priority items return through side conversations, “quick favors,” or ad hoc requests. Individually, each request may seem harmless. Collectively, they pull at the loose strings of the project until the team is spending substantial time on work everyone previously agreed could wait.
Honest prioritization requires discipline after the planning session:
High-priority work receives the team’s focus
Lower-priority work remains visible without quietly entering the current release
New requests are evaluated against existing commitments
Changes in priority are explicit and include the corresponding tradeoffs
If a new request genuinely becomes the highest priority, that’s fine. Priorities should change when circumstances change. But the team should also identify and be comfortable with what moves down as a result.
Pushback Is Part of Good Consulting
A consultant’s role isn’t simply to accept a list of requirements and build it in the order received. Good consulting includes respectful pushback. We should be willing to ask whether a requested feature supports the mission, whether a simpler approach could achieve the same result, and whether the organization is ready to sustain the solution after launch.
That can occasionally feel uncomfortable. It is also one of the most valuable things a consulting partner can provide. When we challenge prioritization, we aren’t dismissing stakeholders’ ideas or protecting ourselves from difficult work. We’re helping the organization direct limited time and budget toward the outcomes that matter most. The alternative is allowing passion projects, louder voices, or the newest request to consume resources intended for mission-critical work.
Progress Creates Better Information
There is another benefit to delivering the highest-yield capabilities first: using a working system teaches us things that planning cannot.
Once people begin working in Salesforce, we learn:
Which processes occur most often
Where users actually experience friction
Which reports influence decisions
Where automation will have the greatest impact
Which original assumptions were incomplete
Which “must-have” features were not initially reported
That information improves every later prioritization decision.
A smaller, well-designed release can therefore be more valuable than a comprehensive system delivered much later. The organization begins receiving value sooner, and the roadmap becomes grounded in evidence instead of speculation.
The Goal Isn’t to Build Less, It’s to Build in the Right Order
Prioritization doesn’t mean important ideas disappear. It means the organization makes a deliberate decision about sequence.
First, establish the mission. Then identify the outcomes that create the most value. Protect the work required to achieve them and treat new requests as tradeoffs. Finally, use what you learn after launch to guide the next investment.
A Salesforce implementation will always contain more possibilities than a single timeline or budget can accommodate. That’s a strength of the platform, but only if the project team is prepared to make choices.
When everything is “drop everything” important, nothing really is.
Ready to bring greater clarity and more honest prioritization to your Salesforce roadmap? Canvas Cloud can help you identify the highest-value work, manage competing requirements, and build a practical path from today’s needs to tomorrow’s possibilities.
About the Author
Sean “Conner” Conner is a Salesforce Solutions Architect.
