/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 potential solutions, e.g., software, hardware, services, etc.
- Minimize the time it takes to evaluate the compatibility of potential solutions, e.g., interoperability, integration, etc.
- Minimize the time it takes to assess the reliability of potential solutions, e.g., uptime, performance, etc.
- Minimize the time it takes to understand the cost of potential solutions, e.g., licensing, implementation, maintenance, etc.
- Minimize the time it takes to determine the scalability of potential solutions, e.g., user capacity, data volume, etc.
- Minimize the time it takes to evaluate the security of potential solutions, e.g., data protection, access control, etc.
- Minimize the time it takes to assess the support and maintenance of potential solutions, e.g., vendor support, community support, etc.
- Minimize the time it takes to understand the implementation timeline of potential solutions, e.g., setup, configuration, testing, etc.
- Minimize the time it takes to evaluate the user-friendliness of potential solutions, e.g., user interface, user experience, etc.
- Minimize the likelihood of overlooking a potential solution, e.g., due to lack of visibility, lack of knowledge, etc.
- Minimize the time it takes to compare potential solutions, e.g., feature set, cost, support, etc.
- Minimize the time it takes to gather feedback on potential solutions, e.g., user reviews, expert opinions, etc.
- Minimize the time it takes to understand the future roadmap of potential solutions, e.g., planned features, updates, etc.
- Minimize the likelihood of choosing a solution that becomes obsolete, e.g., due to discontinuation, lack of updates, etc.
- Minimize the time it takes to identify potential risks associated with each solution, e.g., security risks, implementation risks, etc.
- Minimize the time it takes to understand the training requirements for each solution, e.g., user training, admin training, etc.
- Minimize the likelihood of choosing a solution that doesn't meet the project's requirements, e.g., functional requirements, technical requirements, etc.
- Minimize the time it takes to understand the customization possibilities of each solution, e.g., APIs, plugins, etc.
- Minimize the time it takes to evaluate the performance of each solution, e.g., speed, stability, etc.
- Minimize the likelihood of choosing a solution that doesn't integrate well with existing systems, e.g., due to incompatible technologies, lack of APIs, etc.
Customer Success Statements (PJTBD)
How important is it that you can quickly and accurately… and How difficult is it for you to…
- Identify potential solutions, e.g., software, hardware, services, etc.
- Evaluate the compatibility of potential solutions, e.g., interoperability, integration, etc.
- Assess the reliability of potential solutions, e.g., uptime, performance, etc.
- Understand the cost of potential solutions, e.g., licensing, implementation, maintenance, etc.
- Determine the scalability of potential solutions, e.g., user capacity, data volume, etc.
- Evaluate the security of potential solutions, e.g., data protection, access control, etc.
- Assess the support and maintenance of potential solutions, e.g., vendor support, community support, etc.
- Understand the implementation timeline of potential solutions, e.g., setup, configuration, testing, etc.
- Evaluate the user-friendliness of potential solutions, e.g., user interface, user experience, etc.
- Avoid overlooking a potential solution, e.g., due to lack of visibility, lack of knowledge, etc.
- Compare potential solutions, e.g., feature set, cost, support, etc.
- Gather feedback on potential solutions, e.g., user reviews, expert opinions, etc.
- Understand the future roadmap of potential solutions, e.g., planned features, updates, etc.
- Avoid choosing a solution that becomes obsolete, e.g., due to discontinuation, lack of updates, etc.
- Identify potential risks associated with each solution, e.g., security risks, implementation risks, etc.
- Understand the training requirements for each solution, e.g., user training, admin training, etc.
- Avoid choosing a solution that doesn't meet the project's requirements, e.g., functional requirements, technical requirements, etc.
- Understand the customization possibilities of each solution, e.g., APIs, plugins, etc.
- Evaluate the performance of each solution, e.g., speed, stability, etc.
- Avoid choosing a solution that doesn't integrate well with existing systems, e.g., due to incompatible technologies, lack of APIs, 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]