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)
- Minimize the time it takes to evaluate the compatibility of the new solution with existing systems, e.g., software, hardware, etc.
- Minimize the time it takes to assess the reliability of the new solution, e.g., uptime, failure rates, etc.
- Minimize the time it takes to understand the cost-effectiveness of the new solution, e.g., total cost of ownership, return on investment, etc.
- Minimize the time it takes to determine the scalability of the new solution, e.g., capacity, growth potential, etc.
- Minimize the time it takes to evaluate the ease of use of the new solution, e.g., user interface, learning curve, etc.
- Minimize the time it takes to assess the support and maintenance requirements of the new solution, e.g., vendor support, self-service options, etc.
- Minimize the time it takes to understand the security features of the new solution, e.g., encryption, user access controls, etc.
- Minimize the time it takes to evaluate the integration capabilities of the new solution, e.g., APIs, data import/export, etc.
- Minimize the time it takes to assess the performance of the new solution, e.g., speed, efficiency, etc.
- Minimize the time it takes to understand the customization options of the new solution, e.g., user roles, workflows, etc.
- Minimize the likelihood of selecting a solution that fails to meet business needs, e.g., functionality gaps, poor fit with business processes, etc.
- Minimize the likelihood of choosing a solution that is difficult to implement, e.g., complex setup, lack of documentation, etc.
- Minimize the likelihood of selecting a solution that is not future-proof, e.g., outdated technology, lack of updates, etc.
- Minimize the likelihood of choosing a solution that lacks vendor support, e.g., unresponsive customer service, lack of training resources, etc.
- Minimize the likelihood of selecting a solution that is not compliant with industry standards, e.g., GDPR, HIPAA, etc.
- Minimize the likelihood of choosing a solution that lacks necessary security features, e.g., weak encryption, lack of two-factor authentication, etc.
- Minimize the likelihood of selecting a solution that is not user-friendly, e.g., complex interface, steep learning curve, etc.
- Minimize the likelihood of choosing a solution that does not integrate well with existing systems, e.g., incompatible APIs, lack of data import/export options, etc.
- Minimize the likelihood of selecting a solution that is not cost-effective, e.g., high total cost of ownership, low return on investment, etc.
- Minimize the likelihood of choosing a solution that is not reliable, e.g., frequent downtime, high failure rates, etc.
Customer Success Statements (PJTBD)
- Evaluate the compatibility of the new solution with existing systems, e.g., software, hardware, etc.
- Assess the reliability of the new solution, e.g., uptime, failure rates, etc.
- Understand the cost-effectiveness of the new solution, e.g., total cost of ownership, return on investment, etc.
- Determine the scalability of the new solution, e.g., capacity, growth potential, etc.
- Evaluate the ease of use of the new solution, e.g., user interface, learning curve, etc.
- Assess the support and maintenance requirements of the new solution, e.g., vendor support, self-service options, etc.
- Understand the security features of the new solution, e.g., encryption, user access controls, etc.
- Evaluate the integration capabilities of the new solution, e.g., APIs, data import/export, etc.
- Assess the performance of the new solution, e.g., speed, efficiency, etc.
- Understand the customization options of the new solution, e.g., user roles, workflows, etc.
- Avoid selecting a solution that fails to meet business needs, e.g., functionality gaps, poor fit with business processes, etc.
- Avoid choosing a solution that is difficult to implement, e.g., complex setup, lack of documentation, etc.
- Avoid selecting a solution that is not future-proof, e.g., outdated technology, lack of updates, etc.
- Avoid choosing a solution that lacks vendor support, e.g., unresponsive customer service, lack of training resources, etc.
- Avoid selecting a solution that is not compliant with industry standards, e.g., GDPR, HIPAA, etc.
- Avoid choosing a solution that lacks necessary security features, e.g., weak encryption, lack of two-factor authentication, etc.
- Avoid selecting a solution that is not user-friendly, e.g., complex interface, steep learning curve, etc.
- Avoid choosing a solution that does not integrate well with existing systems, e.g., incompatible APIs, lack of data import/export options, etc.
- Avoid selecting a solution that is not cost-effective, e.g., high total cost of ownership, low return on investment, etc.
- Avoid choosing a solution that is not reliable, e.g., frequent downtime, high failure rates, 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]