/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 need for a solution replacement, e.g., performance issues, outdated technology, etc.
- Minimize the time it takes to evaluate the current solution's limitations, e.g., lack of features, poor user experience, etc.
- Minimize the time it takes to determine the impact of the current solution's limitations on business operations, e.g., productivity loss, increased costs, etc.
- Minimize the likelihood of overlooking critical issues with the current solution, e.g., security vulnerabilities, compliance risks, etc.
- Minimize the time it takes to gather feedback from users about the current solution, e.g., surveys, interviews, etc.
- Minimize the time it takes to analyze user feedback for common complaints and issues, e.g., data analysis, trend identification, etc.
- Minimize the likelihood of misinterpreting user feedback, e.g., bias, lack of context, etc.
- Minimize the time it takes to compare the current solution's performance against industry standards or benchmarks, e.g., speed, reliability, etc.
- Minimize the likelihood of ignoring emerging trends or technologies that could render the current solution obsolete, e.g., AI, blockchain, etc.
- Minimize the time it takes to assess the financial implications of replacing the current solution, e.g., cost of new solution, ROI, etc.
- Minimize the likelihood of underestimating the costs associated with replacing the current solution, e.g., training, downtime, etc.
- Minimize the time it takes to identify potential replacement solutions, e.g., market research, vendor evaluations, etc.
- Minimize the likelihood of overlooking a better replacement solution, e.g., due to lack of research, bias, etc.
- Minimize the time it takes to evaluate the compatibility of potential replacements with existing systems and processes, e.g., integration, workflow, etc.
- Minimize the likelihood of choosing a replacement solution that doesn't meet business needs, e.g., lack of features, poor fit, etc.
- Minimize the time it takes to get buy-in from stakeholders for the replacement, e.g., presentations, business case, etc.
- Minimize the likelihood of facing resistance from stakeholders during the replacement process, e.g., change aversion, lack of understanding, etc.
- Minimize the time it takes to plan the transition to the new solution, e.g., timeline, resources, etc.
- Minimize the likelihood of disruptions during the transition to the new solution, e.g., downtime, data loss, etc.
- Minimize the time it takes to train users on the new solution, e.g., tutorials, workshops, 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 need for a solution replacement, e.g., performance issues, outdated technology, etc.
- Evaluate the current solution's limitations, e.g., lack of features, poor user experience, etc.
- Determine the impact of the current solution's limitations on business operations, e.g., productivity loss, increased costs, etc.
- Avoid overlooking critical issues with the current solution, e.g., security vulnerabilities, compliance risks, etc.
- Gather feedback from users about the current solution, e.g., surveys, interviews, etc.
- Analyze user feedback for common complaints and issues, e.g., data analysis, trend identification, etc.
- Avoid misinterpreting user feedback, e.g., bias, lack of context, etc.
- Compare the current solution's performance against industry standards or benchmarks, e.g., speed, reliability, etc.
- Avoid ignoring emerging trends or technologies that could render the current solution obsolete, e.g., AI, blockchain, etc.
- Assess the financial implications of replacing the current solution, e.g., cost of new solution, ROI, etc.
- Avoid underestimating the costs associated with replacing the current solution, e.g., training, downtime, etc.
- Identify potential replacement solutions, e.g., market research, vendor evaluations, etc.
- Avoid overlooking a better replacement solution, e.g., due to lack of research, bias, etc.
- Evaluate the compatibility of potential replacements with existing systems and processes, e.g., integration, workflow, etc.
- Avoid choosing a replacement solution that doesn't meet business needs, e.g., lack of features, poor fit, etc.
- Get buy-in from stakeholders for the replacement, e.g., presentations, business case, etc.
- Avoid facing resistance from stakeholders during the replacement process, e.g., change aversion, lack of understanding, etc.
- Plan the transition to the new solution, e.g., timeline, resources, etc.
- Avoid disruptions during the transition to the new solution, e.g., downtime, data loss, etc.
- Train users on the new solution, e.g., tutorials, workshops, 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]