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 identify the most suitable solutions, e.g., based on system requirements, compatibility, etc.
- Minimize the time it takes to evaluate the performance of potential solutions, e.g., speed, reliability, etc.
- Minimize the time it takes to assess the scalability of potential solutions, e.g., capacity for growth, adaptability, etc.
- Minimize the time it takes to determine the cost-effectiveness of potential solutions, e.g., initial cost, maintenance cost, etc.
- Minimize the time it takes to understand the integration capabilities of potential solutions, e.g., interoperability, compatibility, etc.
- Minimize the time it takes to verify the security features of potential solutions, e.g., data protection, encryption, etc.
- Minimize the time it takes to confirm the support and maintenance options for potential solutions, e.g., vendor support, community support, etc.
- Minimize the likelihood of selecting solutions that fail to meet system requirements, e.g., functionality, performance, etc.
- Minimize the likelihood of choosing solutions that are not scalable, e.g., limited capacity for growth, lack of adaptability, etc.
- Minimize the likelihood of opting for solutions that are not cost-effective, e.g., high initial cost, expensive maintenance, etc.
- Minimize the likelihood of picking solutions with inadequate integration capabilities, e.g., lack of interoperability, compatibility issues, etc.
- Minimize the likelihood of selecting solutions with insufficient security features, e.g., weak data protection, lack of encryption, etc.
- Minimize the likelihood of choosing solutions with limited support and maintenance options, e.g., poor vendor support, lack of community support, etc.
- Minimize the time it takes to compare the pros and cons of potential solutions, e.g., feature comparison, cost comparison, etc.
- Minimize the time it takes to gather feedback on potential solutions from relevant stakeholders, e.g., users, management, etc.
- Minimize the time it takes to finalize the selection of optimal solutions, e.g., decision-making, approval, etc.
- Minimize the likelihood of overlooking key considerations in the selection process, e.g., overlooked requirements, missed feedback, etc.
- Minimize the likelihood of experiencing delays in the selection process, e.g., slow decision-making, delayed approval, etc.
- Minimize the likelihood of encountering resistance from stakeholders during the selection process, e.g., disagreement, lack of buy-in, etc.
- Minimize the likelihood of having to revisit the selection process due to errors or oversights, e.g., incorrect assessment, missed requirements, etc.
Customer Success Statements (PJTBD)
- Identify the most suitable solutions, e.g., based on system requirements, compatibility, etc.
- Evaluate the performance of potential solutions, e.g., speed, reliability, etc.
- Assess the scalability of potential solutions, e.g., capacity for growth, adaptability, etc.
- Determine the cost-effectiveness of potential solutions, e.g., initial cost, maintenance cost, etc.
- Understand the integration capabilities of potential solutions, e.g., interoperability, compatibility, etc.
- Verify the security features of potential solutions, e.g., data protection, encryption, etc.
- Confirm the support and maintenance options for potential solutions, e.g., vendor support, community support, etc.
- Avoid selecting solutions that fail to meet system requirements, e.g., functionality, performance, etc.
- Avoid choosing solutions that are not scalable, e.g., limited capacity for growth, lack of adaptability, etc.
- Avoid opting for solutions that are not cost-effective, e.g., high initial cost, expensive maintenance, etc.
- Avoid picking solutions with inadequate integration capabilities, e.g., lack of interoperability, compatibility issues, etc.
- Avoid selecting solutions with insufficient security features, e.g., weak data protection, lack of encryption, etc.
- Avoid choosing solutions with limited support and maintenance options, e.g., poor vendor support, lack of community support, etc.
- Compare the pros and cons of potential solutions, e.g., feature comparison, cost comparison, etc.
- Gather feedback on potential solutions from relevant stakeholders, e.g., users, management, etc.
- Finalize the selection of optimal solutions, e.g., decision-making, approval, etc.
- Avoid overlooking key considerations in the selection process, e.g., overlooked requirements, missed feedback, etc.
- Avoid experiencing delays in the selection process, e.g., slow decision-making, delayed approval, etc.
- Avoid encountering resistance from stakeholders during the selection process, e.g., disagreement, lack of buy-in, etc.
- Avoid having to revisit the selection process due to errors or oversights, e.g., incorrect assessment, missed requirements, 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]