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 necessary adjustments to the new solution, e.g., configuration changes, feature settings, etc.
- Minimize the time it takes to implement the identified adjustments, e.g., software updates, hardware modifications, etc.
- Minimize the likelihood of overlooking critical adjustments, e.g., security settings, compatibility issues, etc.
- Minimize the time it takes to verify the effectiveness of the adjustments, e.g., performance tests, user feedback, etc.
- Minimize the likelihood of disrupting existing workflows due to adjustments, e.g., process changes, role changes, etc.
- Minimize the time it takes to communicate the adjustments to relevant stakeholders, e.g., team members, clients, etc.
- Minimize the likelihood of causing confusion or misunderstanding due to poor communication of adjustments, e.g., unclear instructions, lack of training, etc.
- Minimize the time it takes to train end users on the adjusted solution, e.g., tutorials, workshops, etc.
- Minimize the likelihood of end users struggling to adapt to the adjusted solution, e.g., usability issues, steep learning curve, etc.
- Minimize the time it takes to monitor the performance of the adjusted solution, e.g., analytics, user feedback, etc.
- Minimize the likelihood of the adjusted solution failing to meet the intended objectives, e.g., efficiency gains, cost savings, etc.
- Minimize the time it takes to make further adjustments based on performance feedback, e.g., bug fixes, feature enhancements, etc.
- Minimize the likelihood of causing disruption or downtime due to further adjustments, e.g., system outages, workflow interruptions, etc.
- Minimize the time it takes to document the adjustments and their impacts, e.g., change logs, impact assessments, etc.
- Minimize the likelihood of losing track of the adjustments made and their effects, e.g., poor record keeping, lack of transparency, etc.
- Minimize the time it takes to assess the overall success of the solution replacement, e.g., performance metrics, user satisfaction, etc.
- Minimize the likelihood of the solution replacement failing to deliver the expected benefits, e.g., productivity gains, cost reductions, etc.
- Minimize the time it takes to plan for future adjustments or replacements, e.g., roadmap updates, budget planning, etc.
- Minimize the likelihood of being unprepared for future solution adjustments or replacements, e.g., lack of foresight, inadequate resources, etc.
- Minimize the time it takes to celebrate the successful solution replacement and acknowledge the team's efforts, e.g., team meetings, recognition awards, etc.
Customer Success Statements (PJTBD)
- Identify necessary adjustments to the new solution, e.g., configuration changes, feature settings, etc.
- Implement the identified adjustments, e.g., software updates, hardware modifications, etc.
- Avoid overlooking critical adjustments, e.g., security settings, compatibility issues, etc.
- Verify the effectiveness of the adjustments, e.g., performance tests, user feedback, etc.
- Avoid disrupting existing workflows due to adjustments, e.g., process changes, role changes, etc.
- Communicate the adjustments to relevant stakeholders, e.g., team members, clients, etc.
- Avoid causing confusion or misunderstanding due to poor communication of adjustments, e.g., unclear instructions, lack of training, etc.
- Train end users on the adjusted solution, e.g., tutorials, workshops, etc.
- Avoid end users struggling to adapt to the adjusted solution, e.g., usability issues, steep learning curve, etc.
- Monitor the performance of the adjusted solution, e.g., analytics, user feedback, etc.
- Avoid the adjusted solution failing to meet the intended objectives, e.g., efficiency gains, cost savings, etc.
- Make further adjustments based on performance feedback, e.g., bug fixes, feature enhancements, etc.
- Avoid causing disruption or downtime due to further adjustments, e.g., system outages, workflow interruptions, etc.
- Document the adjustments and their impacts, e.g., change logs, impact assessments, etc.
- Avoid losing track of the adjustments made and their effects, e.g., poor record keeping, lack of transparency, etc.
- Assess the overall success of the solution replacement, e.g., performance metrics, user satisfaction, etc.
- Avoid the solution replacement failing to deliver the expected benefits, e.g., productivity gains, cost reductions, etc.
- Plan for future adjustments or replacements, e.g., roadmap updates, budget planning, etc.
- Avoid being unprepared for future solution adjustments or replacements, e.g., lack of foresight, inadequate resources, etc.
- Celebrate the successful solution replacement and acknowledge the team's efforts, e.g., team meetings, recognition awards, 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]