The Bedrock Platform Commitment Test
Check whether your operating rhythm can hold a platform still for developers.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 6
- Confidence
- 64%
Platform businesses ask for a promise most companies cannot keep: freeze the target for years so third parties can invest against it. Whether you can keep it is decided by your existing operating rhythm, not your ambition. An organisation whose product cycle is iterative, with new hardware for every title and tweaks made as it goes, has no muscle for a frozen specification, and it will keep shipping variants that fragment the very target developers were promised. Run the test before entering: what is our natural change cadence, what does the ecosystem need held still, and who has the authority to say no to a mid-cycle change? If those answers conflict, either build the governance that can hold the line, or stay a supplier on someone else's platform and keep the margin you already earn.
Origin
Extracted from Acquired's analysis of Sega, whose arcade business tweaked hardware with every new game and never developed the discipline a five-year console platform required.
Core principles
- 01A platform is a promise to hold a target still long enough for others to invest against it.
- 02Your ability to keep that promise is set by your existing operating rhythm, not your ambition.
- 03Iterative, per-product hardware cycles build no muscle for a frozen specification.
- 04Third parties price your change cadence into whether they build for you at all.
- 05Being an excellent supplier on someone else's platform is a legitimate answer.
How to run it
- 1
Measure your natural change cadence
Look at your last three product cycles and record how often the specification third parties depend on actually changed. Use shipped reality, not the roadmap.
Pro tip Count silent changes too: a spec that changes without an announcement is the most expensive kind for partners.
- 2
Measure the freeze the ecosystem needs
Ask third parties how long a target must stay stable before they will fund a build against it. That window is set by their payback period, not your release calendar.
Pro tip Ask what would make them cancel mid-build; the answer names your real constraint.
Watch out Partners will state an optimistic window in a sales conversation and a realistic one in a post-mortem.
- 3
Name the gap out loud
Put the two numbers side by side in front of the decision-makers. A cadence far shorter than the required freeze is a structural conflict, not a communication problem.
Watch out Teams routinely reclassify this gap as a partner-education issue and proceed anyway.
- 4
Assign veto authority for the freeze
Identify the person or body who can refuse a mid-cycle specification change, including one requested by the parent company or the founder.
Pro tip Give that veto to whoever owns the third-party relationship, not to whoever owns engineering.
Watch out If the veto sits with the same group that benefits from shipping changes, it does not exist.
- 5
Choose the honest role
Either fund the governance and the multi-year commitment, or decide to be a first-class developer on someone else's platform and keep your existing economics.
Pro tip Model the supplier path with real numbers before dismissing it; it is often the higher-margin outcome.
Watch out The worst outcome is a half-commitment that consumes platform-scale R&D while delivering supplier-scale trust.
- 6
Publish the commitment window
State the years you will hold the specification, and what you will not change within them. A public commitment is what partners actually price.
Pro tip Pair the window with a compatibility guarantee for anything shipped inside it.
Watch out Breaking a published window costs more trust than never publishing one.
In the wild
Sega's arcade business built each game on its own tweaked hardware board, iterating continuously and leading the industry technologically because of it. That rhythm was a genuine advantage in arcades, where every cabinet was a self-contained system and no outside developer was betting on a fixed target. Carried into home consoles it became a liability: developers needed a specification held still for years, and Sega's instinct was to keep changing the hardware.
→ Sega shipped the Sega CD, the 32X and the Saturn in rapid succession, fragmenting the target and losing third-party support.
A hardware component vendor with a six-month refresh cycle considers launching its own developer platform. Running the test, it finds partners need roughly three years of stability, while its own specification has never gone more than nine months unchanged, and no single executive can block a mid-cycle revision requested by the largest customer. It chooses to ship a reference SDK on an existing platform instead.
→ The vendor keeps its iteration speed and its margin, and avoids a platform commitment it could not have honoured.
Common mistakes
Treating hardware readiness as launch readiness
A platform is ready when the ecosystem around it is ready: titles, retailers, tooling and marketing. Shipping because the silicon works launches a platform with nothing on it.
Letting the parent's cadence override the promise
A parent company under pressure will demand schedule changes that break the freeze. Without a named veto, the platform promise is only as durable as the parent's worst quarter.
Running two of your own platforms at once
Overlapping targets force partners to choose between two of your products. Most will resolve the ambiguity by choosing a competitor instead.
Is it for you?
Best for
Companies with a strong iterative product culture considering a move into a platform or ecosystem business.
Not ideal for
Businesses with no third-party dependency, where nobody outside the company is investing against your specification.
From the transcript
“So they didn't actually have to think about we need to create a standard platform for developers to target for the next five years because…”
“This is the standard thing, and we promise not to change it, and we will create a bedrock platform for you developers. That's not really…”
“The type of game you make for an arcade is very different than the type of game you make for a $60 packaged good home…”
From the episode
Short: The Death of Sega