/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 verify the new solution is fully operational, e.g., functionality checks, performance tests, etc.
- Minimize the time it takes to confirm the new solution meets all requirements, e.g., technical specifications, user needs, etc.
- Minimize the time it takes to ensure the new solution integrates seamlessly with existing systems, e.g., software compatibility, hardware connections, etc.
- Minimize the likelihood of disruptions to operations during the transition, e.g., downtime, data loss, etc.
- Minimize the time it takes to train users on the new solution, e.g., tutorials, hands-on sessions, etc.
- Minimize the time it takes to validate the new solution's effectiveness against the old one, e.g., performance metrics, user feedback, etc.
- Minimize the likelihood of unforeseen costs associated with the new solution, e.g., maintenance fees, upgrade costs, etc.
- Minimize the time it takes to resolve any issues or bugs with the new solution, e.g., technical support, patches, etc.
- Minimize the time it takes to adapt workflows and processes to the new solution, e.g., process mapping, change management, etc.
- Minimize the likelihood of user resistance to the new solution, e.g., change aversion, learning curve, etc.
- Minimize the time it takes to achieve desired results with the new solution, e.g., efficiency gains, cost savings, etc.
- Minimize the likelihood of the new solution becoming obsolete quickly, e.g., future-proofing, scalability, etc.
- Minimize the time it takes to receive positive feedback from stakeholders about the new solution, e.g., customer satisfaction, employee engagement, etc.
- Minimize the likelihood of regulatory or compliance issues with the new solution, e.g., data privacy, industry standards, etc.
- Minimize the time it takes to realize the return on investment for the new solution, e.g., cost-benefit analysis, break-even point, etc.
- Minimize the likelihood of dependency on a single vendor for the new solution, e.g., vendor lock-in, contract terms, etc.
- Minimize the time it takes to optimize the new solution for peak performance, e.g., configuration settings, tuning, etc.
- Minimize the likelihood of security vulnerabilities in the new solution, e.g., data breaches, unauthorized access, etc.
- Minimize the time it takes to document the implementation process for future reference, e.g., project reports, lessons learned, etc.
- Minimize the likelihood of negative impact on customer experience during the transition, e.g., service interruptions, communication gaps, etc.
Customer Success Statements (PJTBD)
How important is it that you can quickly and accurately… and How difficult is it for you to…
- Verify the new solution is fully operational, e.g., functionality checks, performance tests, etc.
- Confirm the new solution meets all requirements, e.g., technical specifications, user needs, etc.
- Ensure the new solution integrates seamlessly with existing systems, e.g., software compatibility, hardware connections, etc.
- Avoid disruptions to operations during the transition, e.g., downtime, data loss, etc.
- Train users on the new solution, e.g., tutorials, hands-on sessions, etc.
- Validate the new solution's effectiveness against the old one, e.g., performance metrics, user feedback, etc.
- Avoid unforeseen costs associated with the new solution, e.g., maintenance fees, upgrade costs, etc.
- Resolve any issues or bugs with the new solution, e.g., technical support, patches, etc.
- Adapt workflows and processes to the new solution, e.g., process mapping, change management, etc.
- Avoid user resistance to the new solution, e.g., change aversion, learning curve, etc.
- Achieve desired results with the new solution, e.g., efficiency gains, cost savings, etc.
- Avoid the new solution becoming obsolete quickly, e.g., future-proofing, scalability, etc.
- Receive positive feedback from stakeholders about the new solution, e.g., customer satisfaction, employee engagement, etc.
- Avoid regulatory or compliance issues with the new solution, e.g., data privacy, industry standards, etc.
- Realize the return on investment for the new solution, e.g., cost-benefit analysis, break-even point, etc.
- Avoid dependency on a single vendor for the new solution, e.g., vendor lock-in, contract terms, etc.
- Optimize the new solution for peak performance, e.g., configuration settings, tuning, etc.
- Avoid security vulnerabilities in the new solution, e.g., data breaches, unauthorized access, etc.
- Document the implementation process for future reference, e.g., project reports, lessons learned, etc.
- Avoid negative impact on customer experience during the transition, e.g., service interruptions, communication gaps, 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]