/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 necessary modifications in the solution configuration, e.g., software settings, hardware adjustments, etc.
- Minimize the time it takes to understand the impact of modifications on the overall system, e.g., performance, compatibility, etc.
- Minimize the likelihood of overlooking critical configuration changes, e.g., security settings, network parameters, etc.
- Minimize the time it takes to verify the effectiveness of the modifications, e.g., system tests, user feedback, etc.
- Minimize the likelihood of causing disruptions to other integrated solutions, e.g., data flow, system stability, etc.
- Minimize the time it takes to document the modifications for future reference, e.g., change logs, system diagrams, etc.
- Minimize the likelihood of incurring additional costs due to improper modifications, e.g., system downtime, rework, etc.
- Minimize the time it takes to communicate the modifications to relevant stakeholders, e.g., team members, clients, etc.
- Minimize the likelihood of non-compliance with industry standards due to modifications, e.g., data privacy, security protocols, etc.
- Minimize the time it takes to train end users on the modified solution, e.g., new features, changed workflows, etc.
- Minimize the likelihood of creating system vulnerabilities due to modifications, e.g., security loopholes, data leaks, etc.
- Minimize the time it takes to monitor the modified solution for potential issues, e.g., system logs, user feedback, etc.
- Minimize the likelihood of degrading system performance due to modifications, e.g., speed, reliability, etc.
- Minimize the time it takes to rollback modifications if necessary, e.g., system restore, backup recovery, etc.
- Minimize the likelihood of conflicts between modified and existing configurations, e.g., software compatibility, hardware requirements, etc.
- Minimize the time it takes to validate the modified solution against user requirements, e.g., functionality, usability, etc.
- Minimize the likelihood of introducing new bugs or errors due to modifications, e.g., software glitches, hardware malfunctions, etc.
- Minimize the time it takes to optimize the modified solution for maximum efficiency, e.g., resource usage, process workflows, etc.
- Minimize the likelihood of disrupting user experience due to modifications, e.g., interface changes, feature removals, etc.
- Minimize the time it takes to incorporate user feedback into the modified solution, e.g., feature requests, bug reports, 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 necessary modifications in the solution configuration, e.g., software settings, hardware adjustments, etc.
- Understand the impact of modifications on the overall system, e.g., performance, compatibility, etc.
- Avoid overlooking critical configuration changes, e.g., security settings, network parameters, etc.
- Verify the effectiveness of the modifications, e.g., system tests, user feedback, etc.
- Avoid causing disruptions to other integrated solutions, e.g., data flow, system stability, etc.
- Document the modifications for future reference, e.g., change logs, system diagrams, etc.
- Avoid incurring additional costs due to improper modifications, e.g., system downtime, rework, etc.
- Communicate the modifications to relevant stakeholders, e.g., team members, clients, etc.
- Avoid non-compliance with industry standards due to modifications, e.g., data privacy, security protocols, etc.
- Train end users on the modified solution, e.g., new features, changed workflows, etc.
- Avoid creating system vulnerabilities due to modifications, e.g., security loopholes, data leaks, etc.
- Monitor the modified solution for potential issues, e.g., system logs, user feedback, etc.
- Avoid degrading system performance due to modifications, e.g., speed, reliability, etc.
- Rollback modifications if necessary, e.g., system restore, backup recovery, etc.
- Avoid conflicts between modified and existing configurations, e.g., software compatibility, hardware requirements, etc.
- Validate the modified solution against user requirements, e.g., functionality, usability, etc.
- Avoid introducing new bugs or errors due to modifications, e.g., software glitches, hardware malfunctions, etc.
- Optimize the modified solution for maximum efficiency, e.g., resource usage, process workflows, etc.
- Avoid disrupting user experience due to modifications, e.g., interface changes, feature removals, etc.
- Incorporate user feedback into the modified solution, e.g., feature requests, bug reports, 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]