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 and understand feedback, e.g., customer reviews, product ratings, etc.
- Minimize the time it takes to analyze the impact of feedback on product performance, e.g., sales data, return rates, etc.
- Minimize the time it takes to determine necessary adjustments based on feedback, e.g., design changes, feature enhancements, etc.
- Minimize the likelihood of ignoring valuable feedback, e.g., constructive criticism, innovative suggestions, etc.
- Minimize the time it takes to implement changes based on feedback, e.g., product updates, new releases, etc.
- Minimize the likelihood of misinterpreting feedback, e.g., cultural nuances, language barriers, etc.
- Minimize the time it takes to communicate changes to stakeholders, e.g., team members, customers, etc.
- Minimize the likelihood of overlooking feedback from minority groups, e.g., underrepresented demographics, niche markets, etc.
- Minimize the time it takes to measure the effectiveness of implemented changes, e.g., customer satisfaction surveys, sales data, etc.
- Minimize the likelihood of implementing changes that do not align with the company's vision or mission, e.g., unsustainable practices, unethical behavior, etc.
- Minimize the time it takes to plan and schedule product updates, e.g., software patches, hardware upgrades, etc.
- Minimize the likelihood of alienating customers with frequent or disruptive changes, e.g., constant updates, drastic redesigns, etc.
- Minimize the time it takes to gather and organize feedback from various sources, e.g., social media, customer service, etc.
- Minimize the likelihood of disregarding internal feedback, e.g., from employees, team members, etc.
- Minimize the time it takes to prioritize feedback based on urgency and impact, e.g., critical bugs, popular requests, etc.
- Minimize the likelihood of making changes that compromise product quality or safety, e.g., cost-cutting measures, rushed updates, etc.
- Minimize the time it takes to validate the success of changes with customers, e.g., follow-up surveys, user testing, etc.
- Minimize the likelihood of neglecting to inform customers about changes, e.g., update notifications, product announcements, etc.
- Minimize the time it takes to document changes for future reference, e.g., version history, change logs, etc.
- Minimize the likelihood of failing to consider the long-term implications of changes, e.g., maintenance costs, scalability, etc.
Customer Success Statements (PJTBD)
- Identify and understand feedback, e.g., customer reviews, product ratings, etc.
- Analyze the impact of feedback on product performance, e.g., sales data, return rates, etc.
- Determine necessary adjustments based on feedback, e.g., design changes, feature enhancements, etc.
- Avoid ignoring valuable feedback, e.g., constructive criticism, innovative suggestions, etc.
- Implement changes based on feedback, e.g., product updates, new releases, etc.
- Avoid misinterpreting feedback, e.g., cultural nuances, language barriers, etc.
- Communicate changes to stakeholders, e.g., team members, customers, etc.
- Avoid overlooking feedback from minority groups, e.g., underrepresented demographics, niche markets, etc.
- Measure the effectiveness of implemented changes, e.g., customer satisfaction surveys, sales data, etc.
- Avoid implementing changes that do not align with the company's vision or mission, e.g., unsustainable practices, unethical behavior, etc.
- Plan and schedule product updates, e.g., software patches, hardware upgrades, etc.
- Avoid alienating customers with frequent or disruptive changes, e.g., constant updates, drastic redesigns, etc.
- Gather and organize feedback from various sources, e.g., social media, customer service, etc.
- Avoid disregarding internal feedback, e.g., from employees, team members, etc.
- Prioritize feedback based on urgency and impact, e.g., critical bugs, popular requests, etc.
- Avoid making changes that compromise product quality or safety, e.g., cost-cutting measures, rushed updates, etc.
- Validate the success of changes with customers, e.g., follow-up surveys, user testing, etc.
- Avoid neglecting to inform customers about changes, e.g., update notifications, product announcements, etc.
- Document changes for future reference, e.g., version history, change logs, etc.
- Avoid failing to consider the long-term implications of changes, e.g., maintenance costs, scalability, 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]