Skip to content

[FR] Use adoption to prioritize the working group's efforts #1544

@shawnalpay

Description

@shawnalpay

Problem Statement

As part of the 1.3 scope definition process, we switched from tracking support on open issues from person to organization. However, a key theme emerged from our in-person FOCUS meeting in Washington, DC on Oct 22, 2025 when discussing 1.4 draft scope: which of these features would best foster adoption of the specification? We do not currently delineate between support from existing practitioners and new practitioners. And we also do not denote whether a given person's support would help them start actually using the spec.

Expected Questions that need answers as a part of this effort

Adoption Blockers vs. Enhancements:

  • Which features are blocking organizations from adopting FOCUS at all?
  • Which features would improve existing adopters' experience but aren't blockers?
  • How do we distinguish "would be nice" from "can't use FOCUS without this"?

Organization Classification:

  • How do we differentiate support from current adopters vs. potential adopters?
  • Should we weight support differently based on adoption stage?
  • How do we capture "this feature would enable us to start using FOCUS"?

Provider vs. Practitioner Signals:

  • How do we balance practitioner demand with provider feasibility?

Measurement & Tracking:

  • What metadata should we collect on feature requests to assess adoption impact?
  • How do we track whether delivered features actually unlocked adoption?
  • Can we establish feedback loops to validate prioritization effectiveness?

Desired Outcome / Practitioner Impact

Have the ability to prioritize the efforts of the working group based on how it might unlock practitioner adoption of FOCUS data.

Type of Request

Supporting Content (e.g., appendices, use cases)

Organizations Requesting or Supporting This Feature

No response

FinOps Scope Alignment (Optional)

  • Public Cloud – e.g., AWS, Azure, GCP, OCI
  • Software-as-a-Service (SaaS) – e.g., Salesforce, Snowflake
  • Data Center – on-prem compute and infrastructure
  • Licensing – subscription or usage-based licensing (under development)
  • AI – cost and usage for AI models and platforms (under development)
  • Custom – internal tooling, specialized infra (under development)

Impacted Parties

  • FinOps Practitioner – end users who analyze or act on the data
  • FOCUS Data Generator – providers generating aligned output
  • Vendor Supporting FOCUS – tools or platforms using the spec
  • Other (please explain in comments)

Level of Ambiguity (1–5)

3: need to better define what would unlock adoption

Supporting Documentation

No response

Proposed Solution / Approach

Investigation Approach

Data Collection:

  • Survey organizations supporting features to classify adoption status (current user, blocked potential user, future enhancer)
  • Identify which features have provider implementation commitments
  • Review 1.3 retrospective on whether prioritized features drove expected adoption

Analysis:

  • Map features to adoption stages (onboarding blockers vs. maturity enhancers)
  • Identify clusters of related features that together unlock adoption
  • Assess effort-to-impact ratio for adoption-critical features

Framework Development:

  • Define adoption impact scoring rubric
  • Establish weighting criteria (blocker > enabler > enhancement)
  • Create decision tree for prioritization

Expected Deliverables

Adoption Impact Classification Schema:

  • Clear definitions for feature categories (Adoption Blocker, Adoption Enabler, Maturity Enhancement)
  • Metadata fields to add to feature requests
  • Scoring rubric for prioritization

Updated Feature Request Template:

  • Add field: "Does this feature block your organization from adopting FOCUS? (Yes/No/Already Adopted)"
  • Add field: "If implemented, would your organization commit to using FOCUS data within 6 months?"
  • Add field: "Provider implementation commitment" (for data generators)

Prioritization Framework Documentation:

  • Decision criteria for scope inclusion
  • Weighting methodology
  • Process for re-evaluating priorities based on adoption feedback

1.5 Scope Implications:

  • Recommended changes to current 1.5 draft scope based on adoption signals
  • Features that should be elevated/demoted in priority

Sub-issues

Metadata

Metadata

Assignees

Labels

featureneeds triageNeeds initial review or agreed action item by project teamneeds use caseNeeds a description of the why (use case or other problem to solve)spikeA time-boxed effort to better define

Projects

Status

In Discovery

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions