Identify Product Requirements

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 understand the product's technical specifications, e.g., hardware requirements, software compatibility, etc.
Minimize the time it takes to determine the product's functional requirements, e.g., performance expectations, user interface needs, etc.
Minimize the time it takes to identify the product's security requirements, e.g., data encryption, user authentication, etc.
Minimize the time it takes to understand the product's integration requirements, e.g., with existing systems, with third-party applications, etc.
Minimize the time it takes to determine the product's scalability requirements, e.g., user load, data volume, etc.
Minimize the time it takes to identify the product's maintenance requirements, e.g., updates, patches, etc.
Minimize the time it takes to understand the product's customization requirements, e.g., branding, user roles, etc.
Minimize the time it takes to determine the product's accessibility requirements, e.g., for users with disabilities, for remote users, etc.
Minimize the time it takes to identify the product's regulatory compliance requirements, e.g., GDPR, HIPAA, etc.
Minimize the time it takes to understand the product's data management requirements, e.g., storage, backup, etc.
Minimize the likelihood of overlooking critical product requirements, e.g., due to lack of documentation, unclear specifications, etc.
Minimize the likelihood that product requirements are misunderstood, e.g., due to technical jargon, lack of clarity, etc.
Minimize the likelihood of conflicting product requirements, e.g., due to different stakeholder expectations, changing business needs, etc.
Minimize the likelihood that product requirements are not feasible, e.g., due to technical limitations, budget constraints, etc.
Minimize the likelihood of missing key product requirements, e.g., due to lack of stakeholder input, incomplete research, etc.
Minimize the likelihood that product requirements are not validated, e.g., due to lack of testing, lack of user feedback, etc.
Minimize the likelihood of product requirements are not prioritized, e.g., due to lack of strategic alignment, lack of resource planning, etc.
Minimize the likelihood that product requirements are not communicated effectively, e.g., due to lack of documentation, lack of stakeholder engagement, etc.
Minimize the likelihood that product requirements are not updated regularly, e.g., due to lack of change management, lack of ongoing review, etc.
Minimize the likelihood of product requirements are not aligned with user needs, e.g., due to lack of user research, lack of user testing, etc.

Customer Success Statements (PJTBD)

❓

How important is it that you can quickly and accurately… and How difficult is it for you to…

Understand the product's technical specifications, e.g., hardware requirements, software compatibility, etc.
Determine the product's functional requirements, e.g., performance expectations, user interface needs, etc.
Identify the product's security requirements, e.g., data encryption, user authentication, etc.
Understand the product's integration requirements, e.g., with existing systems, with third-party applications, etc.
Determine the product's scalability requirements, e.g., user load, data volume, etc.
Identify the product's maintenance requirements, e.g., updates, patches, etc.
Understand the product's customization requirements, e.g., branding, user roles, etc.
Determine the product's accessibility requirements, e.g., for users with disabilities, for remote users, etc.
Identify the product's regulatory compliance requirements, e.g., GDPR, HIPAA, etc.
Understand the product's data management requirements, e.g., storage, backup, etc.
Avoid overlooking critical product requirements, e.g., due to lack of documentation, unclear specifications, etc.
Avoid misunderstanding product requirements, e.g., due to technical jargon, lack of clarity, etc.
Avoid conflicting product requirements, e.g., due to different stakeholder expectations, changing business needs, etc.
Avoid unfeasible product requirements, e.g., due to technical limitations, budget constraints, etc.
Avoid missing key product requirements, e.g., due to lack of stakeholder input, incomplete research, etc.
Avoid unvalidated product requirements, e.g., due to lack of testing, lack of user feedback, etc.
Avoid unprioritized product requirements, e.g., due to lack of strategic alignment, lack of resource planning, etc.
Avoid ineffective communication of product requirements, e.g., due to lack of documentation, lack of stakeholder engagement, etc.
Avoid outdated product requirements, e.g., due to lack of change management, lack of ongoing review, etc.
Avoid misalignment of product requirements with user needs, e.g., due to lack of user research, lack of user testing, 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]