/w=256,quality=90,fit=scale-down)
Success Metrics
There are two formatting options available. The traditional desired outcome statement is a structure used in the Outcome-Driven Innovation methodology. Since many stakeholders - especially when involved with marketing or UX teams - push back on the awkward nature of desired outcomes statements since people don’t talk like that, the alternative is a natural language structure that gets to the heart of the outcome and tries to avoid tasks and activities where feasible.
This catalog contains 20 potential metrics using each formatting option. You will likely need to reduce this set for a survey. The number of statements that have been generated is arbitrary and can be expanded to accommodate your needs.
Desired Outcome Statements (ODI)
How important is it that you… and How satisfied are you with your ability to…
- Minimize the time it takes to identify the system requirements, e.g., hardware specifications, software compatibility, etc.
- Minimize the time it takes to understand the functional needs of the system, e.g., processing speed, storage capacity, etc.
- Minimize the time it takes to determine the non-functional requirements of the system, e.g., security protocols, system reliability, etc.
- Minimize the time it takes to evaluate the compatibility of different solutions, e.g., software integration, hardware compatibility, etc.
- Minimize the time it takes to assess the scalability of the system, e.g., ability to handle increased workload, expandability, etc.
- Minimize the time it takes to identify potential system constraints, e.g., budget limitations, time constraints, etc.
- Minimize the time it takes to understand the system's operational environment, e.g., physical conditions, network infrastructure, etc.
- Minimize the time it takes to determine the system's maintenance requirements, e.g., regular updates, system checks, etc.
- Minimize the time it takes to identify the system's performance metrics, e.g., response time, throughput, etc.
- Minimize the likelihood of overlooking critical system requirements, e.g., regulatory compliance, data privacy, etc.
- Minimize the time it takes to understand the system's user requirements, e.g., user interface, accessibility, etc.
- Minimize the time it takes to identify the system's disaster recovery requirements, e.g., backup procedures, failover mechanisms, etc.
- Minimize the time it takes to determine the system's interoperability requirements, e.g., data exchange, communication protocols, etc.
- Minimize the time it takes to understand the system's security requirements, e.g., encryption, user authentication, etc.
- Minimize the likelihood of misinterpreting system requirements, e.g., ambiguous specifications, conflicting requirements, etc.
- Minimize the time it takes to identify the system's quality attributes, e.g., reliability, maintainability, etc.
- Minimize the time it takes to understand the system's data requirements, e.g., data formats, data volume, etc.
- Minimize the time it takes to determine the system's power requirements, e.g., power consumption, power backup, etc.
- Minimize the likelihood of underestimating system requirements, e.g., underestimating storage needs, processing power, etc.
- Minimize the time it takes to identify the system's future requirements, e.g., future expansion, technology upgrades, etc.
Customer Success Statements (PJTBD)
How important is it that you can quickly and accurately… and How difficult is it for you to…
- Identify the system requirements, e.g., hardware specifications, software compatibility, etc.
- Understand the functional needs of the system, e.g., processing speed, storage capacity, etc.
- Determine the non-functional requirements of the system, e.g., security protocols, system reliability, etc.
- Evaluate the compatibility of different solutions, e.g., software integration, hardware compatibility, etc.
- Assess the scalability of the system, e.g., ability to handle increased workload, expandability, etc.
- Identify potential system constraints, e.g., budget limitations, time constraints, etc.
- Understand the system's operational environment, e.g., physical conditions, network infrastructure, etc.
- Determine the system's maintenance requirements, e.g., regular updates, system checks, etc.
- Identify the system's performance metrics, e.g., response time, throughput, etc.
- Avoid overlooking critical system requirements, e.g., regulatory compliance, data privacy, etc.
- Understand the system's user requirements, e.g., user interface, accessibility, etc.
- Identify the system's disaster recovery requirements, e.g., backup procedures, failover mechanisms, etc.
- Determine the system's interoperability requirements, e.g., data exchange, communication protocols, etc.
- Understand the system's security requirements, e.g., encryption, user authentication, etc.
- Avoid misinterpreting system requirements, e.g., ambiguous specifications, conflicting requirements, etc.
- Identify the system's quality attributes, e.g., reliability, maintainability, etc.
- Understand the system's data requirements, e.g., data formats, data volume, etc.
- Determine the system's power requirements, e.g., power consumption, power backup, etc.
- Avoid underestimating system requirements, e.g., underestimating storage needs, processing power, etc.
- Identify the system's future requirements, e.g., future expansion, technology upgrades, etc.
Test Fit Structure
Apply this to Customer Success Statements only. Everything should fit together nicely. Here’s an article where I introduced the concept. Feel free to devise your own version for Desired Outcome Statements as this does not apply to their format directly.
As a(n) [end user] + who is + [Job] you're trying to [success statement] + "faster and more accurately" so that you can successfully [Job Step]