From 06600da5448386a4989eb7734e0659c73a3341c9 Mon Sep 17 00:00:00 2001 From: Allen Houchins <32207388+allenhouchins@users.noreply.github.com> Date: Fri, 16 Jan 2026 10:51:09 -0600 Subject: [PATCH] Update product-maturity-assessment.md (#38436) --- .../company/product-maturity-assessment.md | 54 ++++++++++++++++--- 1 file changed, 47 insertions(+), 7 deletions(-) diff --git a/handbook/company/product-maturity-assessment.md b/handbook/company/product-maturity-assessment.md index 7859095c9b..10660b64b7 100644 --- a/handbook/company/product-maturity-assessment.md +++ b/handbook/company/product-maturity-assessment.md @@ -162,17 +162,17 @@ Fleet provides comprehensive device management across the entire computing lifec | Platform | Current | Q1 2026 | Q2 2026 | Q3 2026 | Q4 2026 | | :---- | :---- | :---- | :---- | :---- | :---- | -| macOS | ðŸĨ | ðŸĨ | ðŸĨ | ðŸĨ | ðŸĨ | +| macOS | ðŸĨ | ðŸĨ | ðŸĶ† | ðŸĶ† | ðŸĶ† | | Windows | ðŸĨ | ðŸĨ | ðŸĨ | ðŸĨ | ðŸĨ | -| Linux (Ubuntu) | ðŸĶ† | ðŸĶ† | ðŸĶ† | ðŸĶ† | ðŸĶ† | -| Linux (RHEL) | ðŸĶ† | ðŸĶ† | ðŸĶ† | ðŸĶ† | ðŸĶ† | +| Linux (Ubuntu) | ðŸĨ | ðŸĨ | ðŸĨ | ðŸĨ | ðŸĨ | +| Linux (RHEL) | ðŸĨ | ðŸĨ | ðŸĨ | ðŸĨ | ðŸĨ | | Linux (Debian) | ðŸĨ | ðŸĨ | ðŸĨ | ðŸĨ | ðŸĨ | | Linux (Arch) | ðŸĨ | ðŸĨ | ðŸĨ | ðŸĨ | ðŸĨ | | Linux (SUSE) | ðŸĨ | ðŸĨ | ðŸĨ | ðŸĨ | ðŸĨ | -| Android | ðŸĢ | ðŸĢ | ðŸĢ | ðŸĢ | ðŸĢ | -| tvOS/visionOS/watchOS | ðŸĨš | ðŸĨš | ðŸĨš | ðŸĨš | ðŸĨš | -| iOS/iPadOS | ðŸĨ | ðŸĨ | ðŸĨ | ðŸĨ | ðŸĨ | -| ChromeOS | ðŸĶ† | ðŸĶ† | ðŸĶ† | ðŸĶ† | ðŸĶ† | +| Android | ðŸĢ | ðŸĨ | ðŸĨ | ðŸĨ | ðŸĨ | +| tvOS/visionOS/watchOS | ðŸĨš | ðŸĨš | ðŸĨš | ðŸĢ | ðŸĨ | +| iOS/iPadOS | ðŸĨ | ðŸĨ | ðŸĶ† | ðŸĶ† | ðŸĶ† | +| ChromeOS | ðŸĨ | ðŸĨ | ðŸĨ | ðŸĨ | ðŸĨ | --- @@ -250,6 +250,46 @@ Choose the best description for the stage overall based on the mix of category m Replace placeholders with the current assessment. Look at the overall mix of category maturities in the stage to determine the appropriate lifecycle stage. +### Platform support maturity (per platform) + +Platform support maturity is determined by aggregating all platform-specific categories across all lifecycle stages (Enroll, Configure, Monitor, Maintain, Offboard). Use the following algorithm: + +1. **Identify all platform-specific categories**: Collect all categories from Enroll, Configure, Monitor, Maintain, and Offboard that apply to the platform (e.g., "macOS", "Windows", "Apple", "iOS/iPadOS", "Android", "Linux", "ChromeOS", or specific platform mentions). + +2. **Count maturity distribution**: Calculate the percentage of categories at each maturity level (ðŸĨš ðŸĢ ðŸĨ ðŸĶ† ðŸĶĒ). + +3. **Apply maturity criteria**: + - ðŸĨš **Planned**: Platform is actively being researched with a few Planned categories identified, but no Minimal or higher categories exist yet + - ðŸĢ **Minimal**: 50%+ of categories are Planned/Minimal, with at least one Minimal category in a critical area (enrollment or basic configuration) + - ðŸĨ **Viable**: 50%+ of categories are at least Viable, AND enrollment is at least Viable, AND at least 2 out of 3 critical categories (enrollment, basic configuration, monitoring) are at least Viable, AND at least one category from Configure/Maintain/Monitor is at least Viable + - ðŸĶ† **Complete**: 75%+ of categories are Complete, AND enrollment is at least Viable, AND all critical categories (enrollment, basic configuration, monitoring) are at least Viable + - ðŸĶĒ **Lovable**: 50%+ of categories are Complete/Lovable, AND key areas (enrollment, monitoring, or configuration) include at least one Lovable category + +4. **Critical categories** (must be considered): + - Enrollment (foundational - must be at least Viable for platform to be Viable+) + - Basic configuration (profiles or equivalent) + - Monitoring (device status or inventory) + +5. **Edge cases**: + - If a platform has very few categories (< 5), use qualitative judgment based on coverage of critical capabilities + - For platform variants (e.g., Linux distributions), consider both shared capabilities and platform-specific features + +**Example calculation for macOS**: +- Categories: DEP/ABM enrollment (ðŸĶ†), Account Driven User Enrollment (ðŸĢ), Setup experience (ðŸĨ), Configuration profiles (ðŸĨ), Disk encryption (ðŸĶ†), OS update management (ðŸĨ), Remote lock/wipe (ðŸĶ†) +- Distribution: 43% Complete, 43% Viable, 14% Minimal +- Enrollment: DEP/ABM enrollment (ðŸĶ†) ✓ +- Critical categories: Enrollment (ðŸĶ†) ✓, Basic configuration (ðŸĨ) ✓, Monitoring (ðŸĶ† via cross-platform) ✓ = 3/3 ✓ +- At least one Configure/Maintain/Monitor category Viable+: Multiple (Disk encryption, Remote lock/wipe, etc.) ✓ +- Result: ðŸĨ Viable (43% Complete, not 75%+ Complete, but all critical categories met) + +**Example calculation for Linux (Ubuntu)**: +- Categories: Linux enrollment (ðŸĨ), Setup experience (Linux) (ðŸĢ), Disk encryption management (Linux) (ðŸĶ†), OS update management (Linux) (ðŸĨš), Remote lock/wipe (Linux) (ðŸĶ†) +- Distribution: 40% Complete, 20% Viable, 20% Minimal, 20% Planned +- Enrollment: Viable (ðŸĨ) ✓ +- Critical categories: Enrollment (ðŸĨ) ✓, Basic configuration (ðŸĢ) ✗, Monitoring (ðŸĶ† via cross-platform) ✓ = 2 out of 3 ✓ +- At least one Configure/Maintain/Monitor category Viable+: Disk encryption (ðŸĶ†) and Remote lock/wipe (ðŸĶ†) ✓ +- Result: ðŸĨ Viable (60% at least Viable, enrollment Viable, 2/3 critical categories Viable+) + ### What to include in each stage section 1. Stage lifecycle: Replace the placeholder with the current stage-level assessment