Platform or product boundary
Clarify when a shared internal capability needs product ownership rather than a one-off service.
The decision
Who is the customer of this shared capability?
Assumptions and limits
This tool does not assert that every shared component should become a platform.
Describe your situation
Decision context
Do multiple teams rely on a common capability?
- Yes
- No
- Unclear
Decision context
Is there a team accountable for support and change?
- Yes
- No
- Not defined
Demand and boundaries
Do consumers need the same capability rather than similar implementations?
Compare actual workflows and constraints. Repeated code alone does not establish one shared product need.
- Yes, supported by evidence
- Partly, with known gaps
- No, the check is not met
- Unknown, not verified
Demand and boundaries
Is adoption easier than the consumers’ current alternative?
Include migration, learning, integration and support effort. Availability of a shared service does not prove useful adoption.
- Yes, supported by evidence
- Partly, with known gaps
- No, the check is not met
- Unknown, not verified
Service experience
Can consumers complete the intended task without an operator ticket?
Test the specific self-service path, permission boundary and error recovery. Not every privileged action should be self-service.
- Yes, supported by evidence
- Partly, with known gaps
- No, the check is not met
- Unknown, not verified
Service experience
Are platform reliability and capacity promises agreed with consumers?
Check workload limits, support coverage, incident handling and which team owns product-level recovery.
- Yes, supported by evidence
- Partly, with known gaps
- No, the check is not met
- Unknown, not verified
Evolution and investment
Can consumers upgrade or leave without an unbounded coordinated change?
Review API compatibility, migration windows, export needs and deprecation ownership.
- Yes, supported by evidence
- Partly, with known gaps
- No, the check is not met
- Unknown, not verified
Evolution and investment
Is platform work funded and prioritized by consumer outcomes?
Use a named sponsor, roadmap capacity and consumer feedback. Utilization or feature count alone is not platform value.
- Yes, supported by evidence
- Partly, with known gaps
- No, the check is not met
- Unknown, not verified
How this tool works
Each selected answer maps to a stated observation and a check to perform. Answers are not weighted, added together, or converted into a score, diagnosis, or automatic recommendation.
An unknown answer identifies evidence to collect. Review each observation against your system and constraints; one favorable answer does not establish overall readiness or fit.
Model assumptions
- This tool does not assert that every shared component should become a platform.
- Responses are self-reported and have not been independently verified.
Do multiple teams rely on a common capability?
Yes: A shared capability needs an explicit service contract.
Check: Name internal customers, adoption goals, and an owner.
No: A platform abstraction may be premature.
Check: Keep the capability close to the product until reuse is real.
Unclear: Demand is not established.
Check: Interview teams about actual repeated work.
Is there a team accountable for support and change?
Yes: Ownership can support a platform promise.
Check: Define self-service, support, and deprecation terms.
No: A shared service without an owner can become a bottleneck.
Check: Assign ownership before expanding adoption.
Not defined: The operating model is incomplete.
Check: Map on-call and change approvals.
Do consumers need the same capability rather than similar implementations?
Yes, supported by evidence: There is an evidenced common outcome for the proposed platform.
Check: Retain consumer cases and explicitly exclude incompatible needs.
Partly, with known gaps: Some needs align, but forcing divergent workflows into one abstraction could increase work.
Check: Compare two teams’ hardest workflows and identify the genuinely shared contract.
No, the check is not met: The proposed platform does not yet have a coherent shared customer problem.
Check: Compare two teams’ hardest workflows and identify the genuinely shared contract.
Unknown, not verified: Missing evidence prevents a conclusion. Compare actual workflows and constraints. Repeated code alone does not establish one shared product need.
Check: Compare two teams’ hardest workflows and identify the genuinely shared contract.
Is adoption easier than the consumers’ current alternative?
Yes, supported by evidence: The consumer has a concrete reason to adopt the platform.
Check: Review adoption effort and retained value with the first consumers.
Partly, with known gaps: A benefit exists, but onboarding costs may outweigh it for some teams.
Check: Pilot a real onboarding and compare consumer work before and after, with exceptions recorded.
No, the check is not met: Mandated adoption could transfer work to consumers without a demonstrated benefit.
Check: Pilot a real onboarding and compare consumer work before and after, with exceptions recorded.
Unknown, not verified: Missing evidence prevents a conclusion. Include migration, learning, integration and support effort. Availability of a shared service does not prove useful adoption.
Check: Pilot a real onboarding and compare consumer work before and after, with exceptions recorded.
Can consumers complete the intended task without an operator ticket?
Yes, supported by evidence: Self-service has a bounded, tested outcome and safe escalation.
Check: Keep privileged exceptions explicit and measure the remaining support queue.
Partly, with known gaps: Common actions are self-service, but failure or permission exceptions still need manual help.
Check: Observe one consumer completing the task, including a rejected request and recoverable error.
No, the check is not met: The platform promise currently depends on an unplanned operator queue.
Check: Observe one consumer completing the task, including a rejected request and recoverable error.
Unknown, not verified: Missing evidence prevents a conclusion. Test the specific self-service path, permission boundary and error recovery. Not every privileged action should be self-service.
Check: Observe one consumer completing the task, including a rejected request and recoverable error.
Are platform reliability and capacity promises agreed with consumers?
Yes, supported by evidence: Consumers can plan around an explicit platform service boundary.
Check: Review service limits against real consumer workloads and incidents.
Partly, with known gaps: Basic support exists, but capacity or incident responsibility remains ambiguous. Resolve the prerequisite's remaining gaps before making the stated commitment.
Check: Agree the platform/product responsibility split and rehearse one dependency outage.
No, the check is not met: The platform is a shared dependency without an agreed operating promise.
Check: Agree the platform/product responsibility split and rehearse one dependency outage.
Unknown, not verified: This prerequisite is unverified, not proven absent. Resolve its evidence before making the stated commitment. Missing evidence prevents a conclusion. Check workload limits, support coverage, incident handling and which team owns product-level recovery.
Check: Agree the platform/product responsibility split and rehearse one dependency outage.
Can consumers upgrade or leave without an unbounded coordinated change?
Yes, supported by evidence: The platform has a practical evolution and exit boundary.
Check: Keep compatibility and retirement evidence for the next version.
Partly, with known gaps: An upgrade path exists, but some consumers may require coordinated rewrites.
Check: Rehearse one consumer migration and record owner, dependencies and unsupported cases.
No, the check is not met: Shared adoption could create a new internal lock-in bottleneck.
Check: Rehearse one consumer migration and record owner, dependencies and unsupported cases.
Unknown, not verified: Missing evidence prevents a conclusion. Review API compatibility, migration windows, export needs and deprecation ownership.
Check: Rehearse one consumer migration and record owner, dependencies and unsupported cases.
Is platform work funded and prioritized by consumer outcomes?
Yes, supported by evidence: Investment has a decision owner and evidence of consumer value.
Check: Review the roadmap against reduced consumer work or an agreed service outcome.
Partly, with known gaps: Support funding exists, but evolution competes with unowned or conflicting requests.
Check: Name the sponsor and resolve one competing consumer request using explicit decision criteria.
No, the check is not met: The team is promising a product without sustained investment authority.
Check: Name the sponsor and resolve one competing consumer request using explicit decision criteria.
Unknown, not verified: Missing evidence prevents a conclusion. Use a named sponsor, roadmap capacity and consumer feedback. Utilization or feature count alone is not platform value.
Check: Name the sponsor and resolve one competing consumer request using explicit decision criteria.
Hypothetical worked example
These illustrative inputs are not your result, a customer case, or a benchmark. Change the inputs above to review your own situation.
- Do multiple teams rely on a common capability?
- Unclear
- Is there a team accountable for support and change?
- Not defined
- Do consumers need the same capability rather than similar implementations?
- Unknown, not verified
- Is adoption easier than the consumers’ current alternative?
- Unknown, not verified
- Can consumers complete the intended task without an operator ticket?
- Unknown, not verified
- Are platform reliability and capacity promises agreed with consumers?
- Unknown, not verified
- Can consumers upgrade or leave without an unbounded coordinated change?
- Unknown, not verified
- Is platform work funded and prioritized by consumer outcomes?
- Unknown, not verified
Resolve the flagged prerequisites before committing to this decision
8 applicable prompts reviewed. 1 flagged prerequisite needs owner review before the affected use or commitment. These are self-reported observations, not proof of readiness, a maturity grade or a recommendation to buy a service. Even an all-positive review needs supporting evidence.
- Do multiple teams rely on a common capability? Demand is not established.
- Is there a team accountable for support and change? The operating model is incomplete.
- Do consumers need the same capability rather than similar implementations? Missing evidence prevents a conclusion. Compare actual workflows and constraints. Repeated code alone does not establish one shared product need.
- Is adoption easier than the consumers’ current alternative? Missing evidence prevents a conclusion. Include migration, learning, integration and support effort. Availability of a shared service does not prove useful adoption.
- Can consumers complete the intended task without an operator ticket? Missing evidence prevents a conclusion. Test the specific self-service path, permission boundary and error recovery. Not every privileged action should be self-service.
- Are platform reliability and capacity promises agreed with consumers? This prerequisite is unverified, not proven absent. Resolve its evidence before making the stated commitment. Missing evidence prevents a conclusion. Check workload limits, support coverage, incident handling and which team owns product-level recovery.
- Can consumers upgrade or leave without an unbounded coordinated change? Missing evidence prevents a conclusion. Review API compatibility, migration windows, export needs and deprecation ownership.
- Is platform work funded and prioritized by consumer outcomes? Missing evidence prevents a conclusion. Use a named sponsor, roadmap capacity and consumer feedback. Utilization or feature count alone is not platform value.
Checks for this example
- Interview teams about actual repeated work.
- Map on-call and change approvals.
- Compare two teams’ hardest workflows and identify the genuinely shared contract.
- Pilot a real onboarding and compare consumer work before and after, with exceptions recorded.
- Observe one consumer completing the task, including a rejected request and recoverable error.
- Agree the platform/product responsibility split and rehearse one dependency outage.
- Rehearse one consumer migration and record owner, dependencies and unsupported cases.
- Name the sponsor and resolve one competing consumer request using explicit decision criteria.