The Test That Separates an MVP from a Temporary System
Two projects can launch with the same number of screens. One will serve as a foundation for growth, while the other will become technical debt that needs to be dismantled. The difference isn't in scope, but in the type of compromise made.
The practical rule: For the first phase, reduce business breadth, not architectural depth. It's acceptable to narrow down the number of processes, units, and customer types being onboarded. However, you must never compromise on the core data model, the authorization model, or the definition of the single source of truth—these should be built correctly once, even if they initially serve only fifty users.
Teams that reduce depth instead of breadth will end up with a system that works for a quarter and then needs to be rebuilt. The broader context of project stages is available in the Salesforce Implementation Guide.
Three Easily Confused Definitions
| Term | What it actually is | When it's suitable | Primary risk |
|---|---|---|---|
| Proof of Concept (PoC) | Technical feasibility demonstration for a single component | When there's genuine doubt about whether something is possible | Tends to be promoted to production |
| Pilot | Full deployment to a limited group | When the solution is known, and the question is adoption | Group isn't representative enough |
| MVP | First production version that generates real value | When you want to learn from actual use | Becomes permanent without a deliberate decision |
The choice among these three isn't semantic. A PoC can be discarded, but an MVP cannot—which is why an MVP must be built to production standards.
Decisions You Cannot Postpone
There's a set of decisions whose cost of change increases by an order of magnitude once data is in production. These decisions must be made in the first phase, even if they initially serve only a small part of the overall picture:
- The object that holds the business process and its relationship to core entities.
- The unique key that identifies a customer across external systems.
- The default visibility for every central object.
- The record ownership structure—who is the Owner and what happens when an employee leaves.
- The definition of the single source of truth for every entity synchronized with another system.
In contrast, decisions that can and should be postponed include: designing advanced reports, convenience automations, integrating secondary channels, localization of units not in the first phase, and integrations not required for real-time decision-making.
How to Choose the First Phase Process
Don't choose the simplest process, nor the most painful. Choose the process that meets all three conditions: it has a single, available process owner; it produces a result visible to management; and it represents the central data model. A process that meets two out of the three is still acceptable; a process that meets only one will result in a first phase that teaches nothing.
Another consideration is volume: a process that occurs ten times a month won't generate enough usage to learn from within a quarter.
Exit Criteria – What Signifies a Successful Phase
An MVP without exit criteria becomes a permanent fixture. The criteria must be measurable, concise, and predefined. Example structure:
- A percentage of processes of the chosen type are actually performed within the system, not outside it.
- No blocking defect remains open for more than a defined number of days.
- The data generated during the period meets the predefined quality threshold.
- The process owner confirms in writing that the process runs without a permanent workaround.
Note that none of these is "the system went live." That date is the starting point for measurement, not its end.
Cost of Delay – The Tool That Resolves Scope Debates
When debating whether a capability belongs in the first phase, the useful question isn't how much it costs to build now, but how much it costs to build later. The following table serves as a working tool in a scope meeting:
| Capability Type | Cost to build in Phase 1 | Cost to build in Phase 2 | Conclusion |
|---|---|---|---|
| Change to core object structure | Low | Very High – includes migration | Included in Phase 1 |
| New authorization model | Medium | High – exposure has already occurred | Included in Phase 1 |
| Management report | Low | Low | Postponed |
| Alert automation | Low | Low | Postponed |
| Integration required for real-time decision | High | High + entrenched workaround | Included if the process depends on it |
| Integration for reporting only | Medium | Medium | Postponed |
Illustrative Example: International Logistics Company
This scenario is hypothetical and illustrative. A shipping company operating in three countries wanted to launch an MVP within eleven weeks. The initial proposal was to include all three countries, but only the quote stage, without the order stage.
The team reversed the cut: one country, but the full process from quote to confirmed order, including the integration that pulls rates. The reason was simple—cutting the process in the middle would require users to continue in the old system for the order stage, meaning double data entry. Instead of learning if the system helped, the company would learn that the system was burdensome.
The total scope in weeks remained similar. What changed was that after the first phase, the company had a complete, working process, not half a process across three countries.
Signs an MVP Has Become a Temporary System
- A permanent manual process exists, intended to "bridge until the next phase," and has been in place for over two months.
- A field was agreed upon to serve two different purposes because there wasn't time to split it.
- A group of users works simultaneously in two systems.
- There's no decision date for the next phase, only a waiting list.
These patterns, along with other failures, are extensively discussed in the CRM Implementation Mistakes Guide.
Integration with the Overall Timeline
Defining an MVP directly impacts project duration, and sometimes in the opposite direction expected: too narrow a first phase lengthens the overall project, because each phase carries fixed costs for testing, training, and go-live. How to translate this into a realistic detailed plan is covered in the Salesforce Project Timeline Guide, and in the case of replacing an existing system, also in the Replacing CRM with Salesforce Guide.
Next Step
In one sentence, describe the first phase's process, its process owner, and the criteria that will indicate its success in three months. If any of these three sentences cannot be written right now—that's your starting point, not the feature list.