Platform ROI is a J-curve, not a straight line
Every platform investment gets worse before it gets better. Cost is front-loaded, adoption ramps slowly, and value only shows up once teams migrate. Modeling that curve is what makes the number defensible.
The most common mistake in a platform business case is a straight line, not an inflated number. Model the savings as "X% of toil removed, starting month one," and the first board review will ask why month three doesn't look anything like the projection. It won't, because no platform investment behaves that way. Cost is front-loaded, adoption ramps slowly, and the value only shows up once teams migrate onto it. That's a J-curve, and pretending otherwise gets a platform team's numbers distrusted the first time reality diverges from the deck.
Why the curve dips before it rises
In year one you're paying platform-team salaries, tooling, and the disruption cost of migrating existing services onto new patterns, before many teams have adopted anything. That's the trough. The model this maps to is the one behind the ROI calculator: you build before anyone can adopt, so year-one adoption is lower almost by construction, and a platform that's still being built has no product yet for teams to use.
adoption(year) = plateau − (plateau − y1) × decay^year
Adoption follows an S-curve rather than a step function: it starts low, closes the gap to its plateau geometrically each year, and only in later years does the platform reach the steady state where most of its value is realized. Model adoption as instant and the year-one number will always disappoint whoever approved the budget.
The trap of a single scenario
A model with one number in it ("the platform saves $2M/year") invites one question: "what if you're wrong?" A model with a scenario band answers that before it's asked. Conservative, expected, and optimistic scenarios should move every assumption together: benefit realized, cost incurred, adoption speed, and disruption during migration all shift as a set.
- Conservative: less benefit captured, higher cost, slower and rockier adoption.
- Optimistic: more headroom captured, lower cost, faster and smoother adoption.
None of this means being pessimistic by default. A defensible model has to show its assumptions moving together in a realistic way. A reviewer who sees the conservative case still pay back in a reasonable window trusts the expected case far more than one who only ever saw a single cheerful projection.
Building vs. buying changes the curve as well as the total
A home-grown platform costs differently than a productized one and also changes the shape of the curve. Year-one adoption falls further, because there's no product to adopt until the build finishes. The adoption plateau itself tends to land lower too, because a home-grown platform typically carries more rough edges that cap how much of the org ultimately migrates onto it. A build-vs-buy comparison needs to model both effects, a slower ramp and a lower ceiling, and not only compare sticker prices at steady state.
No double-counting
Total waste removed has to be capped as a share of payroll, and each improvement should remove only the waste it targets, with no compounding multiplier that lets several driver categories claim credit for the same recovered hour. A model that lets faster deploys, fewer incidents, and reduced toil all independently multiply the same underlying hours will always output a number too large to survive a second look. The guardrail should only ever push the total down. It should never let a stack of optimistic assumptions amplify each other into an implausible headline figure.
What gets reviewed
Nobody signing a platform investment reads the model. They read one page: the J-curve chart with the trough labeled and dated, the payback period, and the scenario band around it. Everything else (sensitivity analysis, per-driver waste buckets, the terminal value assumptions) belongs in an appendix. The model's job is to be defensible on request, not to be the pitch itself.