Different from greenfield Discovery — you're evaluating fit of an existing package, not designing from scratch.
Process:
1. Document the requirement:
- What problem is the package supposed to solve?
- What's the current pain?
- What does success look like?
2. Inventory candidate packages:
- Search AppExchange. Filter by category, edition compatibility, security review.
- Shortlist 3-5 candidates.
- Check independent reviews (G2, Capterra, AppExchange ratings).
3. Score against requirements:
For each candidate:
- Functional fit — % of needs covered out of the box.
- Customisability — what can you configure vs forced by package design.
- Integration — APIs available? Open enough to extend?
- Performance — any reports of issues at scale?
- Vendor health — financial stability, recent updates, support quality.
- Pricing — total cost of ownership over 3-5 years.
- Reference customers — comparable orgs using it successfully.
4. Demo / trial in a sandbox:
- Don't trust marketing materials alone. Install in a sandbox.
- Walk through actual scenarios with the data model.
- Identify gaps — what's missing, what's awkward.
5. Talk to references:
- 2-3 customers using it. Ask:
- What problems did it solve?
- What surprised you (positive or negative)?
- How responsive is the vendor?
- Would you choose it again?
- Any anti-patterns you've hit?
6. Evaluate exit cost:
- If you adopt and later regret, what's the cost of switching?
- Does the package store proprietary data? How portable?
- Are there competitors you could migrate to?
7. Decide and document:
- Comparative scoring table.
- Recommendation with rationale.
- Implementation effort estimate.
- Trade-offs accepted.
Common evaluation mistakes:
- Believing the demo. Vendor demos are polished; reality is messier.
- Underestimating customisation needs. "We'll customise" — managed packages have customisation limits.
- Ignoring vendor health. Cheap package from a 5-person company is risky.
- Skipping references. Customer voice is the truest signal.
- Cost-only decision. Cheapest is rarely best.
- Overlooking the platform. Some packages are sold as "Salesforce-native" but actually replace large parts of standard functionality.
Senior consultant insight: AppExchange is a strong default for solving common problems but only when the package fits. Force-fitting a package to your needs creates the worst of both worlds: package costs + customisation overhead.
The recommendation framework: build > native > package sometimes is correct (when needs are too specific); other times package > native > build wins (when problem is generic and package is mature).