Why Salesforce Should Be Managed Like a Product, Not Just a Platform
In this Office Hours Insight conversation, Leigh-Anne Nugent shares a smart but often overlooked idea: once Salesforce is implemented, it should be treated like a product. That shift changes everything, from how admins handle requests to how teams prioritize features, avoid distractions, and create more intentional, high-value improvements over time.
LESSONS YOU CAN TAKE FROM THIS:
1. Treating Salesforce like a product creates better decisions
When Salesforce is managed like a living product, it stops being a place for random requests and reactive fixes. Instead, it becomes something that is guided by priorities, outcomes, and structured release thinking. That mindset helps admins and owners stay focused on what creates the most value.
2. The squeaky wheel should not control the roadmap
One of the biggest risks Leigh-Anne highlights is letting the loudest request win. Constant context switching, shiny-object distractions, and low-priority asks can pull attention away from more important work. A product mindset helps protect momentum and keeps teams aligned with bigger goals.
3. Every request needs deeper problem-solving
A request is not always the real need. Someone may ask for a new field, but the actual problem could be process clarity, reporting visibility, or data already captured somewhere else. Great Salesforce management starts by understanding the outcome people want, not just the thing they asked for.
4. Build with purpose, and buy when it makes sense
Leigh-Anne also points to one of the most practical product principles: build versus buy. Not everything needs to be created from scratch. Sometimes the smartest move is to use an existing AppExchange solution, open-source package, or reusable tool, then extend it strategically if needed.
KEY TAKEAWAYS:
Salesforce becomes a product once it is actively supporting business outcomes.
Admins are more effective when they use product ownership principles.
Backlogs and user stories help prevent reactive, disorganized work.
Requests should be evaluated based on the problem being solved, not just the ask itself.
Build-versus-buy thinking can save time, reduce waste, and improve results.
